Open brupxxxlgroup opened 1 week ago
Even if i change the name= value to an ASCII one it fails.
Thank you for the report and the documentation. I'll take a look and see if / how this can be resolved.
It is my understanding that UTF-8 is generally not allowed in headers, although the link you provide seems to show that it's ambiguous.
If the issue is with the Headers
constructor, then I'm not sure what the solution would be (I'd rather not implement a custom headers handler, if at all avoidable).
What can be done about it? Thank you so much for your help.
Well, what can be done right now is not using non-ASCII values, but obviously that's not ideal. I'll investigate this and try to find a longer term solution.
I think your library does exactly what it should do. The client is somehow responsible to encode those values in a proper way.
There is https://datatracker.ietf.org/doc/html/rfc2231 and https://datatracker.ietf.org/doc/html/rfc6266#section-4.3
It seems many clients do not behave properly.
UTF-8 per se is not allowed in headers.
There is also this nice test page with all kind of combinations
http://test.greenbytes.de/tech/tc2231/#encoding-2231-fb
I am not sure if the lib should fix wrong client behaviour but it would be nice if we could some preprocess the header and hand it back to the lib. So as a consumer i could try to fix the header and return a correct value.
Another way would be to convert all the headers values to latin1 and as a consumer i need to convert it back to utf-8.
I am also not sure what is the best way.
Given the following simple HTTP multipart/form-data upload
the lib will fail with
What can be done about it? Thank you so much for your help.