1542989 - Page is blank due to early HTTP negotiation

Status: RESOLVED WORKSFORME

(Core :: Networking: HTTP, defect, P3)

Description

[Karl Dubost💡 :karlcow]

This was originally https://webcompat.com/issues/28422

Steps to reproduce

1. Go to https://www.exidelife.in/

The page is blank or displays a 404 error.

This doesn't happen in Chrome.
This is not related to UA sniffing. Faking the UA to be chrome doesn't resolve the issue.

Comment 1

[Alice0775 White]

Regression window:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ff4a63d66806&tochange=159a0ec99a6d

Triggered by:
7b6fe53f601f Nicholas Hurley — Bug 1097320 - Enable advertising h2. r=mcmanus

And I confirmed that
setting network.http.spdy.enabled.http2 = false fixes the issue on Nightly68.0a1.

Comment 2

[Junior [inactive]]

I'm not sure this is the right component. Maybe tech evangelism is more appropriate but I can't find one.
This site gives us 400 but it's not a good way to do some reverse engineering to guess why we get 400.

Comment 3

[Karl Dubost💡 :karlcow]

This is already coming from Tech Evangelism (by the mean of webcompat.com)
See the comment in the webcompat.com issue, we pushed here because it's not possible to investigate at the devtools level. This is happening before in the stack.

And that seems well related to HTTP2 upgrade.

Chrome is working here.

Comment 4

[Junior [inactive]]

Those resources returns 400 bad headers.
I retry with same headers in devtool and it returns 200.

Looks like the site is fixing issue in progress (from a 404 to an empty page)

Comment 5

[Karl Dubost💡 :karlcow]

Attachment: network traffic

This is the current issue.
Sometimes we get a 400 issues on the index too.
But most of the time the main request is 200. And all the subsequent requests are 400 (as initially reported).

The first resource for example:

GET /css/main_style.min.css HTTP/1.1
Host: www.exidelife.in
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Firefox/68.0
Accept: text/css,*/*;q=0.1
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Referer: https://www.exidelife.in/
Cookie: ExideLifeH2=!kp+C6Ir4ZFBH6hETi/Tgn0kQrge38Qg3BewAnhpWYmuRciEQwNwP13evaMr3VaPwbmDzqlE8vKoL

and the answer:

HTTP/2.0 400 Bad Request
content-type: text/html; charset=us-ascii
date: Thu, 11 Apr 2019 00:09:08 GMT
x-cnection: close
strict-transport-security: max-age=32140800; includeSubDomains
set-cookie: TS012b2500=0149741aa657f2b6bd2182fd2750d9ecc8f112d3a9122242661b6642a37c06665052b4825265ca358a155a6109ad0ef63a451ec25b; Path=/; Domain=.prod.exidelife.in
vary: Accept-Encoding
content-encoding: gzip
X-Firefox-Spdy: h2

In Chrome it seems all requests are made with HTTP/2.0 and with just the changed HTTP headers.

While in Firefox the first request seems to happen with HTTP/1.1 and subsequent requests with HTTP/2.0, but with all HTTP headers (If I understood correctly the HAR files for both browsers.)

Comment 6

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 7

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.

Comment 8

[Mike Taylor [:miketaylr]]

This particular bug no longer reproduces.