portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shinsuke SUGAYA <shins...@yahoo.co.jp>
Subject Re: [J2] Proposal: Handling encoding requirements for the Portal URL
Date Sat, 25 Sep 2004 23:53:05 GMT
Hi Ate,

Thank you for the update info. Understood.
I'm looking forward to the patch ;)

Regards,
  shinsuke


Ate Douma wrote:
> Shinsuke SUGAYA wrote:
> 
>> Is there any update? In order to fix JS2-125, 4 is needed.
>> Currently, multibyte characters are broken...
> 
> 
> Shinsuke,
> 
> Sorry for not reporting yet to the list (I had to go more low profile 
> because my lack of time for J2 recently), but yes I can give an update.
> 
> I completed a first version of a new Portal URL and navigational state 
> encoding just a few days ago. Because it is a complete rewrite of the 
> current implementation, David Sean Taylor and Scott Weaver will do a 
> first review and test (I send them a big patch file yesterday). I've not 
> used my original proposal (below) but based it on the follow up proposal 
> from Raphaƫl Luta, involving encoding the whole of the navigational 
> state into one parameter using base64 encoding.
> I hope to commit my changes very soon, but we also will have to adapt 
> J1/Fusion which is quite dependent on the current implementation.
> 
> The new version fully implements the encoding requirements, and thus 
> will fix J2-125 also.
> 
> Regards,
> 
> Ate
> 
>>
>> Thanks,
>>  shinsuke
>>
>> 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 &#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.
>>>
>>> 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: jetspeed-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>>
>>
>> __________________________________
>> TSUKAME EIKOU! KAGAYAKE EGAO!
>> Yahoo! JAPAN JPC OFFICIAL INTERNET PORTAL SITE
>> http://pr.mail.yahoo.co.jp/para/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>
>>
>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
> 

__________________________________
TSUKAME EIKOU! KAGAYAKE EGAO!
Yahoo! JAPAN JPC OFFICIAL INTERNET PORTAL SITE
http://pr.mail.yahoo.co.jp/para/


---------------------------------------------------------------------
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