Hello,
On Thu, Dec 28, 2017 at 10:26 PM, Lucas Rolff <[email protected]> wrote: >> 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?) You'r right, it does not show up - yet another useless tool: $ curl -k --http2 https://http2.golang.org/reqinfo -H "Connection: keep-alive" > 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. This is log is just as useless as the developer tools, just look at it, in the main thread everything is HTTP/1.1 in both not-working.txt and Working.txt. Then the socket thread takes over and transform the existing HTTP/1.1 request into a h2 stream. All the debug and developer focus on the main thread and are therefor useless to debug this issue. You cannot rely on browser debugs or developer tools for this one. > I’m personally sitting on OS X, and I’ve been able to reproduce it on Firefox > on Ubuntu 16.04 as well. Can you triple check that you can reproduce this on Ubuntu? I was unable, but maybe I didn't try hard enough. I suggest you guys intercept the stream with SSLKEYLOGFILE in wireshark and take a look at the actual real request, see: https://jimshaver.net/2015/02/11/decrypting-tls-browser-traffic-with-wireshark-the-easy-way/ Lukas
