Re: Inclusion of Connection-Specific Headers in h2c
Date: Thu, 20 Nov 2014 21:52:09 +0900
On Wed, Nov 19, 2014 at 11:21 PM, Lucas Pardue <Lucas.Pardue_at_bbc.co.uk>
> I've attached a HTTP/2 multi example that I believe exhibits the same
> issue reported.
> This is a best effort and I've taken some artistic license in modifying
> the code to emulate the behaviour of our real code. There may be errors,
> introduced by me or in the real code; either way it will be helpful to get
> feedback on any mistakes.
> The application takes a single URL and requests it multiple times. The
> first request is performed in isolation (in order to perform the h2c
> upgrade) and subsequent requests are all added to the multiple handle at
> the same time.
> This was built with curl (github master at c068284882) and nghttp2
> (0.6.6). The application was tested between two VM's with the server being
> nghttpx (0.6.7-DEV) instance acting as reverse proxy to a local apache
> instance. I have also attached the packet trace.
>  If I add all easy handles at the same time, the request on stream 3
> (first after upgrade) sometimes still contains the Upgrade header resulting
> in a server GOAWAY as reported by Sam and fixed by Tatsuhiro. Seperating
> out the requests leads to a more stable upgrade and continuation of
> requests on the same h2c connection.
I successfully reproduced the situation with multi-http2.c.
I think the cause of this issue is CURLMOPT_PIPELINING.
If it is enabled, libcurl issues HTTP request using existing (upgraded)
HTTP/2 connection without waiting the previous request has been done. Since
we have not yet supported multiplexing, so this has to be avoided.
The attached patch disables pipelining for HTTP/2 and upgraded connection.
With this patch, multi-http2.c works fine in my tests.
- application/x-gzip attachment: 0001-http-Disable-pipelining-for-HTTP-2-and-upgraded-conn.patch.gz