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 03:48:20 UTC
[J2] Proposal: Handling encoding requirements for the Portal URL
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
Re: [J2] Proposal: Handling encoding requirements for the Portal
URL
Posted by "Scott T. Weaver" <sc...@binary-designs.net>.
My order of preference: 2,1,3.
Raphaël Luta wrote:
> 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, you could keep them only in the session and never send
> them back to the browser.
> 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.
>
>> 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.
> 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 :)
>
--
*******************************************
* 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 Raphaël Luta <ra...@apache.org>.
Ate Douma wrote:
> Raphaël Luta said:
>>Ate Douma wrote:
> <snip>
>>
>> >
>> > 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).
>
You're right. To support this case, we need to have a generic and well-defined
encoding scheme for storing control parameters on the URL.
>>> <snip original proposal>
>>
>>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.
>
Yes. RequestParameters should always be correctly encoded, but then this is true
in any web development environment :)
> 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.
>
The only obvious disadvantages I see to doing this are:
- we lose some CPU cycles on the compression/encoding
- we actually *increase* the size of the URL when there's no control parameter:
<test>
raphael@aragorn:~> echo -n "" | gzip -9 | perl -e 'use MIME::Base64; print
encode_base64(<>);' | wc
1 1 29
</test>
So an empty string is 29 characters long after this process, so much for
compression :)
Of course, this can be handled by not compressing if the [controlparameter]
string length <= 18, which yields a base64 encoded string of at most 25 chars.
Upon parsing, you simply check the encoded string length to decide if you need
to gunzip.
The only slight drawback of this conditional encoding is that if there's no
control parameters to encode it makes the trailing / at the end of the path_info
significant which may be somewhat conunter-intuitive, eg:
http://myportal/portal/page/mypage/?param1=1
parses as:
GlobalNavigation -> /page/mypage
ControlParameter -> empty
RequestParameter -> param1=1
but
http://myportal/portal/page/mypage?param1=1
parses as:
GlobalNavigation -> /page
ControlParameter -> Base64Decode(mypage) -> 2
RequestParameter -> param1=1
which will not work.
--
Raphael Luta - raphael@apache.org
Apache Jetspeed - Enterprise Portal in Java
http://portals.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 Ate Douma <at...@douma.nu>.
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 - raphael@apache.org
> Apache Jetspeed - Enterprise Portal in Java
> http://portals.apache.org/
>
> ---------------------------------------------------------------------
> 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 Portal URL
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Aug 26, 2004, at 8:03 AM, Raphaël Luta wrote:
> 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, you could keep them only in the session and never send
> them back to the browser.
> 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.
>
True, that is why we have a configurable navigational state component
with currently 2 implementations
The other implementation uses Pluto URLs, which are much longer than
the Jetspeed URLs since they encode all current and previous states
---------------------------------------------------------------------
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 Portal
URL
Posted by Raphaël Luta <ra...@apache.org>.
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,
you could keep them only in the session and never send them back to the browser.
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.
> 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.
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 - raphael@apache.org
Apache Jetspeed - Enterprise Portal in Java
http://portals.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
Re: [J2] Proposal: Handling encoding requirements for the PortalURL
Posted by Ate Douma <at...@douma.nu>.
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 Portal
URL
Posted by "Scott T. Weaver" <sc...@binary-designs.net>.
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.
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
Re: [J2] Proposal: Handling encoding requirements for the Portal
URL
Posted by Shinsuke SUGAYA <sh...@yahoo.co.jp>.
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 & 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
>>>
>>
>> __________________________________
>> 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
Re: [J2] Proposal: Handling encoding requirements for the Portal
URL
Posted by Ate Douma <at...@douma.nu>.
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 & 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
>>
>
> __________________________________
> 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
Re: [J2] Proposal: Handling encoding requirements for the Portal
URL
Posted by Shinsuke SUGAYA <sh...@yahoo.co.jp>.
Is there any update? In order to fix JS2-125, 4 is needed.
Currently, multibyte characters are broken...
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 & 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
>
__________________________________
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
Re: [J2] Proposal: Handling encoding requirements for the Portal
URL
Posted by David Sean Taylor <da...@bluesunrise.com>.
Ate Douma wrote:
>
>
> David Sean Taylor wrote:
>
>>> 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());
>>>
>> I would like to review each individual place where getPathInfo is
>> used before just blindly changing it.
>> 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
>
> The Servlet spec (2.3, SRV4.4) says:
> It is important to note that, except for URL encoding differences
> between the
> request URI and the path parts, the following equation is always true:
> requestURI = contextPath + servletPath + pathInfo
>
> Assuming Weblogic is compliant to the specs aren't the pathInfo (and
> servletPath) then also be of the dispatched servlet?
>
From reading this, SRV 8.3.1, it sounds like Weblogic is correct.
Regardless I've added a fail-safe to ensure the contextPath is always
that of the portal.
Still, please run the pathInfo changes by me before committing so that I
can test J2 and Fusion on Tomcat4, Tomcat5, JBoss, Weblogic, and Websphere
I have Fusion running on all these platforms. J2 not yet...
---------------------------------------------------------------------
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 Portal
URL
Posted by Ate Douma <at...@douma.nu>.
David Sean Taylor wrote:
>> 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());
>>
> I would like to review each individual place where getPathInfo is used
> before just blindly changing it.
> 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
The Servlet spec (2.3, SRV4.4) says:
It is important to note that, except for URL encoding differences between the
request URI and the path parts, the following equation is always true:
requestURI = contextPath + servletPath + pathInfo
Assuming Weblogic is compliant to the specs aren't the pathInfo (and
servletPath) then also be of the dispatched servlet?
---------------------------------------------------------------------
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 Portal URL
Posted by David Sean Taylor <da...@bluesunrise.com>.
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 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());
>
I would like to review each individual place where getPathInfo is used
before just blindly changing it.
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
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