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
Default multipart form encoding uses noncompliant URLEncoder for tilde (~) #1966
Comments
Disregard that edit note, the Rfc3986.Unreserved char set would be correct. I got confused because URLEncoder also incorrectly handles the |
Yes, a PR would be great - though I'd like to include this change in sttp4 (so the PR would be to the |
Java
It seems that there may be some corner cases around parsing |
Problem:
Following the examples in the docs for submitting form data using
multipart
method results in encoding that is not compliant with RFC 3986 specifically related to how the tilde (~) character is handled.multipart("form", Map("some_key" -> "~"))
results in aStringBody(some_key=%7E,utf-8,text/plain)
form component generated where the tilde has been encoded into %7E. As per the latest spec on URL encoding, ~ is not a reserved character and should not be encoded.It looks like this problem was partially tackled already within STTP as the internal UriCompatibility object has an additional encodeDNSHost method which uses a spec compliant Rfc3986.encode method. Unfortunately the multipart method uses the noncompliant encodeQuery method on UriCompatibility.
Is it possible to switch to using the Rfc3986 encoder instead of the URLEncoder as part of the multipart method's form handling? (edit: originally mentioned incorrect allowedCharacters set that would work here) Looks like a new character set would need to be defined within Rfc3986 object to get a fully correct allowedCharacters set. Want a PR for this?
The text was updated successfully, but these errors were encountered: