I allow users to download files from a Windows Azure storage pool by using SAS (cf. this discussion). The SAS is being constructed and next the Request.Redirect(targetURL) is called to redirect the client's browser to download the file.
This works well using Chrome to download a file (a proprietary binary file ending on the extention .dp).
However, when downloading the same file (using the same URL) on Internet Explorer 9, the extension of the file is being changed to .zip (removing the original .dp).... Some users still use IE9 :(
I've checked the content-type of the blob, which is application/octet-stream (and hence should be correct).
Why does IE9 changes the extention of the file and what can I do to prevent this? Do I need to instruct Azure to leave the .dp file as-is (mime-type wise) and if so, how can I configure that?
edit: I really want to use redirection and not blob.openread()/response.write() to avoid additional load on the webserver.
Update 1
I've used Fiddler to see the server answer on the download request, and it is clear that the content-type is correct:
HTTP/1.1 200 OK
Content-Length: 60783
Content-Type: application/octet-stream
Last-Modified: Fri, 17 Aug 2012 13:25:24 GMT
ETag: 0x8CF4XXXE4DD2184
Server: Blob Service Version 1.0 Microsoft-HTTPAPI/2.0
x-ms-request-id: 21XXXXX-9e42-4ca8-a425-e84269d9f104
Date: Fri, 17 Aug 2012 16:49:05 GMT
The content payload of the server starts with
PK����nAQ������p����
* FIDDLER: RawDisplay truncated at 128 characters. Right-click to disable truncation. *
Does IE interprets the "PK" as PKZIP and hence beliefs it's a ZIP file?
How can this be disable (on the client side) - cf. first comment below was not the trick...
Kind regards,
Robbie De Sutter
I suspect this is just IE doing something annoying. I'd suggest changing the content type to something like application/x-foobar, maybe replacing "foobar" with something more meaningful. :-)
I haven't tested it, but I would think that's sufficient to get IE to stop trying to guess the file type.