Closed
Bug 357958
Opened 18 years ago
Closed 18 years ago
http://my.qj.net/ gives a Content Encoding Error on trunk
Categories
(Core :: Networking: HTTP, defect)
Core
Networking: HTTP
Tracking
()
RESOLVED
FIXED
mozilla1.9alpha1
People
(Reporter: martijn.martijn, Assigned: Biesinger)
References
()
Details
(Keywords: regression)
Attachments
(1 file)
(deleted),
patch
|
darin.moz
:
review+
darin.moz
:
superreview+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 1•18 years ago
|
||
Content-encoding: UTF-8 that's not a valid content encoding (even though it is a valid character encoding).
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 2•18 years ago
|
||
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?
Assignee | ||
Comment 3•18 years ago
|
||
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•18 years ago
|
||
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....
Assignee | ||
Updated•18 years ago
|
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Assignee | ||
Updated•18 years ago
|
Assignee: nobody → other
Status: REOPENED → NEW
Component: Networking: HTTP → Other
Product: Core → Tech Evangelism
QA Contact: networking.http → other
Version: Trunk → unspecified
Assignee | ||
Updated•18 years ago
|
Assignee: other → english-us
Component: Other → English US
QA Contact: other → english-us
Comment 5•18 years ago
|
||
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•18 years ago
|
||
Should probably file a bug on that, then (and request 1.9 blocking)....
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
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?
Assignee | ||
Comment 9•18 years ago
|
||
ok, let's ignore unknown encodings
Assignee: english-us → cbiesinger
Component: English US → Networking: HTTP
Product: Tech Evangelism → Core
QA Contact: english-us → networking.http
Target Milestone: --- → mozilla1.9alpha
Version: unspecified → Trunk
Assignee | ||
Comment 10•18 years ago
|
||
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)
Attachment #243980 -
Flags: superreview?
Attachment #243980 -
Flags: review?
Assignee | ||
Updated•18 years ago
|
Attachment #243980 -
Flags: superreview?(darin.moz)
Attachment #243980 -
Flags: superreview?
Attachment #243980 -
Flags: review?(darin.moz)
Attachment #243980 -
Flags: review?
Assignee | ||
Updated•18 years ago
|
Status: NEW → ASSIGNED
Comment 11•18 years ago
|
||
r+sr=darin ... my new email address is not authorized to edit attachments :(
Comment 12•18 years ago
|
||
Comment on attachment 243980 [details] [diff] [review] patch Or, perhaps I just need to login as the correct account ;-)
Attachment #243980 -
Flags: superreview?(darin.moz)
Attachment #243980 -
Flags: superreview+
Attachment #243980 -
Flags: review?(darin.moz)
Attachment #243980 -
Flags: review+
Updated•18 years ago
|
Flags: blocking1.9?
Comment 13•18 years ago
|
||
*** Bug 359283 has been marked as a duplicate of this bug. ***
Comment 14•18 years ago
|
||
*** Bug 363834 has been marked as a duplicate of this bug. ***
Comment 15•18 years ago
|
||
http://www.daimlerchrysler.dk/ also has the problem
Assignee | ||
Comment 16•18 years ago
|
||
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
Status: ASSIGNED → RESOLVED
Closed: 18 years ago → 18 years ago
Flags: blocking1.9?
OS: Windows XP → All
Hardware: PC → All
Resolution: --- → FIXED
Updated•18 years ago
|
Flags: in-testsuite?
Updated•18 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•