Closed Bug 212005 Opened 22 years ago Closed 11 years ago

tweaknews.net - View page source does not show actual source

Categories

(Web Compatibility :: Site Reports, defect)

Product:
Web Compatibility
Component:
Site Reports
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: marco, Unassigned)

References

(
URL
)

Details

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030702 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030702 The page at http://www.tweaknews.net/forum/viewtopic.php?t=312 doesn't show up. OK, it may be bad HTML, but why does "View Source" just show: <html><body></body></html> Lynx can't handle it either, both page and source show up as garbage. w3m gives "unzip: stdin: not in gzip format" (this may be a clue, see below). Konqueror renders it OK, but more importantly, shows all the source. wget has no problem retrieving all the HTML source. When running lynx or mozilla on the source obtained with wget the page shows up! Is the server sending it compressed and confusing the various browsers? I repeat: this is NOT necessarily is rendering bug, the HTML source may be bad, the problem is that the source itself is apparently not shown. If the server is mangling the content it's not Mozilla's fault, of course, but I'm not sure what should be the expected behaviour... Reproducible: Always Steps to Reproduce: 1. Go to http://www.tweaknews.net/forum/viewtopic.php?t=312 2. Do View -> Page Source 3. Actual Results: Page is blank, source says "<html><body></body></html>" (but it's not) Expected Results: Show the same source as obtained when doing: wget -O source.html "http://www.tweaknews.net/forum/viewtopic.php?t=312" If the HTML source is actually good, render the page. After all of the above I think that maybe the server is not sending the content as it should. However, I don't understand why some browsers/downloaders (Konqueror, wget) can handle it, while others (Mozilla, w3m, lynx) can't. Browser or server problem? Both?
Over to Networking:HTTP The server sends a response marked as "Content-Encoding: gzip". And the data does in fact seem to be encoded somehow, though I can't tell with what (otherwise this would be a definite dupe of bug 184144)--though apparently the gzip decoder can't handle it.
Assignee: general → darin
Component: Browser-General → Networking: HTTP
QA Contact: general → httpqa
Summary: View page source does not show actual source (maybe) → View page source does not show actual source
ok, it seems like the GZIP header is malformed. inspecting the first few bytes in memory, i see the following: 028A9784 5C 78 31 66 5C 78 38 62 \x1f\x8b 028A978C 5C 78 30 38 5C 78 30 30 \x08\x00 028A9794 5C 78 30 30 5C 78 30 30 \x00\x00 028A979C 5C 78 30 30 5C 78 30 30 \x00\x00 according to RFC 1952, the first byte should be 0x1F and the second byte should be 0x8B, but notice that in this case the first byte is 0x5C and the second byte is 0x78. it seems to me that the server is for some reason sending out the GZIP header using some kind of ASCII escaping. that doesn't seem to be allowed by the GZIP specification, and i'm not sure that we should try to accept it.
wget appears to work only because it does not send an "Accept-Encoding: gzip" request header. IE6 loads this page correctly, but interestingly enough when i packet trace IE6, i notice that the webserver doesn't do the funky \x escaping. in fact, if i make moz spoof IE6's useragent string, then this bug goes away. so i think this is not something we should try to work around... this is definitely an evangelism bug. reassigning...
Assignee: darin → english-us
Status: UNCONFIRMED → NEW
Component: Networking: HTTP → English US
Ever confirmed: true
Product: Browser → Tech Evangelism
QA Contact: httpqa → english-us
Version: Trunk → unspecified
Summary: View page source does not show actual source → tweaknews.net - View page source does not show actual source
View source now shows the whole source.
marco, can this be closed?
Assignee: english-us → nobody
Status: NEW → RESOLVED
Closed: 11 years ago
Component: English US → Desktop
Resolution: --- → FIXED
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.