The filename is decoded wrongly on Safari
Closed this issue · 1 comments
I'm opening this issue because:
-
I have found a bug
-
My Go version / GOPATH is: N/A
(N/A because I use the pre-compiled binary.)
How to Reproduce
touch 啊.txt
# ISO/IEC 8859-1 (Latin 1) does not contain 啊
qrcp send 啊.txt
Then open the link in iOS Safari. You'll find å.txt
.
Reason
The filename is declared in UTF-8 as \xe5\x95\x8a.txt
in the header Content-Disposition
, but Safari interprets it in ISO/IEC 8859-1 as å\x95\x8a.txt
.
# Inspect the response with HTTPie
$ https http://*.*.*.*:**/send/****
HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Disposition: "attachment; filename=\xe5\x95\x8a.txt"
Content-Length: 110
Content-Type: text/plain; charset=utf-8
…
Possible solution
Add filename*
in Content-Disposition
.
Lines 222 to 223 in 8b35ad8
§4.3. Disposition Parameter: 'Filename' - RFC 6266:
The parameters
filename
andfilename*
differ only in thatfilename*
uses the encoding defined in [RFC5987], allowing the use of characters not present in the ISO-8859-1 character set ([ISO-8859-1]).
Appendix D. Advice on Generating Content-Disposition Header Fields - RFC 6266:
Include a
filename*
parameter where the desired filename cannot be expressed faithfully using thefilename
form. Note that legacy user agents will not process this, and will fall back to using the "filename" parameter's content.
Content-Disposition: attachment;
filename="EURO rates";
filename*=utf-8''%e2%82%ac%20rates
The syntax of the value of filename*
is specified in RFC 5987 §3.2.1:
ext-value = charset "'" [ language ] "'" value-chars
; like [RFC 2231](https://www.rfc-editor.org/rfc/rfc2231)'s <extended-initial-value>
; (see [[RFC2231], Section 7](https://www.rfc-editor.org/rfc/rfc2231#section-7))
I can make a PR if you want.
I guess #253 should work?
It drops filename
, which is against RFC 6266.