Details
-
Type:
Bug
-
Status:
Resolved
-
Priority:
Major
-
Resolution: Won't Fix
-
Affects Version/s: 6.1.0rc3
-
Fix Version/s: None
-
Component/s: HTTP
-
Labels:None
-
Number of attachments :
Description
Deduced from static code inspection of 6.1.0rc3. in org.mortbay.jetty.Request#extractParameters()
There are two values defining the character encoding:
the instance member '_queryEncoding' and local variable 'encoding'.
In a deployed Jetty installation where the user is only ever using runtime parameters
and/or the published Servlet APIs, '_queryEncoding' can only ever be given a value
by using the 'org.mortbay.jetty.Request.queryEncoding' parameter.
It thus acts as a server-wide default value, individual servlets cannot set its value.
What they are supposed to do is call the servlet API HTTPServlet#setCharacterEncoding(String).
The parameter of this call is used in Request.extractParameters() by
String encoding = getCharacterEncoding(); // Request line 1222
The key method invocation, where I believe the bug is, is in line 1227:
_uri.decodeQueryTo(_baseParameters,_queryEncoding);
Note that this uses '_queryEncoding', not 'encoding'.
So the only current way of specifying the encoding used to decode the query is via
the server-wide 'org.mortbay.jetty.Request.queryEncoding' parameter.
I think the logical solution would be to prefer any specific encoding set via the Servlet
'setCharacterEncoding()' API , defaulting to the _queryEncoding.
So I would propose changing line 1227 to
_uri.decodeQueryTo(_baseParameters, (encoding!=null?encoding:_queryEncoding) );
I have been around this loop many many times and I really think the current compromise
is the best.
The content encoding of the body of the request is totally unrelated to any encoding used in the URL. As we discussed on the list, the best way to deal with this is to just use UTF-8
The setQueryEncoding method is there as a fall back so that you can override this in a
handler.
Note the Request attribute "org.mortbay.jetty.Request.queryEncoding" can be set per request from a standard servlet and thus allows this mechanism to be called from a portable servlet.