GZip encoded URL isn't rendered properly and triggers a download




2 years ago
2 years ago


(Reporter: bz, Unassigned)



52 Branch

Firefox Tracking Flags

(firefox50 unaffected, firefox51 unaffected, firefox52 affected, firefox53 affected)



(1 attachment)



2 years ago
Created attachment 8818875 [details]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20161215004017

Steps to reproduce:

* Visited https://www.brain.fm/app/html/templates
* Tried the same URL in Chrome which worked (if you see a blank page, it worked - the page is a bunch of script elements).
* Tried the same URL with curl --compressed, which worked.

Actual results:

* Noticed that the page didn't display properly in Firefox dev ed 52.0a2 and instead showed a download dialog (see attachment)
* Moz regression log: https://gist.github.com/anonymous/716892ad5736265e514aa548cbfc0e10

Expected results:

* Page should have been decompressed properly and displayed as usual

Comment 1

2 years ago
I'd be happy to perform a mozreg on Nightly but currently all Nightly builds are broken for me due to bug 1320340 so it's difficult to test.

Comment 2

2 years ago
I can't reproduce it with FF53 on Win 7, issue specifici to Linux probably.
Component: Untriaged → Networking
Keywords: regression
OS: Unspecified → Linux
Product: Firefox → Core
Hardware: Unspecified → x86_64
I have tried it on linux and I can reproduce it on Nightly 53. But if I turn on logging to figure out what is happening it is not reproducible. :) Logging should not change behavior.
I have seen in dev-tools that there is a header Content-type: "application/x-gzip" if it shows dialog and this header does not exist if it does not show the dialog (from log I seen that we do not get such a header).
I cannot reproduce it all the time. I think it is a server issue.

Comment 6

2 years ago
(In reply to Dragana Damjanovic [:dragana] from comment #5)
> I cannot reproduce it all the time. I think it is a server issue.

Interesting. I can reliably reproduce this every time, even after turning on logging in about:networking. Are you able to see it work by refreshing repeatedly? I'm curious as to what you're doing differently to me.

Comment 7

2 years ago
Can't repro after updating today. I assumed there was a fix that had been pushed - running mozregression with --good=2016-12-16 --bad=2016-12-15 --find-fix --repo aurora gave me:

 2:16.30 INFO: Narrowed inbound regression window from [40a2d269, 35f19f6b] (3 revisions) to [e92c50c1, 35f19f6b] (2 revisions) (~1 steps left)
 2:16.30 INFO: Oh noes, no (more) inbound revisions :(
 2:16.30 INFO: First good revision: 35f19f6baa6c2d853a438efff3d955a23823bbca
 2:16.30 INFO: Last bad revision: e92c50c1c5cdd95b59f0a72f15e3aa2841908beb
 2:16.30 INFO: Pushlog:

I was suspicious, so I ran the same command again and got a totally different result:

 1:40.78 INFO: Narrowed inbound regression window from [481d62db, 0da2d015] (4 revisions) to [f3353c8b, 0da2d015] (2 revisions) (~1 steps left)
 1:40.78 INFO: Oh noes, no (more) inbound revisions :(
 1:40.78 INFO: First good revision: 0da2d0158f98743c85d3ed279c3a4db691c2d4f5
 1:40.78 INFO: Last bad revision: f3353c8bb6f3de41df3e889da27115d6e29a7e93
 1:40.78 INFO: Pushlog:

So I don't know what to make of that. I don't think it's telling us anything and I'm beginning to think this is indeed a server issue.

I can confirm what was said about the "Content-Type" header above:

> I have seen in dev-tools that there is a header Content-type: "application/x-gzip" if it shows dialog and this header does not exist if it does not show the dialog (from log I seen that we do not get such a header).

I checked the network log and it would indeed appear as if it's definitely being sent (but only sometimes?):

2016-12-16 15:36:06.086150 UTC - [Socket Thread]: V/nsHttp index 61: date Fri, 16 Dec 2016 15:35:24 GMT
2016-12-16 15:36:06.086153 UTC - [Socket Thread]: V/nsHttp index 62: content-type application/x-gzip
2016-12-16 15:36:06.086156 UTC - [Socket Thread]: V/nsHttp index 63: x-frame-options SAMEORIGIN
2016-12-16 15:36:06.086159 UTC - [Socket Thread]: V/nsHttp index 64: x-backend-server brainfm-us-atl01.brain.fm
2016-12-16 15:36:06.086162 UTC - [Socket Thread]: V/nsHttp index 65: vary Accept-Encoding
2016-12-16 15:36:06.086165 UTC - [Socket Thread]: V/nsHttp index 66: strict-transport-security max-age=86400
2016-12-16 15:36:06.086167 UTC - [Socket Thread]: V/nsHttp index 67: server cloudflare-nginx
2016-12-16 15:36:06.086170 UTC - [Socket Thread]: V/nsHttp index 68: content-encoding gzip
2016-12-16 15:36:06.086173 UTC - [Socket Thread]: V/nsHttp index 69: cf-ray 3123347473f83476-LHR

I'll take this up with their support again and see if there are any more ideas.
status-firefox50: --- → unaffected
status-firefox51: --- → unaffected
status-firefox52: --- → affected
status-firefox53: --- → affected
The pushlog for the fixed revisions shows nothing in networking (all graphics changes), and the pushlog for the broken revisions (https://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=f6f2e2b9fa87a1cf454dec44bcf52cd4f96288a0&tochange=0d52c1ee6bce8b6b8d0b1774ce4b15082e6b4854) only contains updates to the HSTS and HPKP preload lists. None of those changes would have caused or fixed a problem like this. Based on that, and other comments in the bug, marking this invalid.
Last Resolved: 2 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.