> the output of the http2 golang test and can you please both clarify which OS
> you reproduce this on?
If I visit http2 golang test, I also don’t see it, and I saw it in developer
tools (Because dev tools shouldn’t put headers that isn’t requested/received) –
however based on your findings, that seem to be the case.
What I find odd, is that Firefox (Together with Safari, and Webkit) all have
the same behaviour, however, I’m unable to reproduce it in Chrome and Opera.
I can reproduce the error in nghttp and curl when using -H “Connection:
keep-alive” – omitting the header makes the request work in nghttp and curl as
well (as expected).
However, are we sure that the http2 golang doesn’t just ignore the header (or
even removes it?)
I found that Firefox actually has a way to enable HTTP Logging to get info
about what’s going on – it can be enabled by going to about:networking#logging
What I did is to first to take a sample where it doesn’t fail (now in this case
for a GET request), figure out what it does specific to my “app.css” file, and
then another request (retrying 20-30 times), until it failed, and then
comparing what differs.
When it doesn’t work, it does a “BeginConnect”, some “ResolveProxy” and
“OnProxyAvailable” function calls, it seems like establishing a connection - if
that’s the case, it would be odd, since the TCP connection should already be
established during the initial page request.
From the logs:
Dec 28 21:22:35 localhost haproxy[1534]: 80.61.160.xxx:64921
[28/Dec/2017:21:22:12.309] https_frontend~ https_frontend/<NOSRV>
-1/-1/-1/-1/22978 400 0 - - CR-- 1/1/0/0/0 0/0 "<BADREQ>"
Dec 28 21:22:40 localhost haproxy[1534]: 80.61.160.xxx:64972
[28/Dec/2017:21:22:35.329] https_frontend~ cdn-backend/mycdn 0/0/1/0/5001 200
995 - - ---- 1/1/0/1/0 0/0 "GET /js/app.js?v=1 HTTP/1.1"
This could explain the additional calls which looks like a connection, due to
the “CR” states:
C : the TCP session was unexpectedly aborted by the client.
R : the proxy was waiting for a complete, valid REQUEST from the client
(HTTP mode only). Nothing was sent to any server.
Why haproxy sees the TCP session as aborted from the client, I’m not sure.
The working example also does actual stuff in the socket thread, where the
non-working one doesn’t really do much, other than generating headers (last two
lines)
The output is here:
https://gist.github.com/lucasRolff/c7f25c93281715c3911d36e9488b111a
> and can you please both clarify which OS you reproduce this on?
I’m personally sitting on OS X, and I’ve been able to reproduce it on Firefox
on Ubuntu 16.04 as well.
On 28/12/2017, 21.19, "[email protected] on behalf of Lukas Tribus" <[email protected]>
wrote:
Hello,
On Thu, Dec 28, 2017 at 12:29 PM, Lukas Tribus <[email protected]> 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.
> I'm unable to reproduce a "400 Bad Request" when using GET request in
> my quick tests.
>
>
>
> Here 2 exact same requests with different haproxy behavior:
My previous mail proves that haproxy's behavior is inconsistent.
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:
- https://http2.golang.org/reqinfo never shows a connection header
(not even with POST)
- sniffing with wiresshark (using SSLKEYLOGFILE) also shows that
Firefox never emits a connection header in H2
- 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
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?
Thanks,
Lukas
