Skip to content

N
net
Switch branch/tag
  1. 02 Feb, 2018 1 commit
  3. 01 Feb, 2018 3 commits
  5. 24 Jan, 2018 1 commit
  7. 12 Jan, 2018 1 commit
  9. 10 Jan, 2018 1 commit
  11. 08 Jan, 2018 1 commit
  13. 05 Jan, 2018 1 commit
  15. 12 Dec, 2017 1 commit
  17. 07 Dec, 2017 7 commits
  19. 29 Nov, 2017 1 commit
  21. 28 Nov, 2017 5 commits
    • Tom Bergan's avatar
      http2: fix flake in net/http's TestCloseIdleConnections_h2 · 894f8ed5
      Tom Bergan authored 
      That test makes a request with no body and receives a response with no
body. The client will receive a HEADERS frame with END_STREAM. The test
assumes that the stream is closed immediately on receipt of that HEADERS
frame, i.e., before RoundTrip returns.

This assumption was broken by https://golang.org/cl/70510, which made
stream closure asynchronous w.r.t. RoundTrip.

To fix TestCloseIdleConnections_h2 while preserving the intent of CL
70510, we break processHeaders into two cases:

1. The request has a body. In this case, END_STREAM puts the stream in a
   half-closed-remote state, which means the connection is not
   necessarily idle when RoundTrip returns (since the request body is
   still being uploaded). In this case, we preserve the behavior from CL
   70510.

2. The request does not have a body. In this case, END_STREAM puts the
   stream in a closed state and we must close the stream before
   returning from RoundTrip.

The following command passes when this CL is merged into net/http:
go test -count=100000 -run=TestCloseIdleConnections_h2 net/http

Updates golang/go#22413

Change-Id: Iff2a0685a636ad51bff380e86a42b0d0eea984e5
Reviewed-on: https://go-review.googlesource.com/80139
Run-TryBot: Tom Bergan <tombergan@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      894f8ed5
    • Gregory Man's avatar
      http2: discard logger output in invalid response tests · 6921abc3
      Gregory Man authored 
      In invalid response tests logger write error messages to stderr and spam
test output.

Since we know response are invalid in these tests we can safely discard
logger output.

Fixes golang/go#22850

Change-Id: Id8c97be910f0cf7dbe2380ba632960364bc8478b
Reviewed-on: https://go-review.googlesource.com/80235Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      6921abc3
    • Brad Fitzpatrick's avatar
      http/httpproxy: fix build on Go 1.8 · fc492d2e
      Brad Fitzpatrick authored 
      Go 1.8 doesn't have t.Helper.

Fix the row of red on the dashboard.

Change-Id: I85d4bb9fe38e989dc3b6a4e99705599745b83cef
Reviewed-on: https://go-review.googlesource.com/80140
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: 's avatarTom Bergan <tombergan@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      fc492d2e
    • Tom Bergan's avatar
      http2: fix leak in activeRes by removing activeRes · e6a4aa30
      Tom Bergan authored 
      AFAICT, activeRes serves no real purpose. It is used in just two ways:

- To reduce the number of calls to closeIfIdle, which reduces the number
  of acquires of cc.mu when there are many concurrent streams. I dug
  through the CL history and could not find any benchmarks showing that
  this is necessary.

- To avoid redundant calls to cs.bufPipe.CloseWithError(err) when a read
  loop is shutdown. This is unnecessary, since redundant CloseWithError
  calls are ignored.

Since there isn't a good reason to have activeRes, the simplest way to
fix the leak is to remove activeRes entirely.

Updates golang/go#21543

Change-Id: I1d1d2dc6c946425a2772c8bf71436707021ac269
Reviewed-on: https://go-review.googlesource.com/80137Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      e6a4aa30
    • Tom Bergan's avatar
      http2: don't autodetect Content-Type when the response has an empty body · db473f6b
      Tom Bergan authored 
      This change was originally made in https://golang.org/cl/46631, however,
that change was applited to net/http/h2_bundle.go instead of x/net/http2.

Updates golang/go#20784

Change-Id: I947fa4c19f3efc400856573768140bece28276a2
Reviewed-on: https://go-review.googlesource.com/80135
Run-TryBot: Tom Bergan <tombergan@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      db473f6b
  23. 27 Nov, 2017 3 commits
  25. 23 Nov, 2017 1 commit
  27. 22 Nov, 2017 1 commit
  29. 15 Nov, 2017 1 commit
  31. 07 Nov, 2017 1 commit
    • Anmol Sethi's avatar
      http2: require either ECDSA or RSA ciphersuite · a337091b
      Anmol Sethi authored 
      The HTTP/2 RFC does indeed mandate TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
but in practice, people are also using TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
becuase they are only using an ECDSA certificate. This is the case in acme/autocert.

It doesn't make sense to enforce only RSA in cipher suites if it will
never be used because they are using a ECDSA certificate.

Change-Id: I86dac192a3eb9b74e4268310a3b550b3bd88a37f
Reviewed-on: https://go-review.googlesource.com/30721Reviewed-by: 's avatarTom Bergan <tombergan@google.com>
Run-TryBot: Tom Bergan <tombergan@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      a337091b
  33. 02 Nov, 2017 2 commits
  35. 01 Nov, 2017 1 commit
  37. 27 Oct, 2017 1 commit
  39. 26 Oct, 2017 1 commit
  41. 24 Oct, 2017 1 commit
  43. 23 Oct, 2017 2 commits
  45. 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
  47. 19 Oct, 2017 1 commit