Jetty
  1. Jetty
  2. JETTY-207

Decoding of query characters ignores setCharacterEncoding

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 6.1.0rc3
    • Fix Version/s: None
    • Component/s: HTTP
    • Labels:
      None
    • Number of attachments :
      0

      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) );

        Activity

        Hide
        Greg Wilkins added a comment -

        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.

        Show
        Greg Wilkins added a comment - 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.
        Hide
        Michael Böckling added a comment -

        Why has this bug been marked as "won't fix"?
        At least the reason should be given.

        Show
        Michael Böckling added a comment - Why has this bug been marked as "won't fix"? At least the reason should be given.

          People

          • Assignee:
            Unassigned
            Reporter:
            Chris Haynes
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: