request parameter encoding problem
----------------------------------
Key: JS2-376
URL: http://issues.apache.org/jira/browse/JS2-376
Project: Jetspeed 2
Type: Bug
Components: Components Core
Versions: 2.0-M4
Reporter: Thorsten Berger
I logged an issue for the struts bridge, but found out that this problem is
specific to jetspeed.
Please see PB-14 (unable to post unicode characters in struts bridge) for an
introduction.
The problem is the character decoding done in in
o.a.j.engine.servlet.ServletRequestImpl (line 157):
try
{
paramValues[i] = new
String(paramValues[i].getBytes("ISO-8859-1"), getCharacterEncoding());
}
catch (UnsupportedEncodingException e)
The struts bridge now does some further wrapping of the ServletRequest
resulting in calling the code above twice (and decoding decoded parameter
strings again). It's clear that this results in garbage characters.
The first call is done by jetspeed itself (providing parameters to the
StrutsPortlet) and the second by the Struts RequestProcessor (to populate the
form bean). However, I think this behaviour should be changed in Jetspeed.
I'd like to suggest two solutions:
1: setting a request attribute indicating that request parameters have already
been decoded, which prevents the second decoding
2: Delegating the decoding to the servlet api. (my preferred solution)
I think hard-coding the encoding is unclean. The portal cannot count on
"ISO-8859-1" parameter strings (which is especially true in the above case).
The delegation could be achieved by:
- removing the decoding from o.a.j.engine.servlet.ServletRequestImpl
- changing JetspeedRequestContext.setCharacterEncoding() to set the encoding
also to the wrapped HttpServletRequest
- as you know this has to be done before the first getParameter() call is
invoked, the following two calls must be removed to make this work:
line 60 in CapabilityValveImpl (the variable "requestMediaType" is never used)
and line 192 in JetspeedEngine (noticed that "targetPipeline" is never set as
request parameter rather than as request attribute)
-> results in the CapabilityValveImpl setting the characterEncoding before any
getParameter() call
As I urgently need this to work for my portal I applied solution 2. I would
provide a patch for this solution if you're in agreement.
Regards, Thorsten
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]