Reputation: 705
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:
I tried
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
Upvotes: 3
Views: 1701
Reputation: 705
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.
Upvotes: 0
Reputation: 42055
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.
Upvotes: 1