Hi Lukas, On Thu, Dec 28, 2017 at 09:19:24PM +0100, Lukas Tribus wrote: > On Thu, Dec 28, 2017 at 12:29 PM, Lukas Tribus <lu...@ltri.eu> wrote: > > Hello, > > > > > >> But in this example, you're using HTTP/1.1, The "Connection" header is > >> perfectly valid for 1.1. It's HTTP/2 which forbids it. There is no > >> inconsistency here. > > > > For me a request like this: > > $ curl -kv --http2 https://localhost/111 -H "Connection: keep-alive" > > -d "bla=bla" > > > > Fired multiple times from the shell, leads to a "400 Bad Request" > > response in about 20 ~ 30 % of the cases and is forwarded to the > > backend in other cases.
In fact it's a race between the GOAWAY frame caused by the invalid request, and the HEADERS frame being sent in response to the stream being closed. It pretty much depends which one makes its way through the mux first, and given that both depend on the scheduling of all pending events, I hardly see what we can do to achieve a better consistency, except cheating (eg: killing the stream in a way to make it silent). In both cases the GOAWAY should be sent, and only sometimes there is enough time to get the 400 sent in the middle, which gets reported. I agree that it's quite confusing, but we're talking about responses to conditions that are explicitly forbidden in the spec, so I'd rather not spend too much energy on this for now. > However I am unable to reproduce the issue with Firefox: none of the > quantum releases (57.0, 57.0.1, 57.0.2, 57.0.3) emit a connection > header in my testing: That's pretty much interesting, so in fact probably that in the end it's not really sent. I can't test, I installed 57.0.3 on my machine and it's totally broken, tabs spin forever and even google.com does not load, so I had to revert to the last working Firefox ESR version :-( > - https://http2.golang.org/reqinfo never shows a connection header > (not even with POST) You never know whether this one could be stripped on the server side however. > - sniffing with wiresshark (using SSLKEYLOGFILE) also shows that > Firefox never emits a connection header in H2 OK this one sounds better. > - the developer tools *always* show a connection header in the > request, although there really isn't one - clearly there is a > discrepancy between what is transmitted on the wire and what is shown > on in dev tools Great, so that makes more sense regarding the observations so far. It's never fun when dev tools report false elements but it possibly depends where the information is extracted and we could even imagine that the header is internally emitted and stripped just before the request is converted to H2, so let's not completely blame the dev tool yet either :-) > What am I missing? Can you guys provide a decrypted trace showing this > behavior, the output of the http2 golang test and can you please both > clarify which OS you reproduce this on? So at least my analysis for now is that for a reason still to be determined, this version of firefox didn't correctly interoperate with haproxy in a given environment, that the dev tools reported a connection header, which once forced to be sent via curl or nghttp proved that haproxy rejected the request as mandated by the spec. This then led us to conclude that firefox was hit by the same problem, which in fact isn't the case as you just found. Thus we're indeed back to first round trying to figure why firefox+haproxy overthere do not cope well with h2 (given that it doesn't even work with H1 on my machine and that "ps auxw" clearly shows some buffer overflows affecting the argument strings, so I have zero trust at all in this version for now). Cheers, Willy
