357958 - http://my.qj.net/ gives a Content Encoding Error on trunk

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect)

Description

[Martijn Wargers (dead)]

When visiting that site on trunk, I get a Content Encoding Error page, instead of the site itself. This works fine on branch.
This regressed between 2005-09-15 and 2005-09-16.
A regression from bug 184144.
Maybe this is basically the same issue as bug 309510, I'm not sure.

Comment 1

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

Content-encoding:	UTF-8

that's not a valid content encoding (even though it is a valid character encoding).

Comment 2

[Martijn Wargers (dead)]

I don't understand, I can see the site with Mozilla1.7, Firefox1.5, Firefox2.0, Opera9 and IE7, but not with current trunk builds. Why not?

Comment 3

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

cc'ing some people from bug 184144, but the reason for this is that that bug made an invalid/unknown content-encoding fatal.

Comment 4

[Boris Zbarsky [:bzbarsky]]

So...  I've run into this a few times now -- sites sending charsets as Content-Encoding.

We should evangelize the sites, at least (so reopen this, move to evang, contact the site).  If it's a very common problem, we might need to work around it....

Comment 5

[Darin Fisher]

I think there's enough of a difference between failing to decode a content encoding that we know about vs. failing to decode a content encoding that we don't know about.  I think we should ignore content encodings that we don't know about.  

I think it is extremely unlikely that new content encodings will suddenly start appearing on the net in vast numbers such that it is correct to assume that the unknown content encoding is actually correct.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Should probably file a bug on that, then (and request 1.9 blocking)....

Comment 7

[davedit]

Also see his on OSX 10.4.8 Camino trunk and Minefield at the testcase URL, as well as http://www.speedguide.net/analyzer.php

Comment 8

[davedit]

In my above post, "his" = "this"

I found another way to trigger this problem. If you go directly to http://usa.visa.com/personal/cards/credit/visa_signature_benefits.html , the page should load fine. However (empty the cache if you just tried the previous link), if you instead go to Google and search for "Visa Signature Benefits", and then click on the first link, which is the one stated above, it will receive the Content Encoding Error. Something in the Google search is causing the link to be problematic if I click on it but not if I go directly to it?

Comment 9

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

ok, let's ignore unknown encodings

Comment 10

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

Attachment: patch

Note that this doesn't fix the visa URL, because that's different (it compresses the 200 OK response, but not the 206 Partial Content one. we can't deal with that atm)

Comment 11

[please CC darin dot moz at gmail dot com instead]

r+sr=darin  ... my new email address is not authorized to edit attachments :(

Comment 12

[Darin Fisher]

Comment on attachment 243980 [details] [diff] [review]
patch

Or, perhaps I just need to login as the correct account ;-)

Comment 13

[Tracy Walker [:tracy]]

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

Comment 14

[Henrik Gemal]

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

Comment 15

[Henrik Gemal]

http://www.daimlerchrysler.dk/
also has the problem

Comment 16

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

oops. I forgot about this patch.

checked in now:
Checking in netwerk/protocol/http/src/nsHttpChannel.cpp;
/cvsroot/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp,v  <--  nsHttpChannel.cpp
new revision: 1.302; previous revision: 1.301
done