portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <da...@bluesunrise.com>
Subject Re: [jira] Commented: (JS2-376) request parameter encoding problem
Date Tue, 11 Oct 2005 16:51:33 GMT
Thorsten Berger wrote:
>> 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.

It throws an exception because there is no pipeline named "test".
I objected to taking out this line:

          String targetPipeline = context 

since it would break any URLs coming from the browser with the pipeline 
parameter on it. This is currently how Fusion works: the pipeline is 
passed on the URL, not as a request attribute. Additionally, any 
existing HTML/Javascript that depends on the pipeline request parameter 
will be broken. Again, your soluton seems disproportionate in 
tradeoffs: are you saying that, with your patch, the portal can no 
longer make use of request parameters? I must be missing something here

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

View raw message