We have a problem with an IIS5 server.
When certain users/browsers click to download .zip files, binary gibberish text sometimes renders in the browser window. The desired behavior is for the file to either download or open with the associated zip application.
Initially, we suspected that the wrong content-type header was set on the file. The IIS tech confirmed that .zip files were being served by IIS with the mime-type "application/x-zip-compressed".
However, an inspection of the HTTP packets using Wireshark reveals that requests for zip files return two Content-Type headers.
- Content-Type: text/html; charset=UTF-8
- Content-Type: application/x-zip-compressed
Any idea why IIS is sending two content-type headers? This doesn't happen for regular HTML or images files. It does happen with ZIP and PDF.
Is there a particular place we can ask the IIS tech to look? Or is there a configuration file we can examine?
IIS 6, tool to copy all site host headers?
Sorting web sites in IIS
How do I programatically disable Etags in iis 6
so in your example here it is sending 2 text/html and then application/x-zip-commercial so the second one would be the most specific - if that cant be handled on the client then the more general one is used (the first one in this case ) - .
ABCpdf doesn't render images in an web application under IIS6
I have read through this http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html and that sort of points to what you are saying - not sure if this is what is actually happening though..
IIS App Pool recycles don't appear to observe the specified schedule
Of course i may be totally wrong here .
Does restoring a backup of IIS6 restore the GAC?
Will creating a new app pool disrupt anything in IIS 6?
How to install iis 6.0 on windows xp-32?
If they don't check to see if the header already exists, it will be appended rather than replaced.
We had issues a while ago with an in-house authentication module not correctly updating the headers so we were getting two Authorization headers, one from IIS and one from our module..
This doesn't explain why IIS would respond with two content-type headers, so any ISAPI filter and other Mime-table is suspect..
If you change the mime type of the zip extension to application/octet-stream this may not happen.
However that is not possible to tell from your post if this is the case.. You can have mime types configured on several levels on your IIS.
My IIS 5 knowledge is a bit rusty, as far as I can remeber this behavior is the same for IIS 6.
I tried to simulate this on a IIS 6 enviroment, but only ever received one mime type depending on the accepted header. I have set the the header for zip files on the site to application/x-zip-compressed and for the file I have explicity set it to .
However I dont feel this prove much.
tinyget -srv:dev.24.com -uri:/helloworld.zip -tbLoadSecurity WWWConnect::Connect("server.domain.com","80") IP = "127.0.0.1:80" source port: 1581 REQUEST: ************** GET /helloworld.zip HTTP/1.1 Host: server.domain.com Accept: */* RESPONSE: ************** HTTP/1.1 200 OK Content-Length: 155 Content-Type: text/html Last-Modified: Wed, 29 Apr 2009 08:43:10 GMT Accept-Ranges: bytes ETag: "747da786a6c8c91:0" Server: Microsoft-IIS/6.0 Date: Wed, 29 Apr 2009 10:47:10 GMT PK?? ? ? ? helloworld.txthello worldPK??¶ ? ? ? ? helloworld.txtPK?? ? ? < 7 ? hello world sample WWWConnect::Close("server.domain.com","80") closed source port: 1581
It does however raise a few questions:.
- What is all the mime maps that have been setup on the server (ask the server admin for the metabase.xml file, and then you can make sure he has not missed some setting)
- Is those clients on a network that is under your control? Probably not, I wonder what proxy server might be sitting inbetween your server and the clients
- How does the IIS log's look like, for that request, I am spesifically intrested in the Accept header.
- I wonder what fiddler will show?
I was testing downloads on IIS 6 and couldn't figure out why a zipped file called test.zip was displaying as text in IE8 (it was fine in other browsers, where it would download).
. Then I realised that for the test I'd compressed a very small text file.
My guess is that IE sniffed the file, saw the text (which was pretty much uncompressed because of the small size) and decided it was plain text.. I tried again with a larger file and the download prompt appeared OK in IE8.. May not be relevant to your case, but thought I'd mention it.. Tim.