portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <da...@bluesunrise.com>
Subject Re: [J2] Proposal: Handling encoding requirements for the Portal URL
Date Thu, 26 Aug 2004 15:20:21 GMT

On Aug 25, 2004, at 6:48 PM, Ate Douma wrote:
>
> To solve these problems I propose the following solution:
>
> 1) The control parameter prefix key may not be one of: '/', '?', ' ', 
> or '#'
>
+1

> 2) To be able to clearly separate the [/GlobalNavigation] part from 
> the [/ControlParameters] part, all [/GlobalNavigation] (path) elements 
> which start with the control parameter prefix are encoded by putting 
> an additional prefix character in front of it. This character of 
> course then also may not be used
> as control parameter prefix. A [/GlobalNavigation] path element 
> already starting with this character must also be prefixed with it, 
> escaping it.
> Which character should be used is a matter of taste. I personally opt 
> for '!'.

+1 - but why not make the "!" configurable

>
> 3) All the [/ControlParameters] portlet request parameter values must 
> have the '_' character encoded, preferably with only a single 
> character instead of using a multi-character hexadecimal style. This, 
> because values might itself contain such a encoding pattern which then 
> needs to be escaped.
> I would prefer using a '!' again (no conflict with [/GlobalNavigation] 
> encoding because these encoded values are never at the start of a url 
> path element).
> If we want to have a clearer distinction another character like '$' 
> would also be good.
>
+1

> 4) As per the portlet specification, all the [/ControlParameters] 
> parameter name and values as well as those in the [?RequestParameters] 
> part need to be
> "x-www-form-urlencoded" encoded which can be done with 
> java.net.URLEncoder.
>
+1

> 5) The Url parameter separators '?' and '&' are also allowed to be 
> specified using html escape definitions like &#38 and &amp; for '&' 
> and &#63; for '?'.
> If those are encoded using the URLEncoder they won't be recognized 
> anymore so they must be properly decoded (into '?' and '&') *before* 
> encoding using the URLEncoder.
>
+1

> 6) Within Jetspeed, HttpServletRequest.getPathInfo() may not be used 
> anymore because it will first decode the the path string which can 
> again break the
> url parsing. Luckily, this can be easily circumvented by using the 
> following statement:
>   String pathInfo =
>     
> request.getRequestURI().substring(request.getContextPath().length()+
>                                       
> request.getServletPath().length());
>
I would like to review each individual place where getPathInfo is used 
before just blindly changing it.
One issue on Weblogic, during a request dispatcher's include, 
getContextPath() returns the path to the dispatched servlet, where as 
on Tomcat and JBoss, it returns the context path to the dispatching 
servlet

--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
[office]   +01 707 773-4646
[mobile] +01 707 529 9194



---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Mime
View raw message