Last Comment Bug 717524 - Google Labs SMS channels website shows garbage characters
: Google Labs SMS channels website shows garbage characters
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Networking: HTTP (show other bugs)
: 12 Branch
: x86 All
: -- normal (vote)
: mozilla13
Assigned To: Patrick McManus [:mcmanus]
:
Mentors:
http://labs.google.co.in/smschannels/...
: 205156 479266 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-11 23:25 PST by Deekshith
Modified: 2013-01-02 12:10 PST (History)
9 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch 0 (6.66 KB, patch)
2012-02-07 14:37 PST, Patrick McManus [:mcmanus]
bzbarsky: review+
Details | Diff | Splinter Review

Description Deekshith 2012-01-11 23:25:47 PST
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0a1) Gecko/20120111 Firefox/12.0a1
Build ID: 20120111031049

Steps to reproduce:

I opened this link http://labs.google.co.in/smschannels/browse 


Actual results:

Firefox displays some weird characters instead of the web page.


Expected results:

I could view the web page in other browsers like Midori and Chrome, but Firefox failed to render it.
Comment 1 Andre Klapper 2012-01-12 03:30:04 PST
Confirming on FF 9.0.1, Fedora16.
Comment 2 Matthias Versen [:Matti] 2012-01-12 07:48:12 PST
1476[170f780]: http response [
1476[170f780]:   HTTP/1.1 200 OK
1476[170f780]:   Content-Length: 13152
1476[170f780]:   Content-Encoding: gzip,gzip
1476[170f780]:   Expires: Fri, 01 Jan 1990 00:00:00 GMT
1476[170f780]:   Vary: Accept-Encoding
1476[170f780]:   Pragma: no-cache
1476[170f780]:   Cache-Control: no-cache, must-revalidate
1476[170f780]:   Date: Thu, 12 Jan 2012 15:32:33 GMT
1476[170f780]:   Content-Type: text/html; charset=UTF-8
1476[170f780]:   Set-Cookie: PREF=ID=ea367be4b644d81b:TM=1326382352:LM=1326382353:S=XXbCmH-J20YsDI04; expires=Sat, 11-Jan-2014 15:32:33 GMT; path=/; domain=.google.co.in
1476[170f780]:   X-Content-Type-Options: nosniff
1476[170f780]:   Server: mic_server
1476[170f780]:   X-XSS-Protection: 1; mode=block
1476[170f780]:   X-Frame-Options: SAMEORIGIN
1476[170f780]: ]

The server sends "Content-Encoding: gzip,gzip" 
If the Client doesn't accept a content-encoding gzip the serer still sends "Content-Encoding: gzip".

This is Tech Evangelism bug but Opera and Chrome seem to handle this, IE8 fails as well. 
Moving to networking:http for a decision from the networking developers.
Comment 3 Boris Zbarsky [:bz] 2012-01-12 07:51:47 PST
Is the server actually gzipping twice when it sends "Content-Encoding: gzip,gzip"?
Comment 4 Alice0775 White 2012-01-12 07:57:23 PST
Related to Bug 205156?
Comment 5 Matthias Versen [:Matti] 2012-01-12 09:09:13 PST
wget --header="accept-encoding: gzip" --user-agent="Mozilla/5.0 (Windows NT 6.1; rv:12.0a1) Gecko/20120111 Firefox/12.0a1 SeaMonkey/2.9a1" -S http://labs.google.co.in/smschannels/browse

The result is a double gzip content
Comment 6 Boris Zbarsky [:bz] 2012-01-12 09:57:02 PST
Yeah, we should probably just handle that...

It's not hard to hook up two chained gzip converters on a technical level; the question is whether there are sites sending "gzip,gzip" but only gzipped once.
Comment 7 Patrick McManus [:mcmanus] 2012-01-12 12:22:16 PST
(In reply to Boris Zbarsky (:bz) from comment #3)
> Is the server actually gzipping twice when it sends "Content-Encoding:
> gzip,gzip"?

I like to look at httparchive.org for crud like this.

It has a DB of 4.5 million HTTP transactions.

About 1 million of them have content-encoding at all, and exactly 1 of them has more than 1 encoding.. and that's "identity, identity" from some cgi (http://www.toggo.de/fcgi-bin/fcgi_application)

So I am content this is a dumb and rare header value. Barring any other data I think the standards compliant interpretation ought to win - which in this case is the double gzip.
Comment 8 Boris Zbarsky [:bz] 2012-01-12 12:54:15 PST
Sounds good.  Let's do that.
Comment 9 Patrick McManus [:mcmanus] 2012-02-07 14:37:04 PST
Created attachment 595189 [details] [diff] [review]
patch 0

process list of Content-Encodings as per RFC 2616 (though I capped it at 16 to avoid true silliness).. add a test case for "gzip" and "gzip, gzip", and manually confirmed this makes http://labs.google.co.in/smschannels/browse work

sent off to try as well.
Comment 10 Patrick McManus [:mcmanus] 2012-02-07 14:43:18 PST
*** Bug 205156 has been marked as a duplicate of this bug. ***
Comment 11 Boris Zbarsky [:bz] 2012-02-07 17:47:17 PST
Comment on attachment 595189 [details] [diff] [review]
patch 0

Why change the return value from AsyncConvertData to NS_ERROR_UNEXPECTED on error?  Just return rv there.

Also, keep the logging for "unknown encoding"?

r=me with that
Comment 12 Patrick McManus [:mcmanus] 2012-02-07 21:09:36 PST
https://hg.mozilla.org/integration/mozilla-inbound/rev/88cb2e5ec134
Comment 13 Ed Morley [:emorley] 2012-02-08 08:59:41 PST
https://hg.mozilla.org/mozilla-central/rev/88cb2e5ec134
Comment 14 Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2013-01-02 12:09:57 PST
Note that this probably makes zip-bombing (http://en.wikipedia.org/wiki/Zip_bomb) easier but I don't see that as a significant issue given that even a single layer of gzip can cause OOM for us.
Comment 15 Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2013-01-02 12:10:35 PST
*** Bug 479266 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.