ZIP files appear corrupt when they come from a script
Eric Ellsworth
I'm wondering if anyone knows any tricks for getting IE to open ZIP
files directly from a site (using the open button). I'm basically running
into this bug:
http://support.microsoft.com/?kbid=308090
Can anyone point me to workarounds for this? I am already using
URL-rewriting, so in theory the browser does not know a script is handling
the request. Is there a header one needs to send before the file?
(more details follow).
Many thanks for any help,
Eric
I am implementing a login system for a customer's website, The site runs
IIS, with ISAPI_Rewrite to route requests through a PHP script (PHP is
running as a CGI) like so:
/protecteddir/content.zip is mapped to auth.php?file=
/protecteddir/content.zip at the server side, so, as I understand it, in
theory the browser has no idea that a script is handling the request. The
script sends the file, without any headers being sent. When I attempt to
fetch a zip file through the redirect, say, content.zip, IE (6.8.2800) first
shows a security dialog with Open, Save, etc. It is important to my client
that Open be available so users can open zip files directly from the site.
When I choose Open, IE downloads the file, then shows a message:
/C:/Documents and Settings/UserName/Local Settings/Temporary Internet
Files/Content.IE5/05KJGZ8J/content[1].htm cannot be found.
As far as I know, client thinks it's fetching a ZIP file from
/protecteddir/content.zip, but when I actually fetch the zip file directly,
everything works fine.
When I add the header:
Content-Disposition: inline; filename=content.zip, the security dialog
changes slightly (a yellow icon disappears), and clicking open now results
in a dialog saying:
The compressed (zipped) file is corrupt or invalid.
Does anyone have idea how to get around this problem? How can the browser
know if its hitting a script as a opposed to an actual file? In other
words, why does it work to fetch the file directly, but not through the
script, when the browser never sees the execution of the script.
Again, many thanks for any help.
Best regards,
Eric
Dirk
your firewall denies java applets in a http-proxy rule,
you can get this effect.
I had the same problem and this was the solution. Off
course, for safety it's best to deny java applets.
Hope this willl help you out.
Dirk
>.
>