Scott T. Weaver said: > Looks very good Ate! When are you looking to commit your changes? I ask > this because we are starting to do a lot of portlet development using a > pre-existing webapp framework and I can already see where your > refactorings to the PortalURL will probably save us a lot of headaches > in the future.
I hope to complete the rest of the work before the end of this weekend. The time I have formally available for J2 has been drastically cut down since last week though to 1 day/week (at the most). The other days I'm now working on another project (completely non-portal related). So most of the work I have to do in my own time, during the evening/night/weekend :-( So bear with me if it takes a few days longer than that. > > Regards, > > Ate Douma wrote: > >> Currently, the url encoding done by J2 isn't exactly fail prove. >> For the Struts Portlet Framework (now Portals Struts Bridge) I created >> a workaround to be able to use embedded url parameters but even that >> turned out not to work under all situations. >> >> Furthermore, there are portlet specification requirements which >> currently are not met. >> >> I have been trying to create a fail prove solution and have already >> done part of what I propose below. >> But, to get it completely right turned out to be more complex than I >> first thought it would. >> Therefore I first want to present my ideas how to solve this. >> >> I'm not sure I covered all requirements and maybe its not fail prove >> either, so please shoot as much holes in it as possible because the J2 >> project I'm involved in has run in many problems because of this and I >> need to fix them asap. >> >> First I like to specify the (current) definition of a Jetspeed >> PortalURL as far as I have been able to determine from the code. >> >> 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) >> >> 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. >> >> >> >> 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. >> >> >> >> 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. >> >> Regards, >> >> Ate >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > -- > ******************************************* > * Scott T. Weaver * > * <[EMAIL PROTECTED]> * > * <http://www.einnovation.com> * > * -------------------------------------- * > * Apache Jetspeed Enterprise Portal * > * Apache Pluto Portlet Container * > * * > * OpenEditPro, Website Content Management * > * <http://www.openeditpro.com> * > ******************************************* > > > --------------------------------------------------------------------- > 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]
