1. 28 Nov, 2017 4 commits
  2. 27 Nov, 2017 3 commits
  3. 23 Nov, 2017 1 commit
  4. 22 Nov, 2017 1 commit
  5. 15 Nov, 2017 1 commit
  6. 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
  7. 02 Nov, 2017 2 commits
  8. 01 Nov, 2017 1 commit
  9. 27 Oct, 2017 1 commit
  10. 26 Oct, 2017 1 commit
  11. 24 Oct, 2017 1 commit
  12. 23 Oct, 2017 2 commits
  13. 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
  14. 19 Oct, 2017 1 commit
  15. 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
  16. 04 Oct, 2017 2 commits
  17. 27 Sep, 2017 1 commit
  18. 26 Sep, 2017 1 commit
  19. 22 Sep, 2017 1 commit
  20. 20 Sep, 2017 3 commits
  21. 15 Sep, 2017 1 commit
  22. 14 Sep, 2017 1 commit
  23. 12 Sep, 2017 1 commit
  24. 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
  26. 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
  27. 08 Aug, 2017 3 commits
  28. 26 Jul, 2017 1 commit