You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Ate Douma <at...@douma.nu> on 2004/08/26 17:02:42 UTC
Re: [J2] Proposal: Handling encoding requirements for the PortalURL
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: jetspeed-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>
>>
>
>
> --
> *******************************************
> * Scott T. Weaver *
> * <we...@apache.org> *
> * <http://www.einnovation.com> *
> * -------------------------------------- *
> * Apache Jetspeed Enterprise Portal *
> * Apache Pluto Portlet Container *
> * *
> * OpenEditPro, Website Content Management *
> * <http://www.openeditpro.com> *
> *******************************************
>
>
> ---------------------------------------------------------------------
> 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
Re: [J2] Proposal: Handling encoding requirements for the PortalURL
Posted by "Scott T. Weaver" <sc...@binary-designs.net>.
I can also help since I am pretty much dedicated to portal development
on my current project.
David Sean Taylor wrote:
>
> On Aug 26, 2004, at 8:02 AM, Ate Douma wrote:
>
>> 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.
>>
> Ate,
>
> I can help out with coding if needed -- just let me know what parts
> you need help on
>
> --
> 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
>
>
--
*******************************************
* Scott T. Weaver *
* <we...@apache.org> *
* <http://www.einnovation.com> *
* -------------------------------------- *
* Apache Jetspeed Enterprise Portal *
* Apache Pluto Portlet Container *
* *
* OpenEditPro, Website Content Management *
* <http://www.openeditpro.com> *
*******************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Proposal: Handling encoding requirements for the PortalURL
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Aug 26, 2004, at 8:02 AM, Ate Douma wrote:
> 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.
>
Ate,
I can help out with coding if needed -- just let me know what parts you
need help on
--
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