x/net/http2: delay sending request body in Transport if 100-continue is set #13851
In Go 1.6, the HTTP/1 client got Transport.ExpectContinueTimeout.
The http2 Transport should do the same. And ideally it should use the configuration value from the *http1.Transport, at least when used via the standard library.
Issue #13659 is about at least not getting confused by the 100-continue header responses from servers. This bug is about doing it properly.
The text was updated successfully, but these errors were encountered:
…e tests This makes the Transport ignore 100-continue responses from servers, rather than get confused by them. This is good enough for golang/go#13659. I filed golang/go#13851 to do better later, but that's less important. This CL also adds comprehensive tests for the 36 different ways that frames can be arranged from servers when reading a response. That exposed some bugs (now fixed), and even affected the http2 API: I'd added a END_STREAM accessor on CONTINUATION frames, but it's not even valid there. I also renamed some confusing variables which sounded too similar. Updates golang/go#13659 Updates golang/go#13851 Change-Id: I58868a27258981267f1b2043f711f50a42ec744a Reviewed-on: https://go-review.googlesource.com/18370 Reviewed-by: Andrew Gerrand <email@example.com>
For now, don't enable http2 when Transport.TLSConfig != nil. See background in #14275. Also don't enable http2 when ExpectContinueTimeout is specified for now, in case somebody depends on that functionality. (It is not yet implemented in http2, and was only just added to net/http too in Go 1.6, so nobody would be setting it yet). Updates #14275 Updates #13851 Change-Id: I192d555f5fb0a567bd89b6ad87175bbdd7891ae3 Reviewed-on: https://go-review.googlesource.com/19424 Reviewed-by: Russ Cox <firstname.lastname@example.org> Run-TryBot: Brad Fitzpatrick <email@example.com> TryBot-Result: Gobot Gobot <firstname.lastname@example.org>
In Go 1.6, the HTTP/1 client got Transport.ExpectContinueTimeout. This makes the HTTP/2 client respect a Request's "Expect: 100-continue" field and the Transport.ExpectContinueTimeout configuration. This also makes sure to call the traceWroteRequest hook if the server replied while we're still writing the request, since that code was in the same spot and it couldn't be trivially separated. Updates golang/go#13851 (fixed after integrating it into std) Updates golang/go#15744 Change-Id: I67dfd68532daa6c4a0c026549c6e5cbfce50e1ea Reviewed-on: https://go-review.googlesource.com/23235 Reviewed-by: Andrew Gerrand <email@example.com>