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.

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.

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/

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.

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

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.

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

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.

In case someone wants to compare.

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?

(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.

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

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

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.

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

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.

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 )

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

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.

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?

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.