We have a download page which is sending files from a database down to a
browser. The web server is Windows Server 2003 SP2 with IIS6 the
application is an ASP.NET app running on .net 3.5. IIS is configured to
compress static files and dynamic pages - including the aspx extension.

When downloading a zip file from our site - which is subsequently also
compressed by IIS (yes unnecessarily) the zip file is corrupted when
downloaded by IE 6,7 and 8. Firefox, Safari, Google Chrome all handle
the download without issues.

We believe the correct http headers are being sent, along with the
typical cotent-disposition we're sending:
Content-Type application/x-zip-compressed (or application/zip)
Content-Encoding gzip

If the content-type is changed to 'application/octet-stream', IE then
handles the file correctly. In our application we specifically handle
this case but wondered if it had ever been reported or reproduced under IE?

The file is downloaded over a secure connection (SSL) if this makes any
difference to IE's behaviour and if anyone needs my metabase settings
along with a simple ironpython or c# aspx sample I can supply these to
recreate the problem.


Darren

"Darren Syzling" <dsyzling******.com.discuss> wrote in message news:eTncKAD6JHA.1416@TK2MSFTNGP04.phx.gbl...
> We have a download page which is sending files from a database down to a
> browser. The web server is Windows Server 2003 SP2 with IIS6 the
> application is an ASP.NET app running on .net 3.5. IIS is configured to
> compress static files and dynamic pages - including the aspx extension.
>
> When downloading a zip file from our site - which is subsequently also
> compressed by IIS (yes unnecessarily) the zip file is corrupted when
> downloaded by IE 6,7 and 8. Firefox, Safari, Google Chrome all handle
> the download without issues.
>
> We believe the correct http headers are being sent, along with the
> typical cotent-disposition we're sending:
> Content-Type application/x-zip-compressed (or application/zip)
> Content-Encoding gzip
>

> If the content-type is changed to 'application/octet-stream', IE then
> handles the file correctly. In our application we specifically handle
> this case but wondered if it had ever been reported or reproduced under IE?


Check to see if the file is cached in each case.


>
> The file is downloaded over a secure connection (SSL) if this makes any
> difference to IE's behaviour and if anyone needs my metabase settings
> along with a simple ironpython or c# aspx sample I can supply these to
> recreate the problem.


There is an option about caching which may be related to that:
Do not save encrypted pages to disk
(in Options, Advanced tab, Security section)


If those guesses don't help I would use ProcMon to compare the details
of the cases, again focusing initially on how the TIF was used.


HTH

Robert Aldwinckle
---

Robert,

Thanks for your reply/help.

Robert Aldwinckle wrote:
>
> Check to see if the file is cached in each case.
>
>

When you say - check to see if the file is cached, do you mean check if
we're setting headers to cache the resulting file on the user's browser
or check if in my particular instance the file has been downloaded and
cached already? For the latter point, the file is not in my browser
cache and we have users of our application reporting this problem
reliably. On the first point all of our aspx pages are treated as
dynamic uncacheable data and we do not set cache headers on these pages.

>
> There is an option about caching which may be related to that:
> Do not save encrypted pages to disk
> (in Options, Advanced tab, Security section)

I believe the default setting for that option is disabled, i.e.
encrypted pages will be saved to disk. In my case it is disabled.

> If those guesses don't help I would use ProcMon to compare the details
> of the cases, again focusing initially on how the TIF was used.

Sorry not following here, how are you suggesting to use procmon, to look
at the resulting file being created locally when downloaded?

From an external point of view it looks as if IE is failing to
decompress an already compressed file. So the zip file is sent and IIS
is then compressing the response with zipped attachement. However IE is
then not dealing correctly with the compressed zip and the behaviour
differs based on the mime type we send down.

Like I said if we change the header mime type for the zip to
octet-stream it handles it fine, but if it's set to application/zip or
one of the many zip alternatives it chokes. All other browsers handle
this case fine.

For now our application treats this as a special case and looks for the
agent string and the file extension being sent and adusts the mime type
dynamically to deal with the IE case.



Darren

Hi,

Why not try Advanced Zip Repair at Advanced Zip Repair - Repair corrupt Zip files. Fix Zip files. ? It recovers several important Zip files for me and is really helpful!

Alan