• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

SOLVED - Problem retrieving a PDF file stored in SQL Server in an ASP.NET application

cyberia

Platinum Member
I have been scratching my head trying to fiigure out what is going on here. Any help would be appreciated.

I have an ASP.NET application, written in VS 2008 and running on Server 2008, that allows a user to upload PDF files which are then displayed in a list and can be viewed/downloaded. The files are stored in a SQL table as a binary field.

Problem: Two recently uploaded PDF files cannot be retrieved for viewing or download. I get the following error in Acrobat Reader: "There was an error opening this document. The file is damaged and could not be repaired".

Here is the strange part:
  • Previously uploaded files work fine
  • An identical copy of the web application running on a Windows Server 2003 box does NOT have this problem

I am leaning toward blaming a weird sequence of bytes in the PDF file that may be triggering a security violation on IIS7/Server 2008 that causes it to interrupt the response. But I can't exactly pinpoint it.
 
Last edited:
1) Did you recently move it to Server 2008, and if you upload a new file does it work? Are you sure it's not the upload process that is faulty? Well, I guess the identical copy rules this out, but its worth a guess.

2) Can you verify the file size? IIS really wouldnt randomly change bytes around. Maybe its sending a 0kb File? Or you are hitting the max response limit, and it's cutting the response off early (if its a very large PDF)

3) Is the identical copy using the same datasource?
 
If you use a packet sniffer like WireShark or an in-browser tool like IEWatch or Fiddler you can look at the server response headers, including the content type, content length, and response body.
 
1) No, it has been on this 2008 box for a while. The upload process and the data stored in the SQL Server must be OK because the retrieval works on the 2003 box.

2) The file is under 18KB. The retrieval gets cut off somewhere around 16,700 Bytes. (The upload uploads the entire 18KB since the entire file can be retrieved on the 2003 mashine). I experimented with dummy PDF files of various sizes, both smaller and larger: They all get uploaded and are later retrieved properly.

3) Yes, both servers (2003 and 2008) point to the same database on a stand-alone SQL server.

I was able to work around this problem by optimizing the problem PDF file, which I am sure changed the byte sequence around the "cut-off point". But I still don't get what exactly causes the problem (and thus can't prevent this from happening in the future).
 
If you use a packet sniffer like WireShark or an in-browser tool like IEWatch or Fiddler you can look at the server response headers, including the content type, content length, and response body.

I just tried that using the Live HTTP Headers extension in FF. Here is what I get:

Code:
HTTP/1.1 200 OK
Cache-Control: private
Transfer-Encoding: chunked
Content-Type: text/html
Content-Encoding: gzip
Vary: Accept-Encoding
Server: Microsoft-IIS/7.5
Content-Disposition: attachment;filename=test123.pdf
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
Date: Wed, 30 May 2012 18:23:43 GMT

Nothing out of ordinery to my eye. Or should the Content-Type be something else, like application/pdf?
 
> Content-Type: text/html

What is the content-type from the 2003 server? I'd expect something like:
Content-type: application/pdf
 
> Content-Type: text/html

What is the content-type from the 2003 server? I'd expect something like:
Content-type: application/pdf

Nope, the same thing. Same Framework version too. But there is no Content-Encoding header. Hmm...

HTTP/1.1 200 OK
Date: Wed, 30 May 2012 19:10:49 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Content-Disposition: attachment;filename=test123.pdf
Transfer-Encoding: chunked
Cache-Control: private
Content-Type: text/html
 
Yep, that was it: I had to disable dynamic content compression for this web application in the IIS settings.

Thank you for nudging me toward the right path.
 
What browser were you using?

This is a known bug in IE - downloaded files are corrupted when dynamic compression is switched on, and the content type is anything other than "application/octet-stream".

But browsers like chrome, firefox and safari will download the files correctly.
 
What browser were you using?

This is a known bug in IE - downloaded files are corrupted when dynamic compression is switched on, and the content type is anything other than "application/octet-stream".

But browsers like chrome, firefox and safari will download the files correctly.

I actually had that issue with that particular file (but not others) in all three browsers.
 
I have exactly the same problem, what I have noticed is that the PDF file versión that can't be retrieved is higher than 1.4 (Acrobat 5.x) , for that version there is no problem retrieving the PDF file. Am I right? how can I solve it?
 
I have exactly the same problem, what I have noticed is that the PDF file versión that can't be retrieved is higher than 1.4 (Acrobat 5.x) , for that version there is no problem retrieving the PDF file. Am I right? how can I solve it?
Wow, this is an oldie - and welcome to AT. I haven't been to the forums in a long while too. 😱

I don't remember the specifics, but here is what I posted as the solution at the time:
I had to disable dynamic content compression for this web application in the IIS settings.
Hope this helps.
 
Wow, this is an oldie - and welcome to AT. I haven't been to the forums in a long while too. 😱

I don't remember the specifics, but here is what I posted as the solution at the time:

Hope this helps.
Yes I know it was an old post, sorry 🙁 shame on me ...lol.. Ok, I will try what you say and let you know, thanks a lot !
 
Back
Top