David
Tue Aug 30 01:21:30 CDT 2005
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" <JonathanPalmer@discussions.microsoft.com> wrote in
message news:AE7E0B03-8EFB-40A9-A26B-BC983EBDAF58@microsoft.com...
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]" wrote:
> 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:edZOltUmFHA.2080@TK2MSFTNGP14.phx.gbl...
> 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]" <someone@online.microsoft.com> wrote in message
> news:eKTp5kUmFHA.3936@TK2MSFTNGP10.phx.gbl...
> > 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:eCJpOaUmFHA.2152@TK2MSFTNGP14.phx.gbl...
> > 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
> >
> >
> >
>
>
>
>
>