Closed Bug 1427256 Opened 2 years ago Closed Last year

connection header http2

Categories

(DevTools :: Netmonitor, defect, P4)

57 Branch
defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: lucas, Unassigned)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36

Steps to reproduce:

- Run haproxy 1.8.2 with http2 enabled (alpn h2,http/1.1)
- Run a website on a backend that accepts POST/PUT requests
- Do a POST/PUT request to the site in Firefox.

The request will fail, due to the fact that the http2 specification says that a browser (or server) shouldn't send connection-specific headers and if it's done, it should be treated as malformed. Firefox sends a "Connection: keep-alive" request on http2 connections.

The issue doesn't seem to happen during GET requests, if this is a specific haproxy issue with implementation, I'm not sure, because connection:keep-alive is still sent during GET requests.

However per specification ( https://tools.ietf.org/html/rfc7540#section-8.1.2.2 ) - Firefox shouldn't send the header in first palce.


Actual results:

Server will reject the request with a 400 Bad Request, due to the fact it's breaking specification


Expected results:

Firefox shouldn't send Connection headers when the negotiated protocol is http2.
We do face the same issue. Users did see empty or partly empty websites.
A clarification, its not that the endpoint "should not" send the connection header, it's that it "MUST NOT". That is quite a difference:

> An endpoint MUST NOT generate an HTTP/2 message containing connection-specific header fields




Also the specification requires ("MUST") the (other) endpoint to treat a request with a connection header in H2 as malformed:

> any message containing connection-specific header fields MUST be treated as malformed (Section 8.1.2.6).



Firefox 57 not only directly violates RFC7540, it also requires all H2 servers to violate the spec as well in order for them to interoperate with Firefox.



Haproxy does not detect the connection header in all of those cases yet, which is why not 100% of the requests are affected. I assume this haproxy bug is gonna be fixed soon, at that point haproxy will reject all request from FF 57.
Component: Untriaged → Networking: HTTP
Product: Firefox → Core
To give a small update

After further investigation, debugging together with Haproxy - it turns out that Firefox actually doesn't send the "Connection" header when negotiating http2 protocol.

However the initial bug report is based on the fact that the Network tab in Web-developer tools shows that a "Connection: keep-alive" is sent as a request header, this, however, is not the case.

I'm still working closely together with Willy from Haproxy to determine the actual root cause of http2 failures in Haproxy which only seems to affect Firefox.

I'd advise the "bug" however gets resolved in terms of removing the "Connection: keep-alive" header from web-developer tools, and possibly look into why it's shown as being sent.

When I have more information regarding the http2 failure, I will update this bug report, just for a closure of the case, so we know what went wrong.
(In reply to lucas from comment #3)
> To give a small update
> 
> After further investigation, debugging together with Haproxy - it turns out
> that Firefox actually doesn't send the "Connection" header when negotiating
> http2 protocol.
> 
> However the initial bug report is based on the fact that the Network tab in
> Web-developer tools shows that a "Connection: keep-alive" is sent as a
> request header, this, however, is not the case.
> 

Based on the above description, I'd like to change the component to Developer Tools.
Component: Networking: HTTP → Developer Tools: Netmonitor
Product: Core → Firefox
The issue in the developer tools IMHO is that Firefox uses HTTP/1.1 in the main thread (where the developers tools get it's data from), and when this goes out to a H2 server, the socket thread will run this through a H2 wrapper converting everything from HTTP/1.1 to H2 - which is the reason the developer tools never see any H2 requests (the response in the dev tools actually show H2 - expect the bogus "X-Firefox-Spdy: H2" header). That's my understanding at least.

A HTTP header analysis with H2 is therefor not possible with the developer tools.
Is this solved in HaProxy 1.8.4?
The changelog mentions both for 1.8.3 and 1.8.4 a number of H2 improvements: 
https://www.haproxy.org/download/1.8/src/CHANGELOG
(In reply to Jeroen Vermeulen from comment #6)
> Is this solved in HaProxy 1.8.4?

Even better, this was fixed in 1.8.3:
https://www.mail-archive.com/haproxy@formilux.org/msg28501.html
(In reply to Lukas Tribus from comment #7)
Thanks for the quick reply @Lukas Tribus!
(In reply to Lukas Tribus from comment #7)
> (In reply to Jeroen Vermeulen from comment #6)
> > Is this solved in HaProxy 1.8.4?
> 
> Even better, this was fixed in 1.8.3:
> https://www.mail-archive.com/haproxy@formilux.org/msg28501.html

So, can we close this bug report?

Honza
Flags: needinfo?(notifications)
Priority: -- → P4
for me: Yes.
Thanks for the update, closing.

@Anyone: feel free to reopen if you think there is a bug in the Network panel.

Thanks!
Honza
Status: UNCONFIRMED → RESOLVED
Closed: Last year
Resolution: --- → WONTFIX
Product: Firefox → DevTools
(In reply to Jan Honza Odvarko [:Honza] from comment #9)
> (In reply to Lukas Tribus from comment #7)
> > (In reply to Jeroen Vermeulen from comment #6)
> > > Is this solved in HaProxy 1.8.4?
> > 
> > Even better, this was fixed in 1.8.3:
> > https://www.mail-archive.com/haproxy@formilux.org/msg28501.html
> 
> So, can we close this bug report?

Agreed.

Thanks,
Lukas
Flags: needinfo?(notifications)
You need to log in before you can comment on or make changes to this bug.