Re: IE, IIS Dynamic compression and corrupt zip files
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.