New Forum | Previous | Next | (P-PDF) Developers
Topic: Bad - Reader 7 with Compressed HTTP Responses
Conf: (P-PDF) Developers, Msg: 129614
Date: 3/18/2005 04:20 AM
Ran into a problem with a customer using Acrobat 7 (just upgraded). The system I'm trying to fix is using a library to create PDF's on the fly in conjunction with GZIP compressed HTTP Responses.
This system has been in PROD for more than a year with no problems until now.
Apparently, the latest version of Adobe Acrobat Reader (Version 7) has a new requirement that none of the previous version had. This new requirement makes it fundamentally incompatible with compressed streams under certain circumstances.
The new version of Adobe Acrobat Reader requires that you (the server) send the file size on the response (called the "Content-Length" attribute of any HTTP Response header). Basically, this means that if you (the server) are about to send the client a 300K PDF file, you MUST now set the "Content-Length" to 300k (this is usually in bytes).
The problem arises with compression. Although the file you are sending may be 300k originally, when it is delivered to the client in compressed format it is going to be smaller. This is usually handled by one of two ways:
A) Not setting the "Content-Length" attribute on any compressed streams. This usually has no effect other than to make progress bars either not function or be inaccurate since they cannot calculate your progress without a known end point.
B) Setting the "Content-Length" to the compressed value of the size
Option "A" is probably the most common since you can't calculate the compressed size of the stream about to be returned unless you can hold the entire thing in memory before you send it back to the client.
Option "B" does NOT work with Acrobat 7 and IE (it DOES work with Mozilla however).
Basically Adobe runs on top of the browser and really has no idea that the thing it just received was compressed. By the time Adobe sees the PDF, the browser has already uncompressed the file. However, the "Content-Length" header attribute is still the compressed size (< 300K). The Acrobat plug-in yells about a corrupted file because the actual file size does not match the stated file size. Mozilla seems to be smart enough to take care of this.
A tried a few different things. I tried sending the compressed stream with while setting the "Content-Length" to the uncompressed size. This caused Mozilla not to function. However, IE would then work SOMETIMES. This causes various protocol errors on the server however since the server now thinks that it wasn't able to send the entire response (the states size of the response is 300k but we only sent 200k). IE seems to be able to recover from this sporadically but Mozilla will not.
There does not appear to be a solution as of yet, other than to NOT compress inline PDF deliveries. You can still send compressed PDF's as long as you do not attempt to display the content inline (setting the "Content-Disposition" to inline).
Anyone else have any theoeries? I really don't want to turn compression off for everyone because of a few people using Acrobat 7.