[jetty-dev] [jira] (JETTY-1532) HTTP headers decoded with platform's default encoding

"Dawid Weiss (JIRA)" <[email protected]> Mon, 3 Sep 2012 02:16:21 -0500 (CDT)
Newsgroups gmane.comp.java.jetty.general
Message-ID <1971694275.49797.1346656581290.JavaMail.j2ee-jira@codehaus01.managed.contegix.com>
Dawid Weiss
commented on JETTY-1532

HTTP headers decoded with platform's default encoding

By "broken" I meant exactly that – the bytes in a Buffer will rarely match the platform's default encoding. The Buffer is (from my brief analysis) constructed from fragments of incoming HTTP request (headers, for example). This implicit assumption that the codepage of headers/ other data and the platform will match is just plain wrong so any use of Buffer's toString() method is, from my perspective, a source of potential problems. From what I remember, toString() is used not only for diagnostics (debugging) but also for other program logic. I'd say toString() should be allowed only when assertions are enabled (so that debugging can be done) but a specialized to
String(Charset) should be exposed for program logic. Or whatever else but verifying that the byte buffer matches the request codepage.

Obviously you may disagree with this, but it is really easy to verify in practice – run your jetty instance with -Dfile.encoding=UTF-32. Does it work and pass all the tests? If so, it's fine and doesn't depend on the default codepage. If it doesn't, it's broken to me.

This message is automatically generated by JIRA.

If you think it was sent incorrectly, please contact your JIRA administrators .

For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email