portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Berger <ber...@imn.htwk-leipzig.de>
Subject Re: [jira] Commented: (JS2-376) request parameter encoding problem
Date Tue, 11 Oct 2005 16:22:53 GMT

> It would break Fusion as it exists today.
> A complete patch would include fixes to Fusion as well
>
> Why is that the portal cannot rely on request parameters?
> Seems like a very restrictive requirement
>
Maybe we're talking at crossed purposes.

The character decoding currently implemented does not work correctly 
when using (at least) the struts bridge (due to some wrapping of the 
ServletRequest). One possible solution would be to let the servlet 
container do the decoding by setting 
ServletRequest#setCharacterEncoding() before any 
ServletRequest#getParameter() call. Since the 
ServletRequest#setCharacterEncoding() is called within the 
CapabilitiesValve, I searched for and found two earlier invocations of 
getParameter(), which must be removed to make this work.

This change delegates the character decoding, which is currently done in 
ServletRequestImpl (and relies on ISO-8859-1 characters), to the servlet 
container.

The invocation we're talking about is imho dispensable, as setting 
pipelines is done with request attributes (not parameters). Furthermore, 
the servlet api does not define a method to set request parameters 
programmatically if not transmitted by the browser request. So, is it 
really necessary to set the pipeline by a browser request parameter?
e.g.:
http://localhost:8080/jetspeed/?pipeline=test
which of course throws an exception.


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org


Mime
View raw message