User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0 Build ID: 20141125180439 Steps to reproduce: I spent a large amount of time thinking that my tomcat 7 setups weren't compressing things correctly http://stackoverflow.com/questions/27816958/problems-getting-tomcat-7-to-use-gzip-compression I was trying to check that gzip compression was in effect on our servers using the different firefox tools available (the normal net console, firebug's net console and yslow). I had firebug installed just because yslow requires it, but both consoles were failing in a similar way. Actual results: It appeared that gzip compression was not working when in fact it was. This was also intermittent and led to me spending somewhere in the region of 2 days of googling about tomcat gzip compression, diffing and changing config options, and generally being baffled about what could be causing what I was seeing. When looking at a compressed response firefox was intermittently misreporting what was going on and showing a type of bytes and a content length with a number, rather than 'chunked' and type gzip. Some of the time it was reporting the right thing which really confused things more as it wasn't giving me a clear picture of the effect (if any) that the changes I was making were having to the state of the compression. After going round in circles I accidentally used chrome on a computer which didn't have firefox which correctly reported that compression was indeed switched on in the place where it didn't seem to be working at all according to firefox (see the stack overflow post for more details). After seeing that I then began checking what was going on with curl and wireshark. Curl was consistently reporting compression as being on and then wireshark confirmed that compression was indeed on for a browser request that firefox reported it as not being. I could see this in two ways - the headers shown in wireshark were different (showing gzip and chunked as you'd expect) and because you could look at the content and see that it was compressed as it looked like gibberish. In firefox you can't see the raw content (which is fine) but the headers that were reported were incorrect - they did not say gzip and specified an exact length (which is what you would see if the file was not compressed). Expected results: Firefox network console should report the response headers from the server correctly. It clearly doesn't do this as I observed from the discrepancy between the sniffed packets in wireshark and what was reported by the developer tools. I dont know what is going on there - possibly those values have been calculated after decompression in an effort to be more helpful. If so it is definitely not more helpful!! Please report exactly the headers that the server sends back!
If you want to contact me further about this then please post on the stackoverflow answer I've linked to. I signed up for this with a temporary email address as I dont want my email address to be public + receive a load of spam so wont receive any email notifications or whatever you might normally get
Victor, can you suggest what to do here to figure out what's going on?
Component: Untriaged → Developer Tools: Netmonitor
Should probably be fixed by bug 731318. Check out Firefox Nightly.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 731318
Created attachment 8545882 [details] firefox raw headers view.PNG Here is what the raw headers view shows (I believe this is the new bit?)...
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
The last 3 comments are having just tried it on the nightly build 37.0a1 (2015-01-07). It's still not working so I've added a couple of screen shots of what firefox says along with what wireshark says. I guess the new bit is the raw headers? I've not noticed that before anyway, either way its still getting it wrong. I don't know the code at all but surely nothing should be messing around with the values in here - it should just be a matter of reading them off the wire and then just displaying them straight. It certainly seems like this isn't happening and that they are tampered with on the way through.
Are you trying Firefox Nightly in e10s mode? Please try disabling e10s for now (in the Preferences), as not all parts of Net Monitor work correctly in e10s. See bug 982319 for more info on this. The part that is new is the "Transferred" column, which correctly matches in size on the wire. In non-e10s mode, the Transferred and Size columns give different values, where Transferred is size on wire, and Size is the uncompressed size. However, I see what you mean that some headers have shifted: * Net Monitor is missing Transfer-Encoding * Net Monitor is missing Content-Encoding * Net Monitor added Content-Length Can you re-test in Nightly with e10s disabled to see if you get different results?
Hi, I've just checked with it definitely not in e10s mode and see the same thing. I dont think I was in e10s mode before anyway - I dont remember clicking to enable it. Cheers
Okay, I am not able to reproduce this behavior on just any site using these headers, so something must be specific to your site. Is there a public URL where I can test this same request? Or if not, could you attach a Wireshark / Fiddler / something capture that can easily be replayed?
Hi, Sorry didn't realise there had been more activity here. So there's no public url + I'm not on the project anymore. I'm not sure what else I can do to help. Thanks for taking an interest though!
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago → 4 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.