Rapha�l Luta said: > Ate Douma wrote: > > <snip> >> >> A Jetspeed PortalURL is build up out of 5 parts: >> >> [<baseURL>/<basePath>][/GlobalNavigation][/ControlParameters][?RequestParameters][#LocalNavigation] >> >> >> The [baseURL/basePath] defines the access point to the portal like: >> [<http://localhost>/<jetspeed/portal>] >> >> The [/GlobalNavigation] defines site navigation to folders and pages >> like: >> [/], or [/default-page] or [/default-page.psml] for the default >> page >> or [/Administrative/pam] >> or [/rootfolder/subfolder/page] >> etc. >> >> The [/ControlParameters] define statefull portlet specific parameters >> like for window mode, portlet mode and portlet request parameters. >> These parameters are encoded in two different ways. >> Non-portlet request parameters: >> <prefix><type>_<portletWindowId>/<value> >> Portlet request parameters >> <prefix><type>_<portletWindowId>_<parameterName>/<parameterCount>_<parameterValue1>[[_<parameterValue<x>]...] >> > > > > The control parameters prefix and type keys are all externally > definable > > (in spring assembly jetspeed-spring.xml) > > > > AFAIK, the JSR168 does not mandate that these parameters be included in > the URL, True, but...
> you could keep them only in the session and never send them back to the > browser. ... which might be quite a problem. Consider a RenderURL link on a page containing additional (new) request parameters. As these parameters are encoded as ControlParameters these *must* be part of the RenderURL send to the server if the user selects the link. For an ActionURL, which always results in a client redirect (Pluto implementation) a new client url can be generated without any ControlParameters. But for an RenderURL this shouldn't be done I think (certainly not for just clearing out possible ControlParameters). > The only disadvantage I see of doing this is that it becomes impossible > for the > user to bookmark a portal page in a non-default state. > > I personnally would rather like to have clean simple URLs and not be able > to > boolmark pages in non-default states than having extremely long and > unnatural > URLs sent to the user. That really depends on the portlet functionality. I wouldn't want to make it impossible on forehand. > >> The [?RequestParameters] define the "normal" url parameters like those >> of an ActionURL and are encoded as usual: >> name=value definitions with first parameter prefixed with an '?', >> additional parameters prefixed with '&'. >> >> Finally, the [#LocalNavigation] is only used by a browser to refer to a >> embedded anchor location. >> > > Agreed, but you may also want to consider that some app servers are > configured > not to track sessions through cookies but through URL rewriting so you > probably > want to avoid any scheme that can confuse the most popular servers > out there (like apache, tomcat, etc...). > >> From the above definitions it becomes clear that the values of certain >> elements might cause havoc on the url parsing as is done >> by both the servlet environment as well as by jetspeed. >> Of course, defining the control parameter prefix as '/' clearly will >> break things, but also using a '/', '_', '?' or '&' within a request >> parameter >> name or value will do so. >> >> In the portlet 1.0 specification these kind of problems have been >> recognized and therefore PLT.7.1 SPEC 30: >> The portlet-container must "x-www-form-urlencoded" encode parameter >> names and >> values added to a PortletURL object. >> >> Currently, Jetspeed 2 doesn't do this! >> A light encoding algorithm is implemented which replaces '_', '.', '/', >> '\r', '\n', '<', '>' and ' ' with hexadecimal representations (0x1, 0x2 >> etc). >> But, this is only done for RequestURL parameters and also not as >> complete as required by the spec. For instance, '?' and '&' characters >> are currently not encoded. >> >> Besides the parameter names and values, other elements also can break >> the url (parsing). >> If a folder or page name in the [/GlobalNavigation] part start with the >> ControlParameter prefix key character Jetspeed won't be able to >> determine them correctly. >> > > Agreed on the symptoms. What we do now is a ugly hack that need to be > fixed. > >> >> >> To solve these problems I propose the following solution: >> >> 1) The control parameter prefix key may not be one of: '/', '?', ' ', or >> '#' >> >> 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 '!'. >> >> 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. >> >> 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. >> >> 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. >> >> 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()); >> > > > > As said above, part of this solution I already have in place (4, 5 and > 6). > > Once we have a solid solution I will also do the required additional > > changes. > > While the above will perfectly work, I think you operate within an > implicit > constraint of having all [/ControlParameters] readable and parseable by > the > browser/user. This is not a requirement IMO, even if we go and send back > [/ControlParameters] to the browser and not keep them within the server > session, only the server needs to be able to parse these parameters when > they > are sent back. > > Hence you can for example have the following transformation: > Unencoded control parameter string -> GZipFilter -> Base64Encoder* -> > [EncodedControlParemeter] > > (* I believe '/' is valid Base64 encoding so we need to modify slightly > the > encoding table not to allow this char but use '!' or '_' instead) > > and simply append the the [EncodeControlParameter] at the end of the > [GlobalNavigation] separated by a /. > > Your request URL then becomes a regular one, without any specific > additional > delimiters; except that the last segment of the request path info is an > encoded > string reprsenting the [ControlParameter] that can easily be decoded by > the > portal. If I understand this correctly, using this solution would result in a PortalURL like this: [GlobalNavigation]/[Encoded ControlParameterString][?Encoded RequestParameters][#LocalNavigation] We we will still need to encode the (ActionURL) RequestParameters because these also can contain trouble making characters. And besides that, the Portlet SPEC 30 explicitely requires it. I have to think a little more about it, but I kinda like this solution as it indeed would result in a regular url, easily parseable by the portal. And also is a lot easier to implement as far as I can see right now. So +1 for this solution if it is feasible. > Using a gzip filter also ensures we keep control of the URL length since > the > absolute minimum size of a control parameter is 11 char and more likely to > run > into the 20-25 char. > > I personnally value control over the URLs we use in the app and thus would > prefer solve these issues in this order of preference: > 1- not sending control parameters at all and keep them within the server > session > 2- sending a completely encoded control parameters string and append it as > the > last component of the request path info > 3- define additionnal reserved markers and sub-components of the URL > > However, if we decide to go for 3 I think your proposal completely fits > the > bill :) > > -- > Raphael Luta - [EMAIL PROTECTED] > Apache Jetspeed - Enterprise Portal in Java > http://portals.apache.org/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
