Closed Bug 224296 Opened 21 years ago Closed 16 years ago

Compressed content not correctly handled with acrobat plugin

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: a.schild, Assigned: peterlubczynski-bugs)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030916
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030916

The webserver for http://www.espacelibre-infopool.ch (Apache 2.0.48) 
is configured to send compressed content when the browser supports it.

PDF files too will be served as compressed content, when the
browser accepts it.

Unfortunally it seems that the acrobat 5.05 and 6.0 plugin get the
compressed content, and not the decompressed content.


Reproducible: Always

Steps to Reproduce:
1. Use Mozilla with Acrobat Reader 5.x and 6.x with the link above
Actual Results:  
The acrobat reader is started and then displays the error message
File does not start with '%PDF'

Expected Results:  
Displaying the content of the PDF file

Of course we could tell our server to serve .pdf files always uncompressed.
But this would only be a work around.

The 1000ID.pdf has a "real" filesize of 410204 Bytes.
In the server logfile we see that the PDF is compressed down to
404714 bytes.

195.48.144.80 - - [31/Oct/2003:15:33:36 +0100] "GET /uploadfiles/1000ID.pdf
HTTP/1.1" 200 404714
"http://www.espacelibre-infopool.ch/mitglied_detail.jsp?ID_Display=10003Z"
"Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030916"


I'm not sure what the correct handling for the plugin should be,
but probably the browser should server uncompressed content to the plugin.
verified Moz 1.5 final on WinXP Pro, with Acrobat Reader 5.0.5 9/24/2001

I'm leaving it marked "unverified" because I have no idea which component it
gets assigned to -- something to do with plugins? Networking?


Questions:
 *  Are there other compressed files on the server we can test?
 *  Does someone have a simlarly configured Apache server we can test?


Some notes:
 *  I really like the painting!

 *  The file opens fine in Acrobat Reader, when executed outside Moz: I
downloaded it, double-clicked ... no problem

 *  Works fine in IE 6.0

 *  You can also access the file from,
http://www.espacelibre-infopool.ch/mitglied_detail.jsp?ID_Display=10003Z
    via the link at the bottom labled,
"Als PDF-Dokument drucken :: Imprimer en format PDF"

 *  The precise error message is:
     titlebar:   Acrobat Reader
     content:    File does not being with '%PDF-'.

 *   When I downloaded the file, Download Manager behaved oddly -- something to
do with the compression?
Here my server configuration
concerning the compression.
It's the default config as suggested by
the apache documentation.

# Insert filter
SetOutputFilter DEFLATE

# Netscape 4.x has some problems...
BrowserMatch ^Mozilla/4 gzip-only-text/html

# Netscape 4.06-4.08 have some more problems
BrowserMatch ^Mozilla/4\.0[678] no-gzip

# MSIE masquerades as Netscape, but it is fine
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

# Don't compress images
SetEnvIfNoCase Request_URI \
\.(?:gif|jpe?g|png)$ no-gzip dont-vary

# Make sure proxies don't deliver the wrong content
Header append Vary User-Agent env=!dont-vary


It is interesting, that the IE 6.x get's a uncompressed
PDF served by the server.
This means, that it does not send a "accept gzip" or such
in the request on behalf of the PDF.

When I just do a "Save Link Target" on the PDF links, then
Mozilla saves the correct content to disk.
In the server logfiles I see that such "Save Link Target" 
are sent as compressed content too.


When you navigate to 
http://www.espacelibre-infopool.ch/mitglieder.jsp
then (almost) each member has a PDF attached to it.

Interestingly, this PDF works fine. (But it's a small
one with no pictures inside). But this one is still 
served as compressed content by the server.

http://www.espacelibre-infopool.ch/uploadfiles/10005Z.pdf

-> Plugins
Assignee: general → peterlubczynski-bugs
Status: UNCONFIRMED → NEW
Component: Browser-General → Plug-ins
Ever confirmed: true
Pehaps it's a specific acrobat plugin problem ?

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22902

I have now activated compression for IE too, and now 
IE shows the same problem.
See bug 165094.  Is this a similar problem?

Is your server sending content-encoding headers, or transfer-encoding headers? 
What you're really doing there is transfer-encoding, but we don't support that....
Here are the headers as sent by the server:

GET /uploadfiles/1000ID.pdf HTTP/1.1
Host: www.espacelibre-infopool.ch
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031028
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
Accept-Language: de-ch,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

HTTP/1.1 200 OK
Date: Fri, 31 Oct 2003 17:08:14 GMT
Server: Apache/2.0.48 (Win32) mod_ssl/2.0.48 OpenSSL/0.9.7c mod_jk/1.2.5
Last-Modified: Mon, 18 Aug 2003 08:11:11 GMT
ETag: "3266d-6425c-8b900ef5"
Accept-Ranges: bytes
Vary: Accept-Encoding,User-Agent
Content-Encoding: gzip
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/pdf

Hmmm... I see the problem now.
Will check on the apache side what they are saying.


Actually I don't see why this works:

Doing a "Save as" command gets the PDF
in the gzipped format, but the resulting
file on the harddisk is ungzipped.

Why does this behave different, than passing
the content to a plugin ?

I don't complain that the "Save as" works, I just
wish to understand why it works. IE behaves the 
same way, passing it to the plugin (or activex) 
doens't works, but saving it works fine.

André


I just turned off compression of PDF files
on the webserver. So any tests against the 
server will no longer produce the problem.
According to the apache developers this is not
a serverside bug, but more a client side problem.

Compression is content-encoding not transfer-encoding. 
See RFC 2616 14.11, 14.41 & 3.6

The fact that Mozilla does save a decompressed PDF file
when doing a save-as clearly shows that there is something
handled differently when passing the data to the plugin.


So a question.  Is there a plugtmp dir or something along those lines in your
temp directory when you run into this problem?  If so, does it contain the file
we're talking about?  And if so, is that file compressed or not?
I see several temporary files created/deleted in my user temp directory.
But I don't know if they are created by Mozilla or the Acrobat plugin.

There are several 0Byte length file and one file of 2MB.

When I access a PDF who isn't sent compressed (gzipped)
over the line, then I see a temp file of 2MB size
with the (correct) content of the PDF file.
The file is filled up with 0x00 bytes after the PDF end.

When I access a PDF who is sent compressed, then
I see to temporary file, but I can't say if it's just created
and then deleted again, or if there has never been such a temp file.

André
Blocks: 275516
So per the headers in comment 6, the fix for bug 165094 should have helped here.

André, I know it's been over a year, but could you possibly retest this in a
current (1.8a6) build?
The patch in bug 300438 might fix this.  I can't tell for sure, per comment 8...
Depends on: 300438
This is a problem in the PDF plug-in, and was fixed quite some time ago (I believe Reader 7.x).  I vote we close it.
marking wfm, please reopen if someone still gets this issue
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.