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 & and & for '&' and ? 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 theI would like to review each individual place where getPathInfo is used before just blindly changing it.
url parsing. Luckily, this can be easily circumvented by using the following statement:
String pathInfo =
request.getRequestURI().substring(request.getContextPath().length()+
request.getServletPath().length());
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 [EMAIL PROTECTED] [office] +01 707 773-4646 [mobile] +01 707 529 9194
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
