IIS website is sending multiple content-type headers for zip files

Question

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?

Answer 1

I believe - and i may be wrong that the http 1.1 header sends multiple headers definitions and the most specific has precedence .

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 ) -

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.

Of course i may be totally wrong here

Answer 2

Make sure that you don't have any ISAPI filters or ASP.net HTTP modules set up to rewrite the headers. 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.

Answer 3

What software has been installed on the server to work with .zip files? It looks like IIS picks up MIME translations from the registry, perhaps zip-software you use has registered the MIME-type. This doesn't explain why IIS would respond with two content-type headers, so any ISAPI filter and other Mime-table is suspect.

Answer 4

This may be related to this knowledge base article. It is suggesting that IIS may be gzipping the already zipped file, but some browsers just buck pass straight to a secondary application giving you bad data (as it has been zipped twice). If you change the mime type of the zip extension to application/octet-stream this may not happen.

Answer 5

Hi

It sounds like there may be a issue with your configuration of IIS. 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

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

However I dont feel this prove much. It does however raise a few questions:

1. 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)
2. 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
3. How does the IIS log's look like, for that request, I am spesifically intrested in the Accept header.
4. I wonder what fiddler will show?

Answer 6

I've encountered a similar problem. 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