1. 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
  2. 29 Sep, 2016 4 commits
  3. 24 Sep, 2016 3 commits
  4. 21 Sep, 2016 1 commit
  5. 20 Sep, 2016 1 commit
  6. 16 Sep, 2016 1 commit
  7. 14 Sep, 2016 2 commits
  8. 12 Sep, 2016 3 commits
  9. 10 Sep, 2016 1 commit
  10. 07 Sep, 2016 1 commit
  11. 01 Sep, 2016 1 commit
  12. 31 Aug, 2016 1 commit
  13. 26 Aug, 2016 5 commits
  14. 25 Aug, 2016 1 commit
  15. 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
  16. 11 Aug, 2016 1 commit
  17. 05 Aug, 2016 1 commit
  18. 04 Aug, 2016 1 commit
  19. 03 Aug, 2016 2 commits
  20. 02 Aug, 2016 1 commit
  21. 01 Aug, 2016 2 commits
    • 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
    • Brad Fitzpatrick's avatar
      http2: don't ignore DATA padding in flow control · 35028a49
      Brad Fitzpatrick authored
      http://httpwg.org/specs/rfc7540.html#rfc.section.6.1 says:
      
      > The entire DATA frame payload is included in flow control, including
      > the Pad Length and Padding fields if present.
      
      But we were just ignoring the padding and pad length, which could lead
      to clients and servers getting out of sync and deadlock if peers used
      padding. (Go never does, so it didn't affect Go<->Go)
      
      In the process, fix a lingering bug from golang/go#16481 where we
      didn't account for flow control returned to peers in the stream's
      inflow, despite sending the peer a WINDOW_UPDATE.
      
      Fixes golang/go#16556
      Updates golang/go#16481
      
      Change-Id: If7150fa8f0da92a60f34af9c3f754a0346526ece
      Reviewed-on: https://go-review.googlesource.com/25382
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarAndrew Gerrand <adg@golang.org>
      35028a49
  22. 26 Jul, 2016 2 commits
  23. 20 Jul, 2016 1 commit
  24. 17 Jul, 2016 1 commit