Re: [wsrp] URL rewriting expression required to be valid for its mimetype?

[Alejandro Abdelnur <Alejandro.Abdelnur@Sun.COM>]

Thanks for the initial write up Rich.

* Part I (answering Rich's write up)-----------------------

I still don't see why is a problem always using '&' in the case of consumer rewriting ('wsrp-rewrite?.../wsrp-rewrite'). The consumer has the chance to replace the '&' with '&' if an XML markup type is to be returned to the user-agent. The portlet developer would always use '&', if the WS stack does funny things to send it to the consumer, that's something the WS stacks in both sides (consumer and producer) have to deal with, but completely transparent to the producer and the consumer. The producer pushes '&'s and the consumer gets '&'s. If the user-agent needs '&', the consumer will take care of doing the transformation.

For #1. On using a DOM library, the library will escape invalid characters. On imposing 'valid output stream' requirement, I think this is not doable. First of all, fragments are not valid XML documents, they are fragments. And secondly, URLs of the form 'wsrp-rewrite?.../wsrp-rewrite' (that will be in the fragment) are not valid URLs.

For #2. Same as #1. And I agree with Yossi's comments that stuff could be encrypted so the intermediary could do nothing.

For #3. I see 2 options here. One, at rewriting time the consumer already knows what ('&' or '&') has to be used and does it while rewriting the URLs. Two, at rewriting time the consumer does not know what has to be used, leaves the '&'s and a second rewrite is done later to resolve the '&'s.

Or, to avoid confusion with the '&', we could use a different separator (ie '$') and force the consumer to replace it with the right thingy if the data will end up in a URL in the generated page.

* Part II (adding other scenario)-----------------------

Where I see we have a problem is in producer rewriting. The Producer receives URL templates and it will add application parameters to it, these parameters have to be separated. What does the producer use? '&'s or '&'s ? How does the producer know the final MIME type ?

Alejandro



On Thursday, June 12, 2003, at 12:00  PM, Rich Thompson wrote:

> I was asked to start this thread for enumerating the issues and how the proposed solution addresses them.
>
> Basic issue is that the format of our URL rewriting expression (wsrp-rewrite?wsrp-urlType=value&name1=value1.../wsrp-rewrite) is not valid for XML markup types. In particular, XML requires that the character "&" be represented as the entity "&". We should note that the values a portlet author could write into the expression potentially also suffer from this problem. This problem becomes acute when one considers the impacts on various parties:
>   1. Portlet author: At least one technology (serialization of a DOM) can not be used to produce invalid XML. Others may also impose this requirement of producing a valid output stream.
>   2. Intermediaries: When the markup moves out into an attachment, it will be natural for an intermediary to examine the fragment. This examination will fail if the fragment is invalid for its mime type.
>   3. Consumer processing: For some Consumer implementations, it would be required that the URL rewriting take place very early in the processing of the fragment in order to make the fragment valid for other steps to process.
>
> The proposed solution is to require Consumers to accept both "&" and "&" as the name/value pair separator. We would also encourage portlet authors to use the entity approach for ease of upgrading when their content gets placed into an XML markup type.
>
> Andre's quick test suggested that even when such an entity reference makes it to the browser the browser tends to parse the entity reference and replace it with the represented character such that no special code should be required of the Consumer when processing an activated URL that had contained an entity reference.
>
> I would note that this solution does not address whether or not the values written into the URL are valid for the mime type. I will plan to look again at the wording, but suggest that the requirement for strict encoding of values placed in URLs point out that the encoding needs to take into account both the fact that the value is being placed into an URL and that the URL will be in a document of a particular mime type. As a result, the encoding needs to deal with any characters special to URLs and/or the mime type.
>
> Rich Thompson