Sending Zip file from Database problems

[Frostillicus]

I'm trying to get an ASP to return a zip file to the remote browser from an
Image (BLOB) field in SQL Server 2000 but Internet Explorer keeps saying:

Cannot open C:\Documents and Settings\Frostillicus\Local Settings\Temporary
Internet Files\Content.IE5\U7GXENGF\file[1].zip

The URL to open the zip file is like this: doc_view.asp?id=1&ver=2

....where id and ver represent the zip file's version in the database. The
code I've pieced together to return the zip file is as follows (note: this
code works fine for PDF, JPG, DOC, XLS, GIF, and all sorts of files - just
not zip - HOWEVER, if I click "save" instead of "open" in the download box
then open the zip file manually, it works fine - Internet Explorer just
won't load WinZip for me automatically)

<% @language="VBScript" %>
<!-- #include file="./include/adovbs.inc" -->
<%
Response.Buffer = True
Response.Clear

Set RS = Server.CreateObject("ADODB.Recordset")

SQL = "SELECT ContentTypeString, DocumentData, DocumentTitle, FileExtension,
DocumentContentLength FROM DocumentVersion "
SQL = SQL & "WHERE (DocumentID = " & id & ") AND (VersionNumber = " & ver &
")"

Set RS = DbConn.Execute(SQL)

If Not RS.EOF Then
Response.ContentType = RS(0)

' zip file needs to be 1 byte more for some silly reason
If Not RS(0) <> "application/zip" Or Not RS(0) <>
"application/x-zip-compressed" Then
Response.AddHeader "Content-Length", RS(4) + 1
Else
Response.AddHeader "Content-Length", RS(4)
End If

Response.AddHeader "Content-Disposition", "filename=" & RS(2) & "." &
RS(3)
Response.BinaryWrite RS(1)

If Not RS(0) <> "application/zip" Or Not RS(0) <>
"application/x-zip-compressed" Then
Response.Write vbCrLf
End If
End If

RS.Close
Set RS = Nothing
Response.Flush
%>

The conscientious among us might say "what's the extra vbCrLf being printed
for, then"? Well, without the final carriage return I get a corrupt zip file
that is at least capable of being repaired. I have no idea why I need the
last carriage return but I decided to stick it in there after I saw (using
HTTP Watch to spy on the headers received) that the same zip file downloaded
via a normal hyperlink was one byte larger than the same zip file being
served up from the database (the binary data saved to the database is the
same length as the content-length for the normal hyperlinked zip file). So,
when I get the download-file box in Internet Explorer, if I click "Save"
then open the zip file manually, it works just fine.

If I click "Open", I get the nasty error message mentioned at the beginning
of this prolix post :-( I am tearing my hair out because this sort of thing
just ain't supposed to be this god-damned difficult. I mean, it's just a
stream of binary data and I'm sending the correct content types. What is so
special about Zip files?

 

[Frostillicus]

By the way, I've tried clearing my cache, rebooting, etc. I even browsed to
the directory where IE is trying to save the file using a command-prompt,
and the directory does actually exist, and there are copies of other files I
have downloaded using this save "doc_view.asp" file, but the zip file just
ain't there.

I also tried sending the "application/octet-stream" content-type, no luck.

 

[Dave Anderson]

I'm trying to get an ASP to return a zip file to the remote browser
from an Image (BLOB) field in SQL Server 2000 but Internet Explorer
keeps saying:

Cannot open C:\Documents and Settings\Frostillicus\Local
Settings\Temporary Internet Files\Content.IE5\U7GXENGF\file[1].zip

The URL to open the zip file is like this: doc_view.asp?id=1&ver=2

...where id and ver represent the zip file's version in the database.
The code I've pieced together to return the zip file is as follows
(note: this code works fine for PDF, JPG, DOC, XLS, GIF, and all
sorts of files - just not zip - HOWEVER, if I click "save" instead of
"open" in the download box then open the zip file manually, it works
fine - Internet Explorer just won't load WinZip for me automatically)

My guess: Mozilla and Opera do not display this error, and the ASP script
(a) sits behind NTLM authentication, or (b) depends on cookies (directly or
for session variables).

See the notes on these articles:
http://support.microsoft.com/?id=264143
http://support.microsoft.com/?id=185978

It appears that IE sometimes "loses" request information when handing the
response off to helper apps:

"Internet Explorer can sometimes lose information pertinent to a
particular download for an Active Document server (Word, Excel.)
When this occurs, Internet Explorer is able to activate the Active
Document server but when the server attempts to bind to and read
the data for the document, Internet Explorer re-downloads the
document from the context of the server.

When the server is an out-of-process local server, the second
download is treated as a new session with the Web server."


--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.