Skip to content

Do not use default charset for decoding headers (bad practice) #9

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
defnull opened this issue Feb 22, 2018 · 0 comments
Open

Do not use default charset for decoding headers (bad practice) #9

defnull opened this issue Feb 22, 2018 · 0 comments

Comments

@defnull
Copy link

defnull commented Feb 22, 2018

Headers are currently decoded using the system default charset if no explicit charset is passed to the MultipartContext. This caused my application to work correctly on my laptop and the integration test server, but broke in production because the docker container defaulted to latin-1 instead of utf-8 :(

Using the system default charset for anything but console output is considered bad practice as it breaks portability. There is even a JEP draft to deprecate the default charset. See http://openjdk.java.net/jeps/8187041

MultipartContext should not allow null as a charEncoding parameter, or default to UTF-8 (all modern browsers and most HTTP client libraries use UTF-8 per default, even if the RFCs are unclear about this).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant