Our application use Content-Disposition header to guide browser download file and set filename. We found on Safari browser some Content-Disposition header (usually happened when Content-Disposition is very long) will be truncate and cause filename incorrect.
Here is an example:
Running with Safari 14.1.1 On MacOS 11.4 Intel
The complete response headers:
HTTP/1.1 200 OK
Server: Tengine
Date: Fri, 16 Jul 2021 02:56:46 GMT
Content-Type: application/octet-stream
Content-Length: 12919
X-Application-Context: application
x-kss-request-id: a559693f511d4f9f8b9ddfe7901df2ac
x-kss-server-side-encryption: AES256
ETag: "454cd496ee440342ac349d4ae3ed3883"
Content-MD5: RUzUlu5EA0KsNJ1K4+04gw==
Last-Modified: Thu, 15 Jul 2021 19:56:50 GMT
Content-Disposition: attachment;filename*=utf-8''%E9%99%84%E4%BB%B6%E4%B8%80%E4%B8%AA%E7%94%A8%E4%BA%8E%E6%B5%8B%E8%AF%95%E5%B9%B6%E4%B8%94%E5%90%8D%E5%AD%97%E6%AF%94%E8%BE%83%E9%95%BF%EF%BC%88%E7%89%B9%E5%88%AB%E9%95%BF%EF%BC%89%E7%8E%B0%E5%9C%A8%E5%8F%AF%E8%83%BD%E5%A4%9F%E4%BA%86%E7%9A%84%E8%A1%A8%E6%A0%BC.docx
Accept-Ranges: bytes
Connection: keep-alive
The response header in Safari borwser developer tools:
200 OK
Content-Type: application/octet-stream
Content-Disposition: attachment;filename*=utf-8''%E9%99%84%
Date: Fri, 16 Jul 2021 02:56:46 GMT
Content-Length: 12919
Connection: keep-alive
ETag: "454cd496ee440342ac349d4ae3ed3883"
Accept-Ranges: bytes
Last-Modified: Thu, 15 Jul 2021 19:56:50 GMT
X-Application-Context: application
Server: Tengine
x-kss-server-side-encryption: AES256
Content-MD5: RUzUlu5EA0KsNJ1K4+04gw==
x-kss-request-id: a559693f511d4f9f8b9ddfe7901df2ac
Content-Disposition in Safari only left a few start character.
In our test, Google Chrome and Firefox do not have this problem. Is this a bug or a feature? How to avoid this situation?