429629 - Unsupported form of compression

Status: RESOLVED INVALID

(Core :: Networking: HTTP, defect)

Description

[Prakhar Deep]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5

The Support website of microsoft does not open. Firefox gives error message : The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression.

Reproducible: Always

Steps to Reproduce:
1. Open Firefox 3b5
2. Enter http://support.microsoft.com
3. Press Enter
Actual Results:  
Error message "The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression." was displayed.

Expected Results:  
Its should have opened the website.

Comment 1

[Ria Klaassen (not reading all bugmail)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008041804 Minefield/3.0pre

I can visit the site http://support.microsoft.com/ without problem.

Comment 2

[Dave Garrett]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008041304 Minefield/3.0pre

Ditto; works for me too.  Please try a more recent build of Firefox on your system and see if that works.  It may just be an issue that's already been fixed, or it may be something else.

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2008/04/2008-04-13-06-trunk/
OR
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

Comment 3

[Jean-Marc Desperrier]

I'm getting the error right now for the page:
http://support.microsoft.com/kb/931351/en-us

"Content Encoding Error

The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression."

HTTP headers shows me the following exchange:
----- Request
GET /kb/931351/en-us HTTP/1.1
Host: support.microsoft.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008041707 Minefield/3.0pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
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
Cookie: MC1=GUID=498d772bdbe28248b98c8394fd7ae22c&HASH=2b77&LV=200711&V=3; gssSITE=gn; WT_FPC=id=195.68.92.104-3825860080.29892770:lv=1208835673791:ss=1208835079267; A=I&I=AxUFAAAAAAAVCQAAKOWu2mxDWqDvCq+dOV+WKg!!&CS=111_cS002hDii0W02gqif2R002jif1M01[8gT00; .ASPXANONYMOUS=jZmXIhDbyAEkAAAAMGJhYTBlMDItZTRjYy00NzgyLTk2OTYtYWZjMjc0NmI4YWFk_xArGkLex4TEISBg75HAqZIKh6c1; WT_NVR_RU=0=msdn2:1=:2=; msdn=N=&MS=F&TS=F&MB=&TB=&L=0

----- Response
HTTP/1.x 200 OK
Cache-Control: private,max-age=0
Date: Tue, 22 Apr 2008 13:46:48 GMT
Content-Type: text/html; charset=utf-8
Expires: Wed, 01 Jan 1997 12:00:00 GMT
Server: Microsoft-IIS/6.0
P3P: CP="ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI"
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Set-Cookie: .ASPXANONYMOUS=IE6sJhHbyAEkAAAANTRkZjA4ZGQtNjQwYS00NTE5LWI3OWQtNjJhNDJjZTQ5ODE2UGREDmo-ffidW56HUEM5P8ftukM1; expires=Tue, 01-Jul-2008 00:26:48 GMT; path=/; HttpOnly
Content-Encoding: gzip
Vary: Accept-Encoding
Transfer-Encoding: chunked
X-Cache: MISS from firewall.dictao.com
Connection: close

So gzip and deflate accepted, gzip obtained.

Comment 4

[Ria Klaassen (not reading all bugmail)]

Does it work with a new profile? http://kb.mozillazine.org/Creating_a_new_Firefox_profile_on_Windows

Comment 5

[Jean-Marc Desperrier]

Still getting the problem with a fresh profile and build 2008042106

Setting network.http.accept-encoding to null in about:config workarounds this problem (was at the default value of gzip,deflate as can be deduced from the headers above).

Can you install LiveHTTPHeaders extension and check if something is different in the header with an install that works ? Seamonkey is broken too.

Comment 6

[Ria Klaassen (not reading all bugmail)]

This is the beautiful site I see:
http://img366.imageshack.us/img366/291/microsoftdm6.png

Teh only thing I'm missing in the response is:

X-Cache: MISS from firewall.dictao.com
Connection: close

Comment 7

[Jean-Marc Desperrier]

Hum, could it be the fault of our local firewall ? 
And/or linked somehow to the fact the response is chunked and gzip ?

Wireshark show me there was 14 tcp segment and 22 chunk data segment.

I probably should enable NSPR logging to see what happens internally.

Comment 8

[Ria Klaassen (not reading all bugmail)]

Attachment: Log of http://support.microsoft.com/ (working)

In case someone wants to compare.

Comment 9

[Jonathan Nieder]

I experience the same problem. There is a transparent proxy between me and the Internet - the software my landlord uses to provide wireless access in the apartment building was made for Internet cafes. I am using the latest nightly build of Firefox under Windows 2000 SP4, with build id

     Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008050105 Minefield/3.0pre ID:2008050105.

I can confirm the problem with a fresh profile. The error message always
appears upon visiting http://support.microsoft.com/ and never appears at http://www.microsoft.com/. It is the same error message as Prakhar Deep mentioned.

The problem is also present using the Linux port of Firefox (well, Debian's iceweasel-3.0b5-1) using Colinux (with the same net connection, provided through SLiRP from Windows).

Can I do anything to help diagnose this?

Comment 10

[Jean-Marc Desperrier]

(In reply to comment #9)
Two things to do I think:
- Set nspr logging and compare the result with Ria Klaassen's attachement in comment #8 . Ria can you explain or give a link about how to get this kind of log?
- Try to find a regression windows. Use http://archive.mozilla.org/pub/firefox/nightly/ to download old nightlies and see if there's a date where it stopped working.

Right now I'm getting non-compressed, non-chunked encoding from support.microsoft.com, so I can not investigate myself.

Comment 11

[Ria Klaassen (not reading all bugmail)]

Here is the doc: http://www.mozilla.org/projects/netlib/http/http-debugging.html

Comment 12

[Jonathan Nieder]

Attachment: log of http://support.microsoft.com/ (not working)

build-id = Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008050206 Minefield/3.0pre

Comment 13

[Jonathan Nieder]

I narrowed the regression window down to one day: build id

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

displays http://support.microsoft.com/ just fine, whereas build id

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

gives the error "The page you are trying to view cannot be shown because it uses
an invalid or unsupported form of compression."

Thanks for the suggestions. I tried comparing the logs, but I don't know what to look for. Some differences:

 * in the log I posted, the transaction is HTTP/1.0, whereas the other (and presumably Microsoft) has HTTP/1.1

 * from the http response in the log I posted:

   X-Cache: MISS from lokbox.localdomain
   Via: 1.0 lokbox.localdomain:3128 (squid/2.6.STABLE9)
   Connection: close

There is nothing like this in the other one.

Then, one line later:

-waiting for the server to close the connection.
+Connection can be reused
+chunked decoder created
+nsHttpChunkedDecoder::HandleChunkedContent
 nsHttpTransaction::HandleContent

Here, lines starting with '-' were in my log and not the working one, lines with '+' were in the working one but not mine, and ' ' lines were in both.
I think this is where the problem behavior is: Firefox gives up on handling the chunked content.

For comparison, in the log for the 20060404 build (which works ok), there are

    X-Cache: MISS from lokbox.localdomain
    Via: 1.0 lokbox.localdomain:3128 (squid/2.6.STABLE9)
    Connection: close

lines, but there is no

    waiting for the server to close the connection.

line right after, and there are

    Connection can be reused
    chunked decoder created
    nsHttpChunkedDecoder::HandleChunkedContent

lines. Ok - I'll attach the log for that build now.

Comment 14

[Jonathan Nieder]

Attachment: log of http://support.microsoft.com/ (2006 build handling the proxy fine)

build-id = Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060404 Firefox/1.6a1

Comment 15

[Jonathan Nieder]

Looks like this is the fix to Bug 330214. I don't understand the bug, but it seems likely that Firefox is doing the right thing. A better error message would be helpful, though.

Comment 16

[Jean-Marc Desperrier]

Thanks for your research, Jonathan
Opposite to bug 330214, the server is not sending back Content-Length

We would need to compare with how IE is behaving to understand why it works there.
Could you check using either with ieHTTPHeaders ( http://www.blunck.se/iehttpheaders/iehttpheaders.html ) or with network tracing with for example WireShark ? (I'm afraid ieHTTPHeaders might not give enough details because it will not show the content of the chunked encoding )

Comment 17

[Mike Schroepfer]

Given comment 15 I'm going take off the blocking nomination status. Thanks to everyone for the detailed debugging here...

Comment 18

[Jean-Marc Desperrier]

Comment 15 is incomplete. 
Firefox is doing the right thing for the case where the server sends back both Content-Length and chunked encoding (even thought it could be optimized to reject the data only when the length of the two differs), but it breaks the case where chunked encoding is received without a security reason for doing so.

Now if we look further it's a bug inside the proxy.
IIUC (If I Understand Correctly) it receives a 1.1 request, transmit it as 1.1 to the server, receives a 1.1 response, and butchers it to a broken 1.0 response to the client.

But at the end of the game, what the users see is that the page is broken in Firefox and works in IE.

This being said it seems to be low impact in real life because this is broken since Fx 1.5.04 (MFSA 2006-33) and it did not generate a lot of noise until now.

Comment 19

[Jonathan Nieder]

Actually, the page doesn't work in IE for me (using IE6 on Windows 2000 or
IE7 on my roommate's computer with Windows XP). Perhaps the "HTTP/1.x"
versus "HTTP/1.0" makes a difference. Which version of IE was working for
you? 

Comment 20

[Jean-Marc Desperrier]

OK, so I had a talk about this with our network admin which, added with some web sources, made things a lot clearer.

So it was in fact also broken with IE here.

The thing is since a few weeks support.microsoft.com has started to respond to HTTP 1.0 requests that have a Accept-Encoding: gzip header with a chunked encoding response.
This is not conformant to the HTTP norm and breaks both IE and Firefox.

Squid 3.1 and 2.6 can handle that and send back a valid response.
For squid 2.5/3.0 you need to disable the "Accept-Encoding" header when talking to this site, which has already been done here by our network admin.

Some Squid pointers about this problem:
http://www.nabble.com/Unable-to-Access-support.microsoft.com-through-Squid-td17019176.html
http://squidproxy.wordpress.com/2008/04/29/chunked-decoding/
http://davehope.co.uk/Blog/microsoft-break-supportmicrosoftcom-for-squid-users/#comment-582

Firefox without squid does not have this problem, as it will send a HTTP1.1 request and it's correct and supported to get back a chunked response in that case.

There's just one thing left, I clearly remember having already in the past a very similar problem, and I back then it worked with IE, but I have no proof if it was really related to this. So if it happens again and is not the same thing as this, I'll open another bug.