Current state of non-ascii values in http headers?

Question

We had an international customer ask about some Safari behavior of

Content-Disposition: attachment; filename=<customer file name>.pdf

We hadn't been testing international uses of our pdf writing functions, and they saw Safari behaving oddly for them. That started off a mini-odyssey for me today looking into this.

Specifically, when the customer had Safari on a mac configured for English, our Japanese-named pdf saved just fine (with the default behavior of Asp.Net/IIS, serializing that field as raw utf-8). But when they configured their browser to be in Japanese, the file name came out as each serialized utf-8 character being treated as Ascii.

Some quick googling got piles of references to Rfc5987 and Rfc8187 and lots of posts here and elsewhere on how those get implemented vis a vis Content-Disposition: filename=...

Problem is a lot of those posts are from 2007-2015.

I started trying out a lot of those Rfc5987/8187 implementation suggestions on the latest Chrome build, the latest Firefox build, IE 11 and Edge (I don't have a mac with Safari handy) and here's what I found:

• IE11 and Edge will recognize if filename= is url encoded and decode it. Other browsers won't.
• IE11, Edge, and Safari on mac (configured in English) will accept filename= raw utf-8 and will process it properly to a Japanese name
• Safari (configured with Japanese) and Firefox and Chrome will take filename = raw utf-8 as a string of ascii characters
• Not one browser I have implemented any of Rfc5987/8187. Not a feature.

I tried

• filename=[url encoded version].pdf;
• filename*=utf-8''[url encoded version].pdf (also UTF-8 when lower case didn't work)
• filename=[both raw and url encoded].pdf; filename*=utf-8''[url encoded].pdf

Just filename* values were completely ignored in all the browser I had on hand. filename=...; filename*= ran the ;filename*=... into the resulting filename.

In short not a single browser of the 4 appeared to implement any bit of Rfc 8187.

But I've seen references to Asp.Net Core (which we don't currently use) having a FileNameStar member in their ContentDispositionHeader object model, so that makes me think something out there must be implementing Rfc 8187.

But all of the posts I've seen seem to peter out around 2015 and none of the things I find in them appear to be working in the browsers I have available.

Does anyone have any more current ideas on how to get browsers to process international character sets in Content-Disposition: filename= values?

I mean, so far the only problems people have reported are with Firefox and Safari configured to something not US English; just doing what comes naturally seems to be working in a lot of situations.

But it would be nice to know how to do it "correctly."

EDIT: examples of output I tried

Content-Disposition: attachment; filename*=utf-8''%e6%8e%a1%e7%94%a8%e3%81%ab%e9%96%a2%e3%81%99%e3%82%8b%e5%90%84%e7%a8%ae%e6%9b%b8%e9%a1%9e.pdf

No browser read that correctly. All just substituted "download" as the name.

Content-Disposition: attachment; filename=Fred.pdf; filename*=utf-8''%e6%8e%a1%e7%94%a8%e3%81%ab%e9%96%a2%e3%81%99%e3%82%8b%e5%90%84%e7%a8%ae%e6%9b%b8%e9%a1%9e.pdf

All browsers tested produced a file named "Fred.pdf; filename*=utf-8''blahblahblah"

Content-Disposition: attachment; filename="Fred.pdf"; filename*=utf-8''%e6%8e%a1%e7%94%a8%e3%81%ab%e9%96%a2%e3%81%99%e3%82%8b%e5%90%84%e7%a8%ae%e6%9b%b8%e9%a1%9e.pdf

Same as example above.

Also tried all of the above with UTF-8 instead of utf-8.

Thanks

Answer 1

Sorry for the false alarm... Turned out that the client side code fetching the data was using a jquery ajax call, and the client-side code reading the header was not doing a good job of it.

I had to track down and enhance the client side parser code.

Answer 2

All current browsers implement RFC 8187 - you probably did something wrong. It would be helpful if you posted an example field value generated by your code.