Skip to content

N
net
Switch branch/tag
  1. 03 Oct, 2016 2 commits
  3. 01 Oct, 2016 3 commits
  5. 30 Sep, 2016 2 commits
    • Brad Fitzpatrick's avatar
      http2: in Server, disarm connection's ReadTimeout after first request · 69729301
      Brad Fitzpatrick authored 
      Fix a regression from Go 1.5 to Go 1.6: when we introduced automatic
HTTP/2 support in Go 1.6, we never handled Server.ReadTimeout. If a
user set ReadTimeout, the net/http package would set the read deadline
on the connection during the TLS handshake, but then the http2 package
would never disarm it, killing the likely-still-in-use connection
after the timeout period.

This CL changes it to disarm the timeout after the first request
headers, similar to net/http.Server.

Unlike net/http.Server, we don't re-arm it on each idle period,
because the definition of idle is more complicated with HTTP/2.

No tests here for now. Tests will be in the go repo once all the knobs
are in place and this is re-bundled into std, testing both http1 and
http2.

Updates golang/go#16450 (minimal fix for now)
Updates golang/go#14204 (considering a new http1+http2 IdleTimeout knob)

Change-Id: Iaa1570c118efda7dc0a65ba84cd77885699ec8fc
Reviewed-on: https://go-review.googlesource.com/30077Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      69729301
    • Brad Fitzpatrick's avatar
      http2: add Transport support for IdleConnTimeout · a333c534
      Brad Fitzpatrick authored 
      Tests will be in the go repo's net/http package when this
package is re-bundled into std.

Updates golang/go#16808 (fixes after bundle into std)

Change-Id: Iad31dc120bc008b1e9679bf7b2b988aac9c893c8
Reviewed-on: https://go-review.googlesource.com/30075
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      a333c534
  7. 29 Sep, 2016 4 commits
  9. 24 Sep, 2016 3 commits
  11. 21 Sep, 2016 1 commit
  13. 20 Sep, 2016 1 commit
  15. 16 Sep, 2016 1 commit
  17. 14 Sep, 2016 2 commits
  19. 12 Sep, 2016 3 commits
  21. 10 Sep, 2016 1 commit
  23. 07 Sep, 2016 1 commit
  25. 01 Sep, 2016 1 commit
  27. 31 Aug, 2016 1 commit
  29. 26 Aug, 2016 5 commits
  31. 25 Aug, 2016 1 commit
  33. 19 Aug, 2016 1 commit
    • Brad Fitzpatrick's avatar
      http2: fix protocol violation regression when writing certain request bodies · 7394c112
      Brad Fitzpatrick authored 
      The mod_h2 workaround CL (git rev 28d1bd4f,
https://golang.org/cl/25362) introduced a regression where the
Transport could write two DATA frames, both with END_STREAM, if the
Request.Body returned (non-0, io.EOF). strings.Reader, bytes.Reader
are the most common Reader types used with HTTP requests and they only
return (0, io.EOF) so we got generally lucky and things seemed to
work, but other Readers do return (non-0, io.EOF), like the HTTP
transport/server Readers. This is why we broke the HTTP proxy code,
when proxying to HTTP/2.

Updates golang/go#16788 (fixes after it's bundled into std)

Change-Id: I42684017039eacfc27ee53e9c11431f713fdaca4
Reviewed-on: https://go-review.googlesource.com/27406
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarChris Broadfoot <cbro@golang.org>
      7394c112
  35. 11 Aug, 2016 1 commit
  37. 05 Aug, 2016 1 commit
  39. 04 Aug, 2016 1 commit
  41. 03 Aug, 2016 2 commits
  43. 02 Aug, 2016 1 commit
  45. 01 Aug, 2016 1 commit
    • Brad Fitzpatrick's avatar
      http2: make Transport work around mod_h2 bug · 28d1bd4f
      Brad Fitzpatrick authored 
      The http2 server implementation in Apache (mod_http2, aka mod_h2) had
a bug where it didn't reply to the initial SETTINGS frame until it had
received a request. Apache 2.4.17 was the first Apache version to
include mod_http2 and has the bug.

The bug was fixed 20 days ago
(https://github.com/apache/httpd/commit/de4e3031aeb9775d2ebb9c917ecb1117c12d05f8)
for Apache 2.5.0 and included in the out-of-tree mod_h2 1.5.12
(https://github.com/icing/mod_h2/releases/tag/v1.5.12) but most Apache
sites are running older versions making them incompatible with Go's
client. (At least Debian Stretch and Ubuntu Xenial, currently.)

Chrome, curl, Firefox et al don't wait for the initial SETTINGS
response & ACK before sending their first request, which is why
mod_http2 didn't notice their bug for some time.

This change makes Go's http2.Transport act like other common HTTP/2
clients and not wait for the peer's SETTINGS frame & ACK before
sending the first request.

As a bonus, this reduces the latency for the first request on
connections by one RTT.

The reason we waited for the initial settings is purely
historical. Andrew and I just wrote it that way when initially
developing the client on video (https://www.youtube.com/watch?v=yG-UaBJXZ80)
because we were working top-down through the protocol and didn't
get back to optimizing the RTT away. It also seemed more compliant to
wait for the peer's SETTINGS to know the frame size and such, but as
as spec says, it's permitted for clients to not wait:

http://httpwg.org/specs/rfc7540.html#rfc.section.3.5

> To avoid unnecessary latency, clients are permitted to send
> additional frames to the server immediately after sending the client
> connection preface, without waiting to receive the server connection
> preface. It is important to note, however, that the server
> connection preface SETTINGS frame might include parameters that
> necessarily alter how a client is expected to communicate with the
> server. Upon receiving the SETTINGS frame, the client is expected to
> honor any parameters established. In some configurations, it is
> possible for the server to transmit SETTINGS before the client sends
> additional frames, providing an opportunity to avoid this issue.

So, don't wait.

Fixes golang/go#16519

Change-Id: I916827e49829f7f107a51838512816916fb553fc
Reviewed-on: https://go-review.googlesource.com/25362Reviewed-by: 's avatarAndrew Gerrand <adg@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      28d1bd4f