1427256 - connection header http2

Status: RESOLVED WONTFIX

(DevTools :: Netmonitor, defect, P4)

Description

[lucas]

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.

Comment 1

[Maximilian Böhm]

We do face the same issue. Users did see empty or partly empty websites.

Comment 2

[Lukas Tribus]

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.

Comment 3

[lucas]

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.

Comment 4

[Kershaw Chang [:kershaw]]

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

Comment 5

[Lukas Tribus]

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.

Comment 6

[Jeroen Vermeulen]

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

Comment 7

[Lukas Tribus]

(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/[e-mail]/msg28501.html

Comment 8

[Jeroen Vermeulen]

(In reply to Lukas Tribus from comment #7)
Thanks for the quick reply @Lukas Tribus!

Comment 9

[Jan Honza Odvarko [:Honza] (always need-info? me)]

(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/[e-mail]/msg28501.html

So, can we close this bug report?

Honza

Comment 10

[Jeroen Vermeulen]

for me: Yes.

Comment 11

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Thanks for the update, closing.

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

Thanks!
Honza

Comment 12

[Lukas Tribus]

(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/[e-mail]/msg28501.html
> 
> So, can we close this bug report?

Agreed.

Thanks,
Lukas