324363 - Firefox 1.5 doesn't render pages with what trunk calls "invalid or unsupported form of compression"

Status: RESOLVED WORKSFORME

(Core :: Networking, defect)

Description

[Philip Peake]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

On this website (http://www.sadoun.com/) most of the pages do not display unless you perform a refresh (full refresh - shift<refresh> - cntrl-shift-r).

Reproducible: Always

Steps to Reproduce:
1.Go to http://www.sadoun.com/
2.Click on a link or two.
3.

Actual Results:  
Most pages show up blank.
Refresh needed to display.

Expected Results:  
Page should display.

Not seen this anywhere else.

Marking this as Major -- completely refusing to display a page is broken.
However, since I have only seen this on one website, I won't be at all upset if someone decides that this should be "Normal" priority.

Comment 1

[Philip Puryear]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060120 Firefox/1.6a1

When I tried to repro, Firefox spat out this error page:

"The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression. Please contact the website owners to inform them of this problem."

But you said the page didn't display at all?

Comment 2

[Philip Peake]

Yes - verified on two systems (both XP).
No complaint, returns very fast, displays a blank screen (until refresh).
You are using 1.6a1 I am using 1.5.

Looking at network traffic, the server is Apache 1.3.34 and the content is gzip encoded -- doesn't seem anything that special.

Comment 3

[Philip Puryear]

Hmmm... if this is a gzip handling issue then maybe it's related to/a dupe of bug 205156? Figuring that out goes beyond the scope of my knowledge, though. At any rate, I can confirm that the page in question does not render in 1.5, and my trunk build spits out an invalid compression error.

I'm confirming this to get it on the radar, as it seems to be a problem affecting the branch only. This is quite likely a dupe, though given the number of bugs about Firefox "not rendering pages," it'd be pretty difficult to pinpoint exactly which one.

Comment 4

[:Gavin Sharp [email: [e-mail]]]

I see the contentEncodingError message with a trunk build - I didn't see any problems with 1.5.

Comment 5

[:Gavin Sharp [email: [e-mail]]]

The change in error behavior is due to bug 308858 - it caused an error message to appear instead of just getting nothing. Not sure what is causing the error, though; maybe a server side issue?

Comment 6

[Philip Puryear]

So the issue here is that the patches for bug 184144 and bug 308858 were never checked in on the branch, so 1.5 users get a blank screen while trunk users get an error page, right? If so, then this bug could be marked as a dupe of bug 184144 (since they essentially are the same bug (I think)).

Comment 7

[:Gavin Sharp [email: [e-mail]]]

If the page is being sent with "Content-encoding: gzip" but isn't gzipped, then this is a Tech Evangelism bug. I've not seen any evidence that that is the case, though. Bug 184144 and bug 308858 are related, but they are not duplicates of this issue.

Comment 8

[Philip Peake]

If the page(s) display properly upon refresh, it seems that Firefox is perfectly capable of dealing with the content. The question really is why isn't the page displayed without the need to refresh?

Comment 9

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #8)
> If the page(s) display properly upon refresh, it seems that Firefox is
> perfectly capable of dealing with the content. The question really is why isn't
> the page displayed without the need to refresh?

Seems like a cache issue - clearing the cache will lead to being unable to render the page, subsequent loads seem to be fine. It could also be an issue on the server side, with only certain responses being broken.

Comment 10

[Christian :Biesinger (don't email me, ping me on IRC)]

A log would help a lot here. Can someone create one using the instructions at http://www.mozilla.org/projects/netlib/http/http-debugging.html?

Comment 11

[Philip Puryear]

Attachment: Trunk log

I created a log with a trunk build and a log with a 1.5 build in case both are needed.

Comment 12

[Philip Puryear]

Attachment: 1.5 log

Comment 13

[Flummox]

http://www.zorpia.com/ displays the same error message, but I cannot display the page even when overriding the cache (CtrlCmd+Shift+R). Displays o.k. with 1.5

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060124 Firefox/1.6a1 ID:2006012404

Comment 14

[bugzilla]

I see this on linux also.  Can someone kindly change OS to All?  Thanks.

Comment 15

[Flummox]

The website at http://www.sadoun.com has been fixed.
I've had some useful feedback from the Administrator there - 

"Mod_gzip was causing the problem. We removed it from the server and all
seems well."

Comment 16

[Philip Peake]

I'm not certain how useful this feedback is. Removing mod_gzip simply means that they are not using any compression -- we know that FireFox works on non-compressed sites. The problem occurs when they *are* using compression.

Comment 17

[Robert Sayre]

http://shared.snapgrid.com/

GET / HTTP/1.1
Host: shared.snapgrid.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060317 Firefox/1.5.0.2
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
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.x 200 OK
Date: Tue, 30 May 2006 18:48:39 GMT
Server: Apache/1.3.33 (Unix) mod_throttle/3.1.2 DAV/1.0.3 mod_fastcgi/2.4.2 mod_gzip/1.3.26.1a PHP/4.4.2 mod_ssl/2.8.22 OpenSSL/0.9.7e
Last-Modified: Tue, 25 Apr 2006 01:40:52 GMT
Etag: "bcc01-29797-444d7e24"
Accept-Ranges: bytes
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html
Content-Encoding: gzip
Content-Length: 46176
----------------------------------------------------------
http://shared.snapgrid.com/

GET / HTTP/1.1
Host: shared.snapgrid.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060317 Firefox/1.5.0.2
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Range: bytes=3362-
If-Range: "bcc01-29797-444d7e24"

HTTP/1.x 206 Partial Content
Date: Tue, 30 May 2006 18:48:39 GMT
Server: Apache/1.3.33 (Unix) mod_throttle/3.1.2 DAV/1.0.3 mod_fastcgi/2.4.2 mod_gzip/1.3.26.1a PHP/4.4.2 mod_ssl/2.8.22 OpenSSL/0.9.7e
Last-Modified: Tue, 25 Apr 2006 01:40:52 GMT
Etag: "bcc01-29797-444d7e24"
Accept-Ranges: bytes
Content-Length: 166517
Content-Range: bytes 3362-169878/169879
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html

Comment 18

[Darin Fisher]

-> reassign to default owner

Comment 20

[Philip Semanchuk]

I'm seeing this now on random (?) pages on my site (semanchuk.com) when using Firefox 3 RC1 on OS X. Prior to this I had Firefox 1.5 installed and saw similar behavior -- the page would be blank. (The "invalid or unsupported form of compression" only started appearing w/FF 3.) I have also had this reported about my site by a user with FF 2.0.0.14 on Windows. In other words, this behavior seems to have been in FF since at least 1.5 and appears at least on both OS X and Windows.

A typical URL at which I see the problem is:
http://semanchuk.com/gen/

This problem is easy for me to reproduce. In addition to the Live HTTP headers dump below, I'll attach a Wireshark libcap file from a session that exhibited the problem. Note that in the conversation below FF requests a byte range and that the server responds with 206 Partial Content. I think this is relevant because when I had the Web developer toolbar installed, using the "Disable cache" feature would "fix" this problem.

----------------------------------------------------------
http://semanchuk.com/gen/

GET /gen/ HTTP/1.1
Host: semanchuk.com
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008051202 Firefox/3.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.7,sv;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
Range: bytes=2477-
If-Range: "57048b-30a9-44046a8b"
Cache-Control: max-age=0

HTTP/1.x 206 Partial Content
Date: Sat, 31 May 2008 16:04:51 GMT
Server: Apache/1.3.41 (Unix) mod_gzip/1.3.26.1a mod_log_bytes/1.2 mod_bwlimited/1.4 mod_auth_passthrough/1.8 FrontPage/5.0.2.2635 mod_ssl/2.8.31 OpenSSL/0.9.7a
Last-Modified: Tue, 28 Feb 2006 15:21:47 GMT
Etag: "57048b-30a9-44046a8b"
Accept-Ranges: bytes
Content-Length: 9980
Content-Range: bytes 2477-12456/12457
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html
----------------------------------------------------------


Another strange clue is that I was able to reproduce the problem just now on http://semanchuk.com/gen/places/BukowskoTriangle.html. Before I visited the page, I used about:cache to verify that the page was not in my memory, disk, or offline cache. Nevertheless, the Live HTTP Headers extension showed that FF sent these headers:
Range: bytes=2477-
If-Range: "5704b3-4727-45d37ce3"

The server responded with partial content. Maybe I don't understand how FF caching works, but why would FF request partial content for a page that it doesn't have in its cache?

Please let me know if I can help to debug this further.

Comment 21

[Philip Semanchuk]

Attachment: Wireshark dump of a conversation during which the problem manifested itself.

Comment 22

[Luke Schlather]

http://www.microsoft.com/word/

While in principle I wouldn't mind making it difficult to access Microsoft products, this looks a little tacky. This is under Ubuntu 8.04, yesterday's Minefield. Hard refresh fixed it. Then I closed the tab.

Comment 23

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #17)
> GET / HTTP/1.1
> Host: shared.snapgrid.com
> 
> HTTP/1.x 200 OK
> Server: Apache/1.3.33 (Unix) mod_throttle/3.1.2 DAV/1.0.3 mod_fastcgi/2.4.2 mod_gzip/1.3.26.1a PHP/4.4.2 mod_ssl/2.8.22 OpenSSL/0.9.7e
> Etag: "bcc01-29797-444d7e24"
> Accept-Ranges: bytes
> Content-Type: text/html
> Content-Encoding: gzip
> Content-Length: 46176   <== gzip'ed version by on-the-fly compression
> ----------------------------------------------------------
> GET / HTTP/1.1
> Host: shared.snapgrid.com
> Range: bytes=3362-
> If-Range: "bcc01-29797-444d7e24"
> 
> HTTP/1.x 206 Partial Content
> Etag: "bcc01-29797-444d7e24"
> Accept-Ranges: bytes
> Content-Length: 166517
> Content-Range: bytes 3362-169878/169879 <== Original(not compressed) version
> Content-Type: text/html                 <== No Content-Encoding:gzip

Dup of Bug 241085. (Apache 1.3's fault)
See Bug 241085 Comment #65 and Bug 247334 Comment #4.

See also Bug 426273 for remaining issue relates to "Content-Encoding:gzip & 206 response" even with Apache 2.

Comment 24

[Philip Semanchuk]

(In reply to comment #23)
> 
> Dup of Bug 241085. (Apache 1.3's fault)
> See Bug 241085 Comment #65 and Bug 247334 Comment #4.

This problem does indeed appear to be a dup of 241085, but it's not simply "Apache 1.3's fault". The comments in 241085 discuss the interpretation of the HTTP 1.1 spec (it's not crystal clear what to do in this case) and fixes to both Mozilla and Apache.

Comment 25

[WADA:World Anti-bad-Duping Agency]

Following is proper 206 response by Apache 2(Bug 426273's case), although Content-Type:application/gzip in this case is incorrect due to wrong set up by www.w3.org (See Bug 448240 for this).
In Bug 241085's case, Apache 1.3 returned 206 response with;
 (1) No Content-Encoding:gzip => Should be returned with Content-Encoding:gzip 
 (2) Returned data was not-compressed version => Compressed version is required  
These are the "Apache 1.3's fault", and no fault of Fx is involved in it.
Sorry but I don't know whether newer Apache 1.3 has the problem or not.

> GET /Graphics/SVG/Test/20070907/W3C_SVG_12_TinyTestSuite.tar.gz HTTP/1.1
> Host: www.w3.org
>(snip
> Accept-Encoding: gzip,deflate
>(snip)
> Range: bytes=912968-
> If-Range: "17ece0c-439993d6a5180"
>
> HTTP/1.x 206 Partial Content
> Date: Sun, 03 Aug 2008 23:45:20 GMT
> Server: Apache/2
> Last-Modified: Sat, 08 Sep 2007 05:43:50 GMT
> Etag: "17ece0c-439993d6a5180"
> Accept-Ranges: bytes
> Content-Length: 24174532
> Cache-Control: max-age=21600
> Expires: Mon, 04 Aug 2008 05:45:20 GMT
> P3P: policyref="http://www.w3.org/2001/05/P3P/p3p.xml"
> Content-Range: bytes 912968-25087499/25087500 <= Partial content of gzip'ed data
> Connection: close
> Content-Type: application/gzip; qs=0.001
> Content-Encoding: gzip <= Required because originally sent with this header

Comment 26

[Matthias Versen [:Matti]]

Is this still a problem in recent Firefox builds ?
This looks wfm with Seamonkey trunk

Comment 27

[Frankie]

Following bug 241085:

"As the last comment a year ago was WFM, new Apache versions and a lot of changes on the mozilla side took place, I resolve this WFM."