Skip to content

N
net
Switch branch/tag
  1. 20 Oct, 2017 1 commit
    • Tom Bergan's avatar
      http2: always delay closing the connection after sending GOAWAY · cd69bc3f
      Tom Bergan authored 
      Currently, we close the connection immediately after sending a GOAWAY
frame if all outstanding responses have been completely sent. However,
the client may have had requests in-flight at that time which have been
queued in the kernel receive buffer. On both Windows and Linux, if the
connection is close()'d when the receive buffer is not empty, the kernel
sends RST. This has the effect of aborting both sides of the connection,
meaning the client may not actually receive all responses that were sent
before the GOAWAY.

Instead, we should delay calling close() until after the receive buffer
has been drained. We don't want to delay indefinitely, which means we
need some kind of timeout. Ideally that timeout should be about 1 RTT +
epsilon, under the assumption that the client will not send any more
frames after receiving the GOAWAY. However, 1 RTT is difficult to
measure. It turns out we were already using a 1 second delay in other
cases, so we reuse that same delay here.

Note that we do not call CloseWrite() to half-close the underlying TLS
connection. This seems unnecessary -- GOAWAY is effectively a half-close
at the HTTP/2 level.

Updates golang/go#18701 (fixes after it's bundled into net/http)

Change-Id: I4d68bada6369ba95e5db02afe6dfad0a393c0334
Reviewed-on: https://go-review.googlesource.com/71372
Run-TryBot: Tom Bergan <tombergan@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: 's avatarJoe Tsai <thebrokentoaster@gmail.com>
      cd69bc3f
  3. 19 Oct, 2017 1 commit
  5. 16 Oct, 2017 1 commit
    • Anand K. Mistry's avatar
      net/http2: reset client stream after processing response headers · 1087133b
      Anand K. Mistry authored 
      When a client receives a HEADER frame with a END_STREAM flag,
clientConn.streamByID closes the stream before processing the headers
which may contain a full non-error response. This causes the request's
bodyWriter cancelation to race with the response.

Closing the stream after processing headers allows the response to be
available before the bodyWriter is canceled.

Updates golang/go#20521

Change-Id: I70740e88f75240836e922163a54a6cd89535f7b3
Reviewed-on: https://go-review.googlesource.com/70510
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: 's avatarTom Bergan <tombergan@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      1087133b
  7. 04 Oct, 2017 2 commits
  9. 27 Sep, 2017 1 commit
  11. 26 Sep, 2017 1 commit
  13. 22 Sep, 2017 1 commit
  15. 20 Sep, 2017 3 commits
  17. 15 Sep, 2017 1 commit
  19. 14 Sep, 2017 1 commit
  21. 12 Sep, 2017 1 commit
  23. 28 Aug, 2017 1 commit
    • Mike Appleby's avatar
      http2: Respect peer's SETTINGS_MAX_HEADER_LIST_SIZE in ClientConn · 66aacef3
      Mike Appleby authored 
      Add a new peerMaxHeaderListSize member to ClientConn which records the
SETTINGS_MAX_HEADER_LIST_SIZE requested by the client's peer, and
respect this limit in (*ClientConn) encodeHeaders / encodeTrailers.

Attempting to send more than peerMaxHeaderListSize bytes of headers or
trailers will result in RoundTrip returning errRequestHeaderListSize.

Updates golang/go#13959

Change-Id: Ic707179782acdf8ae543429ea1af7f4f30e67e59
Reviewed-on: https://go-review.googlesource.com/29243
Run-TryBot: Tom Bergan <tombergan@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarTom Bergan <tombergan@google.com>
      66aacef3
  25. 24 Aug, 2017 1 commit
  27. 09 Aug, 2017 1 commit
    • Tom Bergan's avatar
      http2: block RoundTrip when the Transport hits MaxConcurrentStreams · 1c05540f
      Tom Bergan authored 
      Currently if the http2.Transport hits SettingsMaxConcurrentStreams for a
server, it just makes a new TCP connection and creates the stream on the
new connection. This CL updates that behavior to instead block RoundTrip
until a new stream is available.

I also fixed a second bug, which was necessary to make some tests pass:
Previously, a stream was removed from cc.streams only if either (a) we
received END_STREAM from the server, or (b) we received RST_STREAM from
the server. This CL removes a stream from cc.streams if the request was
cancelled (via ctx.Close, req.Cancel, or resp.Body.Close) before
receiving END_STREAM or RST_STREAM from the server.

Updates golang/go#13774
Updates golang/go#20985
Updates golang/go#21229

Change-Id: I660ffd724c4c513e0f1cc587b404bedb8aff80be
Reviewed-on: https://go-review.googlesource.com/53250
Run-TryBot: Tom Bergan <tombergan@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      1c05540f
  29. 08 Aug, 2017 3 commits
  31. 26 Jul, 2017 1 commit
  33. 21 Jul, 2017 1 commit
  35. 20 Jul, 2017 1 commit
  37. 19 Jul, 2017 3 commits
  39. 18 Jul, 2017 1 commit
  41. 16 Jul, 2017 1 commit
  43. 11 Jul, 2017 1 commit
  45. 06 Jul, 2017 1 commit
  47. 04 Jul, 2017 3 commits
  49. 29 Jun, 2017 3 commits
  51. 28 Jun, 2017 1 commit
  53. 27 Jun, 2017 3 commits