300438 - [FIXr]Gzipped Content-Encoding Renders Acrobat PDF Useless

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect, P1)

Description

[Jerry Baker]

20050707 trunk

ALL PDF no longer load in Firefox. I get a message from Acrobat that the file
does not begin with %PDF and then Firefox hangs with 99% CPU. The same links
work in IE with no issues whatsoever.

Comment 1

[Jerry Baker]

Updating summary

Comment 2

[Ria Klaassen (not reading all bugmail)]

WFM. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b3) Gecko/20050711
Firefox/1.0+ ID:2005071121

Comment 3

[Jerry Baker]

Hmm. Seems to work as long as the PDF doesn't come from a loopback address. If
the PDF is served from Apache and you access it via 127.0.0.1 you get an error.
If you access it by the FQDN, it works fine. It's not a virtual host issue since
it works with IE fine either way.

Comment 4

[Jerry Baker]

It doesn't even work from the FQDN if the IP is local.

PDFs also load if you go through a proxy to reach the local server, but not if
it's directly. Can't sniff packets on a loopback interface, so I'm not sure how
to troubleshoot the issue.

Comment 5

[Jerry Baker]

OK. Tracked it down. Sorry for all the spam.

Apparently the content transfer encoding is not being undone before handing the
bytes off to the plugin. Of course, Acrobat has no idea what to do with gzipped
data.

I'm guessing this is a core issue.

Comment 6

[Darin Fisher]

Are you sure you mean Transfer-Encoding and not Content-Encoding?  Mozilla has
never handled Transfer-Encoding: gzip.

Comment 7

[Darin Fisher]

Jerry, can you post a sample URL where this problem occurs?

Comment 8

[Jerry Baker]

Yes, I meant Content-Encoding. Updating summary. Confusing it with
transfer-encoding in mail.

Try this:
http://jerbaker.dhs.org/test.pdf

Comment 9

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch

Comment 10

[Boris Zbarsky [:bzbarsky]]

Attachment: Same as diff -w

So what's going on here is that the test URL in question sends no
Content-Length header.	The plugin code failed to reach the code added in bug
165094 when that happened.  All the patch does is move the length check into
the one place it matters -- deciding whether to do byte-range requests.  This
means that we'll now look for Content-Encoding unconditionally, as well as
unconditionally setting the last-modified date, which I think is desirable.

Comment 11

[Jerry Baker]

My build of Apache isn't sending content-length headers when transfer-encoding
is chunked. I don't know if that's right or not, however. It is alpha code
pulled from Apache's CVS (the 2.1 dev tree).

Comment 12

[James Ross]

That is correct. Transfer-encoding: chunked is specifically for unknown-length
transfers. They should not be seen together, as if you have Content-Length you
have no need for the extra work of chunking it. :)

Comment 13

[Jerry Baker]

Ya. It appears that anything under around 10k will have a content-length header,
but larger files are chunked. I assume that this is somewhere around the buffer
size for mod_deflate and once the file to be compressed is larger than the
buffer, there's no way to know at the time the request is answered how many
times the buffer will fill and flush during the course of the request.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Given that the Content-Length header is generally optional, as I understand, we
want to deal well even when it's absent...

Comment 15

[Darin Fisher]

"because range request on compressed content is irrelevant,"

Actually, apache mod_gzip has (or had) a bug in it where it mistakenly treated
the range request as applying to the uncompressed document instead of the
compressed document :-(  Technically, range requests on an entity served with
Content-Encoding: gzip are perfectly reasonable.  A range request would be an
offset into the compressed document, which is in this case the entity.

Comment 16

[Boris Zbarsky [:bzbarsky]]

Darin, I can update the comment to reflect that if you want.  Just let me
know...  If it's the plugin that makes the range requests, though, then they are
indeed "irrelevant", since the plugin only sees the uncompressed data.

Comment 17

[Darin Fisher]

The plugin is the one issuing the range requests, and I guess what you are
saying is that we need to suppress such range requests when the entity is
compressed because known plugins (ok, Adobe Acrobat) cannot handle ranges
requests on compressed documents?

Comment 18

[Boris Zbarsky [:bzbarsky]]

Right.  More precisely, by the time the plugin gets the data it's always
uncompressed (in the current setup), so it can't make meaningful range requests
on compressed documents -- it has no way to compute the ranges....

Comment 19

[Darin Fisher]

OK, changing the comment to say that would probably be good :)

Comment 20

[Boris Zbarsky [:bzbarsky]]

I can do that, no problem.

Comment 21

[Johnny Stenback (:jst)]

Comment on attachment 189079 [details] [diff] [review]
Same as diff -w

r=jst

Comment 22

[Darin Fisher]

Comment on attachment 189079 [details] [diff] [review]
Same as diff -w

sr=darin (sorry for the delay)

Comment 23

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 189079 [details] [diff] [review]
Same as diff -w

This is a pretty safe fix that should make content-encoding play nice with
plugins in general...

Comment 24

[Benjamin Smedberg]

Comment on attachment 189079 [details] [diff] [review]
Same as diff -w

What would be involved in creating a testcase for this behavior?

Comment 25

[Jerry Baker]

Depends on what you want to test. If you want to see the difference in behavior
between encoding and no encoding, I can set my server up for that. It's just my
home PC on a DSL line, so it can't handle a huge amount of traffic, but it
should suffice for testing.

Comment 26

[Boris Zbarsky [:bzbarsky]]

Bsmedberg, you mean a testcase that becomes part of our basic unit tests?  We
need an https-enabled server, preferably one capable of running CGIs (so that we
can control the headers) and which enables gzip compression (in a controllable
way) for the output of said CGIs.

Comment 27

[Boris Zbarsky [:bzbarsky]]

Fixed.

Comment 28

[Phil Ringnalda (:philor)]

*** Bug 310871 has been marked as a duplicate of this bug. ***