views:

2455

answers:

1

I've been trying to get this aspx page to serve up a pdf. It works correctly in Firefox, but IE gives

Internet Explorer cannot download getform.aspx from SERVER_NAME
Internet Explorer was not able to open this Internet site. The requested site is either unavailable or cannot be found.

This is the general functionality of my code. It's spread across multiple functions (this is why we're not using WriteFile - sometimes we generate the pdf on the fly), but this is generally it:

FileStream fs = File.Open(Path.Combine(PdfBasePath, "form.pdf"), FileMode.Open, FileAccess.Read);
Stream output = Response.OutputStream;

byte[] buffer = new byte[BUFFER_SIZE];
int read_count = fs.Read(buffer, 0, BUFFER_SIZE);
while (read_count > 0)
{
    output.Write(buffer, 0, read_count);
    read_count = fs.Read(buffer, 0, BUFFER_SIZE);
}

fs.Close();

Response.Clear();
Response.ContentType = System.Net.Mime.MediaTypeNames.Application.Pdf;
Response.AddHeader("Content-Disposition", "attachment; filename=form.pdf");
Response.Output.Flush();
Response.End();

Looking at Fiddler, the page is being fetched using this:

GET /getform.aspx?Failure=Y&r=someencryptedstring HTTP/1.1

It is being returned to the browser thus:

HTTP/1.1 200 OK
Date: Thu, 09 Apr 2009 22:08:33 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Pragma: no-cache
Content-Disposition: attachment; filename=form.pdf
Cache-Control: no-cache, no-store
Pragma: no-cache
Expires: -1
Content-Type: application/pdf
Content-Length: 628548

This is really bugging me. I'm not using SSL, otherwise this KB article would seem to apply. Anyone have any ideas?

+1  A: 

Is the Content-Length being returned in the header actually correct for the file you're sending? I'm just comparing this to some production code we use here and it looks like we explicitly set the Content-Length header. If I recall correctly, some browsers have a problem if the header and the actual file size don't match.

Edit The question author found that changing the Content-Disposition header to application/download instead of application/pdf seems to work around the problem.

Ryan
Yeah, they match. Windows Explorer reports the file size to be 613 KB (628,548 bytes), or 616 KB (630,784 bytes) on the disk.
yodaj007
I assume it's failing the same for both the file-based and generated pdfs, right? Is it possible to conditionally use Response.TransmitFile() for the file-based ones and see if that fixes anything?
Ryan
I think it's the URL. I moved the code to a page without an encrypted string on the URL, and it worked ok. It looks like IE is ignoring the content-disposition header and using the name of the page, including query string, as the name of the file.
yodaj007
Your comments moved me in the right direction - IE is ignoring the content-disposition tag. A google search led me to the solution - changing the content-type header to "application/download" appears to fix the problem. I'm marking your answer as correct. Thanks for the boost.
yodaj007
Yeah, the only other thing that I found different between your code and my code is that inside the Content-Disposition header, we don't have a space between "attachment;" and "filename=blah". IE might just be barfing on the space. We do use application/pdf for our pdf files though.
Ryan