1. 08 Nov, 2016 1 commit
  2. 28 Oct, 2016 1 commit
  3. 19 Oct, 2016 3 commits
  4. 18 Oct, 2016 1 commit
  5. 17 Oct, 2016 7 commits
  6. 15 Sep, 2016 1 commit
  7. 08 Sep, 2016 1 commit
  8. 07 Sep, 2016 16 commits
  9. 17 Aug, 2016 1 commit
  10. 16 Aug, 2016 1 commit
  11. 15 Aug, 2016 4 commits
  12. 08 Aug, 2016 3 commits
    • Chris Broadfoot's avatar
      go1.7rc6 · 1e933ed7
      Chris Broadfoot authored
      Change-Id: Ie76b5af0ecc4c64c523110b44483c06e7031237c
      Reviewed-on: https://go-review.googlesource.com/25582Reviewed-by: 's avatarChris Broadfoot <cbro@golang.org>
      1e933ed7
    • Chris Broadfoot's avatar
      all: merge master into release-branch.go1.7 · 78d024a5
      Chris Broadfoot authored
      7a622740 net/http: make Transport use new connection if over HTTP/2 concurrency limit
      219ca602 doc: fix required OS X version inconsistency for binary downloads
      26015b95 runtime: make stack 16-byte aligned for external code in _rt0_amd64_linux_lib
      9fde86b0 runtime, syscall: fix kernel gettimeofday ABI change on iOS 10
      3a03e877 os: check for waitid returning ENOSYS
      10316757 net/http: update bundled http2 for flow control window adjustment fix
      da070bed syscall: fix Gettimeofday on macOS Sierra
      f135c326 runtime: initialize hash algs before typemap
      
      Change-Id: Ie176f3db1e253d75ae8e56b16d3fd9900b37dde3
      78d024a5
    • Brad Fitzpatrick's avatar
      net/http: make Transport use new connection if over HTTP/2 concurrency limit · 7a622740
      Brad Fitzpatrick authored
      The Go HTTP/1 client will make as many new TCP connections as the user requests.
      
      The HTTP/2 client tried to have that behavior, but the policy of
      whether a connection is re-usable didn't take into account the extra 1
      stream counting against SETTINGS_MAX_CONCURRENT_STREAMS so in practice
      users were getting errors.
      
      For example, if the server's advertised max concurrent streams is 100
      and 200 concurrrent Go HTTP requests ask for a connection at once, all
      200 will think they can reuse that TCP connection, but then 100 will
      fail later when the number of concurrent streams exceeds 100.
      
      Instead, recognize the "no cached connections" error value in the
      shouldRetryRequest method, so those 100 will retry a new connection.
      
      This is the conservative fix for Go 1.7 so users don't get errors, and
      to match the HTTP/1 behavior. Issues #13957 and #13774 are the more
      involved bugs for Go 1.8.
      
      Updates #16582
      Updates #13957
      
      Change-Id: I1f15a7ce60c07a4baebca87675836d6fe03993e8
      Reviewed-on: https://go-review.googlesource.com/25580
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      Reviewed-by: 's avatarChris Broadfoot <cbro@golang.org>
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      7a622740