views:

1650

answers:

5

I am trying to respond back to a client with a PDF stored in a MSSQL varbinary(MAX) field. The response works on my localhost and a test server over http connection, but does not work on the production server over https connection. I am using just a simple BinaryWrite (code below).

    byte[] displayFile = DatabaseFiles.getPdfById(id);

    Response.ContentType = "application/pdf";
    Response.BinaryWrite(displayFile);

Nothing fancy here. Just grab the binary data, set the content type, and write back to client. Is there anything special that needs to be done in order to respond back over https in this way?

Edit: By doesn't work, I mean that I get a blank document in the browser. Acrobat does not load in browser.

Edit: I just noticed that this problem is only occurring in IE 7. The PDF loads correctly in Firefox 3. Our client uses IE 7 exclusively (better than IE 6 which I persuaded them upgrade from...lol).

Edit: Tried to add the header "content-disposition" to make the file act as an attachment. Browser failed to loaded under SSL with the IE error "Internet Explorer cannot download displayFile.aspx from ProductionServer.net." (Code Below)

    byte[] displayFile = DatabaseFiles.getPdfById(id);
    Response.Clear();
    Response.AddHeader("content-disposition", String.Format("attachment;filename={0}", fileName));
    Response.ContentType = "application/pdf";
    Response.BinaryWrite(displayFile);

Edit: If the file is viewed over http on the Production Server, the browser displays the code for the PDF like it was being viewed through NotePad. (e.g. %PDF-1.4 %âãÏÓ 6 0 obj <> endobj xref 6 33 ...etc)

A: 

I ran into kind of the same problem a couple of years back. The solution we found were not the most beautiful one. We wrote the file to disk and did a Response.Redirect to it.

Jonas Elfström
A: 

Can you use Wireshark (or similar) to see what's getting to the client?

Kevin Tighe
What data in Wireshark am I looking for? I see the first request under a TLSv1 protocol. I have the tool but don't really know how to make sense of the results. Thanks.
Eddie
Fiddler would probably be better for this sort of thing.
Mark Brackett
Just posted the raw request from Fiddler
Eddie
+1  A: 

IE 7 has/had a mime type "issue" with PDF, related to the convoluted mime type rules. You may want to verify if the client has that patch.

There's also been sporadic complaints of IE 7 blank pages due to other reasons (script tags, response.flush, and keepalives among them) that, AFAIK, have not been reliably solved.

Luckily, it sounds like this is happening every time - so you should be able to get to the bottom of it fairly quickly.

You can try associating .pdf with ASP.NET, so that the url is picked up as a PDF file by IE. That should override the mime type issue.

Redirects (HTTP Response.Redirect, Javascript based, and links) seem to help some other issues.

Checking IIS keepalive settings on the production server, or watching with Fiddler, will show you if keepalives are an issue.

Maybe adding a content-disposition header would help...That's off the top of my head, though.

My guess is that the SSL relation is a red herring, so I'd check with non-SSL on the production server as well.

Mark Brackett
A: 

Here is the raw request as viewed in Fiddler

GET /displayFile.aspx?id=128 HTTP/1.1
Accept: */*
Accept-Language: en-us
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618)
Host: ProductionServer.net
Connection: Keep-Alive

Edit: Here are the raw Response Headers as viewed in Fiddler

HTTP/1.1 200 OK
Date: Wed, 10 Dec 2008 18:39:54 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Cache-Control: no-cache
Pragma: no-cache
Expires: -1
Content-Type: application/pdf; charset=utf-8
Content-Length: 102076
Eddie
The response headers would be helpful too...
Mark Brackett
Added the response header.
Eddie
+4  A: 

I just managed to get around this by replacing

Response.Clear();

with

Response.ClearContent();
Response.ClearHeaders();

so the whole thing looks like:

byte[] downloadBytes = doc.GetData();
Response.ClearContent();
Response.ClearHeaders();

Response.Buffer = true;
Response.ContentType = "application/pdf";
Response.AddHeader("Content-Length", downloadBytes.Length.ToString());
Response.AddHeader("Content-Disposition", "attachment; filename=myFile.pdf");
Response.BinaryWrite(downloadBytes);
Response.Flush();
Response.End();
that works.. thanks bud..
Jeeva S