OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [wsrp] WSRP url parameters and URL Encoding questions

Subbu & Alejandro, 

A consumer can only do this (second) encoding (for '/') for consumer URL
re-writing but has no control over what the producer puts in a template's
{wsrp-someparameter} slot or what comes in to it on a URL activation.

Eilon's suggestion would work fine, and a portlet (or the producer / portlet
container if any) could still use url encoding but would need to encode
twice on writing into a template and decode once (unless the portlet's web
server is automatically doing a url decode) on receiving the parameter back,
I think.


-----Original Message-----
From: Subbu Allamaraju [mailto:subbu@bea.com]
Sent: 28 March 2003 18:37
To: wsrp@lists.oasis-open.org
Subject: Re: [wsrp] WSRP url parameters and URL Encoding questions

Eilon Reshef wrote:
> A somewhat different approach would be to disallow "special" characters 
> in the portlet-provided values, e.g., navigational state, etc.
> This would mean that a portlet can only use, say, URL-allowed characters 
> (alphanumeric+), but not /, #, :, ?, =, ;, %, etc. (the full list is 
> documented in the corresponding RFC).

I prefer encoding. Applications/portlets may use special characters 
(say, "Smith & Co") in state, and it is safer to encode those characters 
  instead of disallowing such strings.

> This will make it easy for the Consumer to process (no special handling, 
> no dependency on Web server), and will also make it easy for portlets 
> and Producers (easy rules, the portlet can always do one level of 
> escaping and replace the % with, say a dash (-).

Is this not somewhat similar to requiring portlets to URL-encode 
parameters? So, why not requre the consumer do this? This would be less 
restritive for developers.


> Escaping seems to be one of the more common sources for incompatibility 
> and it may just be safer to sidestep rather than spend a lot of time to 
> ensure that compatibility across Producers Consumers and Web servers.
> My two cents,
> Eilon
>     -----Original Message-----
>     *From:* Andre Kramer [mailto:andre.kramer@eu.citrix.com]
>     *Sent:* Friday, March 28, 2003 7:41 PM
>     *To:* wsrp@lists.oasis-open.org
>     *Subject:* RE: [wsrp] WSRP url parameters and URL Encoding questions
>     Rich,
>     Unfortunately, the collapsing of // to / also happens within
>     parameters not just to the separators, e.g. the navigationalState
>     parameter value written into the template by the producer is "a//b"
>     but is modified to "a/b" following normal url path processing rules.
>     The whole path is subjected to this collapsing. The consumer can
>     protect itself from this for its own parameter separators as you
>     suggest (and even have special smarts for wsrp-url values), but the
>     producer should not need to special case any "//" in its URL
>     parameter values (wsrp-navigationalState and wsrp-interactionState
>     are the only difficult parameters). That is why I'm suggesting doing
>     a double encoding. We could instead suggest no consecutive '/'s
>     allowed in navigationalState and interactionState but that seems
>     very arbitrary.
>     regards,
>     Andre
>         -----Original Message-----
>         *From:* Rich Thompson [mailto:richt2@us.ibm.com]
>         *Sent:* 28 March 2003 16:42
>         *To:* wsrp@lists.oasis-open.org
>         *Subject:* Re: [wsrp] WSRP url parameters and URL Encoding
>         It would be a good editorial clarification to comment that all
>         parameter values should be URL encoded since they will appear in
>         the URL activated by an End-User interaction. Does anyone object
>         to adding such a comment?
>         As to the particular question about collapsing // into /, the
>         Consumer can easily prevent this by using a construct such as /_
>         to separate parameters (or "/ns_" before the navigational state
>         if so desired). I think we can leave it the Consumer's
>         responsibility to properly construct its templates.
>         Rich Thompson
>         	*Andre Kramer <andre.kramer@eu.citrix.com>*
>         03/28/2003 10:48 AM
>                 To:        wsrp@lists.oasis-open.org
>                 cc:        
>                 Subject:        [wsrp] WSRP url parameters and URL
>         Encoding questions
>         In we advice "wsrp-url" values to be URL Encoded.
>         However, we are silent on the remaining consumer rewriting
>         tokens and their
>         producer URL writing counterparts. But the obvious thing to do
>         is to URL
>         encode them all (i.e. if {wsrp-navigationalState} contains an
>         "&" or a "/"
>         etc then URL Encode it. Or encode it anyway just to be safe).
>         Having URL Encoded all parameters, for producer template URL
>         activation ,
>         the web server may even help out and do the URL decode for you.
>         Furthermore, in order to support method GET, URL templates must
>         avoid query
>         strings. One strategy is to use a path ("/") instead, but I have
>         found that
>         (after the above helpful URL decode) some Web Servers will
>         replace any "//"
>         with a "/"!
>         [A valid transformation for file paths as, e.g. file path a///b
>         == file path
>         a/b, but not great if one is encoding data as a path. We should
>         not force
>         consumers to use "#" or ";" instead of "?", as these also have
>         issues.]
>         Obviously this corrupts any (URL template) parameters that contain
>         consecutive back slashes, and we can not expect producers to
>         know what URL
>         structure the consumer is using for it's templates. Both the
>         decode and
>         collapsing consecutive "/"s seem valid things for the Web server
>         to do but
>         they are interacting with our method=GET work around. What could
>         we do?
>         The simplest solution seems to be to *double* URL Encode values
>         replacing a  {wsp-someparameter} in templates. By double encode
>         I mean
>         {wasp-paramValue} =
>         HttpUtility.UrlEncode(HttpUtility.UrlEncode(RawParamValue)) or
>         {wsrp-paramValue} =
>         URLEncoder.encode(URLEncoder.encode(rawParamValue));
>         [A single URL encode should be enough for consumer rewriting.
>         The consumer
>         can apply a second encode on re-writing (if required).]
>         This double encode does seem onerous at first, but has the
>         advantage of
>         being always safe and independent of template schemes and
>         usesMethodGet (as
>         well as constant for a Web Server environment & avoids us
>         inventing a new
>         encoding scheme).
>         What do people think?
>         regards,
>         Andre

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]