[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