Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

content-disposition: inline pdfs not displaying

Status
Not open for further replies.

Kavius

Programmer
Apr 11, 2002
322
CA
My scenario is that a user requests a file from a webpage, the page authenticates them and verifies their security level, then gives them the requested file. For some reason this works with every filetype except PDFs (zips, csv, xls... all good).

Can anyone identify what I am doing wrong?
[tt]
fs = File.Open(strPath & "\" & strFileName, FileMode.Open)
dim bytBytes(fs.Length) as Byte
fs.Read(bytBytes, 0, fs.Length)
fs.Close

with Response
.Clear()
.AddHeader("content-disposition", "inline; filename=" & strFilename)
.ContentType = strContentType
.Write(strContentType)
.BinaryWrite(bytBytes)
.End()
End With
[/tt]
I can save PDFs to file by right-clicking, but cannot view them in the browser. I did place a PDF on the file-system, to make sure Adobe isn't broken, and it displayed without a problem.

Could it have something to do with the way I am reading the file?
 
kavius

I have the same problem, almost. My code is virtually identical to yours, except I do a .Flush() followed by a .Close() instead of .End()

I'm assuming that strContentType = "application/pdf" in your example.

What happens is on Win 2003 server/ IE6 / Adobe Reader 7 it renders OK in about 10 seconds. But on Win2K / IE6 / Adobe Reader 7 I get a blank screen initially, with no hourglass unless I move the cursor to the border of the browser. After about 6-7 MINUTES, the PDF displays.

Try running it again, and just leave the browser for about ten minutes to see if it eventually displays the PDF.

I've tried it with and without the Content-Disposition header, and it's exactly the same. Currently, I'm trying to get a trace of what ASP.NET is putting out to the wire without writing a filter (see the zero responses on thread855-1111865). Let me know how you get on...
 
application/pdf is correct. I am also sending things like excel files and zips, so I need to look that up. I did double check that the correct value is going in.

I'm running wXP/IE6/Adobe Reader 6. After 15 minutes, nothing loads. I did notice that when I open it with mozilla, I get an error stating the PDF is damaged.

Another thing I noticed was that at one point I was able to view source. I was receiving HTML. Something to this effect:
[tt]
<html>
<body>
<embed height=100% width=100% href=' />
</body>
</html>
[/tt]
It's embedding itself?

When I look at the PDF window now, the border does appear to be double deep (indicating to me that there is an embedded object).
 
Try changing your .End() to .Flush() and .Close(), it might get rid of the HTML.

For Excel, try application/vnd.ms-excel, and for word documents application/msword. Don't know about zip files, though.

Anybody know how to get an image of what ASP.NET sends back to the browser without using a browser? Normally I'd use wget or write a script to do it, but our security package prevents me from doing this. I had hoped for some kind of config option to do it, but Trace doesn't give me what I want.
 
Tried the .End() and .Flush, it didn't seem to make a difference.

Ya, I have a big list of mime types I found somewhere a long time ago, so I have all of those. Zip is "archive/zip".
 
Have you tried changing the content-disposition to attachment for pdf's? This might correct the issue you are having. Also you might want turn on response buffering: Response.Buffer = True, just don't forget to turn it back off after you have flushed your response, this should eliminate the 6-7 minute delay rendering the document. I also noticed in the original post that there is a line that reads ".Write(strContentType)" just before the line that calls the BinaryWrite method. Why are you doing that? Nothing should be written to the response stream except the bytes of the file that you want to push to your users - I think that may have something to do with your problem.

 
> .Write(strContentType)

Oops, should have removed that for the post. That was a temporary thing just to make sure the content type was getting pulled correctly. If you throw that in place you get a text dump and it doesn't work at all.

For now I am just copying the file to a temporary folder and linking to that, so this isn't as desperate anymore. Unfortunately, that leaves a short window where the files are accessable to anyone (I delete the file after a minute).

I'll double check the buffering.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top