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

Status: RESOLVED INVALID

(Core :: Networking, defect)

Description

[Adam Williams]

Attachment: dldialog.png

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

[Adam Williams]

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

[Loic]

I can't reproduce it with FF53 on Win 7, issue specifici to Linux probably.

Comment 3

[Dragana Damjanovic [:dragana]]

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.

Comment 4

[Dragana Damjanovic [:dragana]]

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

Comment 5

[Dragana Damjanovic [:dragana]]

I cannot reproduce it all the time. I think it is a server issue.

Comment 6

[Adam Williams]

(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

[Adam Williams]

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:
https://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=e92c50c1c5cdd95b59f0a72f15e3aa2841908beb&tochange=35f19f6baa6c2d853a438efff3d955a23823bbca

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:
https://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=f3353c8bb6f3de41df3e889da27115d6e29a7e93&tochange=0da2d0158f98743c85d3ed279c3a4db691c2d4f5

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.

Comment 8

[u408661]

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.