Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Problems downloading zip files from IIS 6 site

592 views
Skip to first unread message

Peter Schmidt

unread,
Aug 4, 2005, 6:47:55 PM8/4/05
to
Hi!

I have a problem with a website on IIS 6, where a zip file is published.
When someone using WinXP and IE is downloading the zip file, the file seems
corrupt when the zip file is downloaded and opened.

The specific content of the zip file is not the content is was meant to be,
it just contains one file without any file extension.
When I rename that file to e.g. .zip og unzips that one, the correct zipped
content is within this file. So it seems like the file is added an extra zip
layer, which seems weird.

When I download the same file using Firefox everything is OK.

IIS 6 is setup to use HTTP Compression.

Anyone got an idea to what might be wrong ?

Thanks in advance.

Regards
Peter Schmidt


David Wang [Msft]

unread,
Aug 4, 2005, 6:58:20 PM8/4/05
to
Well, either IIS6 and Firefox collaborated on a bug, or you have a bug with
the download provider of the ZIP file, or this is some behavior problem in
IE. IE does sniff the content data, URL extension, as well as Content-Type
header to determine what to do, so you may want to check your code and IIS
configuration to make sure things are actually all kosher.

By default, IIS6 is not configured to compress .zip files. Thus, you are
currently adding configuration that actually cause this issue. So, you may
want to consider configuring IIS6 to NOT re-compress compressed content like
.ZIP, which should also resolve this issue.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Peter Schmidt" <peterATschmidtDOTdk> wrote in message
news:eCJpOaUm...@TK2MSFTNGP14.phx.gbl...

Peter Schmidt

unread,
Aug 4, 2005, 7:22:31 PM8/4/05
to
Hi David

Thanks for the info. I know IIS 6 isn't suppose to compress zip files, but
it seems to do so in my case.

In the meanwhile I did some testing with disabling the HTTP Compression and
then my downloads of the zip file works great.
As soon as I re-enable I have the same problem again.

I've found that I can disable the HTTP Compression for Application files and
still keep the compression for static files, this "workaround" seems to work
with the zip file, so the downloads will be ok.

Is there a way to setup the compression in the metabase, not to use or do
anything with zip files at all ?

Thanks
/Peter


"David Wang [Msft]" <som...@online.microsoft.com> wrote in message
news:eKTp5kUm...@TK2MSFTNGP10.phx.gbl...

David Wang [Msft]

unread,
Aug 5, 2005, 4:09:06 AM8/5/05
to
It sounds like your server is NOT configured to download .zip files as a
static file by IIS, so your work-around of disabling dynamic compression is
the only choice.

What I mean is this -- IIS has two algorithms for determining content to
compress:
1. Static Compression -- selected by extension of requests served by the IIS
static file handler
2. Dynamic Compression -- selected by extension of requests served by either
script engines, ISAPI DLL, CGI EXE

Normally, .zip is considered a static file since no script engine is
configured for it -- IIS static file handler serves it -- and it is subject
to static compression (and since .zip is not configured by default, .zip
will not be static compressed).

However, your server is configured to use a script engine, ISAPI DLL, or CGI
EXE to serve a .zip file download. This is now considered dynamic
compression because from IIS perspective, it executed a script engine to
handle the request and was told to dynamically compress the output of the
script engine. It so happens that the data being output by the script engine
is a .zip file, but still, it is considered dynamic compression.


You can get this behavior when using something like Sharepoint, which uses
an ISAPI DLL to generate all responses -- so to IIS, all responses are
dynamic -- even if Sharepoint is simply downloading a static .zip file to
the browser. This is why disabling dynamic compression stopped the
compression of .zip files.


--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Peter Schmidt" <peterATschmidtDOTdk> wrote in message

news:edZOltUm...@TK2MSFTNGP14.phx.gbl...

Jonathan Palmer

unread,
Aug 29, 2005, 11:56:02 AM8/29/05
to
I am facing the same problem - using compress application files leads to zip
files being corrupted.

However, I can't see why IIS is treating zip files like application files.
I have checked the configuration for the application and the zip extension is
not recorded there. How can I figure out why the zip file is being treated
as an application file?

David Wang [Msft]

unread,
Aug 30, 2005, 2:21:30 AM8/30/05
to
I already explained why .zip extension can be treated as an application
file. Copy/pasted again. The logical extension of the resource means
nothing -- it all depends on the handler that handled the requested URL.


Normally, .zip is considered a static file since no script engine is
configured for it -- IIS static file handler serves it -- and it is subject
to static compression (and since .zip is not configured by default, .zip
will not be static compressed).

However, your server is configured to use a script engine, ISAPI DLL, or CGI
EXE to serve a .zip file download. This is now considered dynamic
compression because from IIS perspective, it executed a script engine to
handle the request and was told to dynamically compress the output of the
script engine. It so happens that the data being output by the script engine
is a .zip file, but still, it is considered dynamic compression.

You can get this behavior when using something like Sharepoint, which uses
an ISAPI DLL to generate all responses -- so to IIS, all responses are
dynamic -- even if Sharepoint is simply downloading a static .zip file to
the browser. This is why disabling dynamic compression stopped the
compression of .zip files.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//

"Jonathan Palmer" <Jonatha...@discussions.microsoft.com> wrote in
message news:AE7E0B03-8EFB-40A9...@microsoft.com...

David Wang [Msft]

unread,
Sep 1, 2005, 8:46:41 PM9/1/05
to
Based on your description, your server is using ISAPI. That is what ASP.Net
is (to IIS, anyway). Thus, the fact that you have dynamic compression
enabled for ASPX pages is what is causing your ZIP file to be compressed.

What is happening is that you post back to an ASP.Net page (whose file
extension is configured for dynamic compression), and the page delivers the
ZIP file as a download as its generated response. This is why the resource
is compressed.

I will check on this to see whether the problem is either:
1. IIS doing the compression incorrectly
2. IIS is sending the wrong HTTP headers to IE to confuse it
3. IE is confused by HTTP headers for other reasons
4. IE is decompressing incorrectly.

My suspicion right now is that IE is doing #4 incorrectly because it sniffs
HTTP response and does some "automatic" things regardless of HTTP headers
being sent -- and the automatic sniffing is wrong somehow.

Since you are observing a problem with a zip file being dynamically
compressed, the only work around is to not get in a state where a ZIP file
is sent by a resource extension which is configured for dynamic compression.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Jonathan Palmer" <Jonatha...@discussions.microsoft.com> wrote in

message news:13247B17-4EFF-408F...@microsoft.com...
"David Wang [Msft]" wrote:

> I already explained why .zip .... your server is configured to use a


script engine, ISAPI DLL, or CGI

My server is not using isapi or cgi as far as I can detect. It is using
pure asp.net. The user clicks a javascript link that creates a postback to
an asp.net page which delivers the page for download.

This leaves me with two questions:
i) Is this a bug in IIS or in IE? (Even if it makes no sense to compress zip
files, it shoudn't lead to them being corrupted)
ii) How can this problem be worked around if we need compression on our
site?


David Wang [Msft]

unread,
Sep 1, 2005, 9:04:16 PM9/1/05
to
Actually, there is one more possibility, since you are using ASPX page to
send a ZIP file:
5. ASPX code is not setting the right content-type for the download, thus
confusing the client.


Thus, I need you to first prove that you are sending a properly encoded HTTP
response when your ASPX code is sending a ZIP file for download. A network
sniff of just the response headers is sufficient proof.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//

"David Wang [Msft]" <som...@online.microsoft.com> wrote in message

news:ewjIxg1r...@TK2MSFTNGP10.phx.gbl...

Jonathan Palmer

unread,
Sep 2, 2005, 1:30:03 PM9/2/05
to
David

I am not sure how to sniff the response. Can you provide brief guidance.

Alternatively, if you click here:
http://inttest.wcs.org/portal/Home/Transfer/tabid/332/Default.aspx
and you will see a zip file called David Wang Demo. Clicking on the blue
download icon between the title and the date will initiate the download and
recreate the problem.

Thanks again.

Jonathan

David Wang [Msft]

unread,
Sep 3, 2005, 2:58:47 AM9/3/05
to
The server (inttest.wcs.org) is not resolving for me so I cannot retrieve
the ZIP file and see the response.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Jonathan Palmer" <Jonatha...@discussions.microsoft.com> wrote in

message news:AB041C64-9ACA-44C3...@microsoft.com...

0 new messages