Using DynamicFileDownloader does not work with mobile version of Safari in iOS. Instead of downlading the file with the given filename, Safari adds a ".html" to the original filename and stores any data as text file.
Example trying to download a .pdf file:
Other than other browsers, mobile Safari does not take the file ending as a guess for the mime type, instead it expects a http Content-Type header.
I want to recommend adding Content-Type header to every response. RFC2046 defines mime type application/octet-stream as an "arbitrary binary data" which could be used as a default value for unknown binary data. Browsers will use file ending to determine it in this case.
As the download button will most likely be used in the context of web browsers, I think it is safe to always provide a Content-Type.
Adding the Content-Type (no matter octet-stream or real mime type) will allow correct file download handling in mobile Safari.
Using
DynamicFileDownloaderdoes not work with mobile version of Safari in iOS. Instead of downlading the file with the given filename, Safari adds a ".html" to the original filename and stores any data as text file.Example trying to download a .pdf file:
Other than other browsers, mobile Safari does not take the file ending as a guess for the mime type, instead it expects a http
Content-Typeheader.I want to recommend adding
Content-Typeheader to every response. RFC2046 defines mime typeapplication/octet-streamas an "arbitrary binary data" which could be used as a default value for unknown binary data. Browsers will use file ending to determine it in this case.As the download button will most likely be used in the context of web browsers, I think it is safe to always provide a Content-Type.
Adding the Content-Type (no matter octet-stream or real mime type) will allow correct file download handling in mobile Safari.
Please find attached a pull request.
More resources: