MultipartBody headers should allow non-ascii characters

[sxci]

here, https://github.com/square/okhttp/blob/parent-3.12.0/okhttp/src/main/java/okhttp3/MultipartBody.java#L259
for MultipartBody,like file upload, the filename may not be ascii ,but it is legal.

but Headers.of https://github.com/square/okhttp/blob/parent-3.12.0/okhttp/src/main/java/okhttp3/Headers.java#L224
use the 'checkValue(value, name)' , it is not allowed non-ascii char.

[vishr]

Is there any workaround? It crashes while uploading a file with non-ascii characters.

[swankjesse]

Strip non-ascii characters from headers before passing them to MultipartBody?

[vishr]

In my case I can skip passing a filename, so it works for me.

[sxci]

Strip non-ascii characters from headers before passing them to MultipartBody?

we need the same filename in the fielsystem , just like upload a non-ascii-filename file in form action. sometimes, the fielname's characters are all non-ascii .

[galderz]

Indeed, I don't think stripping is a good idea since important information could get lost. If all filename's characters are non-ascii you'd be left with no characters ;)

If you want to keep filename as part of the Content-Disposition header then you have to adhere to header rules since those rules are the most strict and the ones that will eventually prevail. So, encoding the filename with RFC 5987 should work. This assumes that the server can decode the RFC5987 encoded file name. That depends on the server itself...

Another possibility would be to remove the filename out of the Content-Disposition and instead move the filename to the URL itself and add it there. That would force you to encode the filename in application/x-www-form-urlencoded format (e.g. using Java's URLEncoder). In the server you'd do the opposite work.

It's also worth noting that Content-Disposition can contain a filename* field which is expected to follow RFC 5987 format, see here. If both filename* and ``filenameare present, it appearsfilename*` is chosen.

[swankjesse]

Fixed in 3.13!

[galderz]

Sorry I missed the PR 🙈. I had also not realised that there was already support for non-ascii headers in the codebase.

The PR does not mention but I guess based on your testing that you've discarded the option of implementing support for filename* (RFC6266)?

[swankjesse]

Yeah as far as I can tell filename* is not used by browsers doing multipart posts.