1. 04 May, 2016 14 commits
  2. 03 May, 2016 9 commits
  3. 02 May, 2016 8 commits
  4. 01 May, 2016 9 commits
    • Keith Randall's avatar
      cmd/compile: fix reslice · ade0eb2f
      Keith Randall authored
      := is the wrong thing here.  The new variable masks the old
      variable so we allocate the slice afresh each time around the loop.
      
      Change-Id: I759c30e1bfa88f40decca6dd7d1e051e14ca0844
      Reviewed-on: https://go-review.googlesource.com/22679
      Run-TryBot: Keith Randall <khr@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarMinux Ma <minux@golang.org>
      ade0eb2f
    • Brad Fitzpatrick's avatar
      net/http: fix typo in comment · 24c05e7e
      Brad Fitzpatrick authored
      Change-Id: I753e62879a56582a9511e3f34fdeac929202efbf
      Reviewed-on: https://go-review.googlesource.com/22680Reviewed-by: 's avatarRalph Corderoy <ralph@inputplus.co.uk>
      Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      24c05e7e
    • Brad Fitzpatrick's avatar
      net/http: add Response.Uncompressed bool · ca8b6270
      Brad Fitzpatrick authored
      The Transport's automatic gzip uncompression lost information in the
      process (the compressed Content-Length, if known). Normally that's
      okay, but it's not okay for reverse proxies which have to be able to
      generate a valid HTTP response from the Transport's provided
      *Response.
      
      Reverse proxies should normally be disabling compression anyway and
      just piping the compressed pipes though and not wasting CPU cycles
      decompressing them. So also document that on the new Uncompressed
      field.
      
      Then, using the new field, fix Response.Write to not inject a bogus
      "Connection: close" header when it doesn't see a transfer encoding or
      content-length.
      
      Updates #15366 (the http2 side remains, once this is submitted)
      
      Change-Id: I476f40aa14cfa7aa7b3bf99021bebba4639f9640
      Reviewed-on: https://go-review.googlesource.com/22671Reviewed-by: 's avatarAndrew Gerrand <adg@golang.org>
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      ca8b6270
    • Brad Fitzpatrick's avatar
      net/http: provide access to the listener address an HTTP request arrived on · a9cf0b1e
      Brad Fitzpatrick authored
      This adds a context key named LocalAddrContextKey (for now, see #15229) to
      let users access the net.Addr of the net.Listener that accepted the connection
      that sent an HTTP request. This is similar to ServerContextKey which provides
      access to the *Server. (A Server may have multiple Listeners)
      
      Fixes #6732
      
      Change-Id: I74296307b68aaaab8df7ad4a143e11b5227b5e62
      Reviewed-on: https://go-review.googlesource.com/22672Reviewed-by: 's avatarAndrew Gerrand <adg@golang.org>
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      a9cf0b1e
    • Brad Fitzpatrick's avatar
      net/http: add Transport.IdleConnTimeout · abc1472d
      Brad Fitzpatrick authored
      Don't keep idle HTTP client connections open forever. Add a new knob,
      Transport.IdleConnTimeout, and make the default be 90 seconds. I
      figure 90 seconds is more than a minute, and less than infinite, and I
      figure enough code has things waking up once a minute polling APIs.
      
      This also removes the Transport's idleCount field which was unused and
      redundant with the size of the idleLRU map (which was actually used).
      
      Change-Id: Ibb698a9a9a26f28e00a20fe7ed23f4afb20c2322
      Reviewed-on: https://go-review.googlesource.com/22670Reviewed-by: 's avatarAndrew Gerrand <adg@golang.org>
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      abc1472d
    • Brad Fitzpatrick's avatar
      net/http: fix a few crashes with a ClientTrace with nil funcs · 0ab78df9
      Brad Fitzpatrick authored
      And add a test.
      
      Updates #12580
      
      Change-Id: Ia7eaba09b8e7fd0eddbcaefb948d01ab10af876e
      Reviewed-on: https://go-review.googlesource.com/22659Reviewed-by: 's avatarAndrew Gerrand <adg@golang.org>
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      0ab78df9
    • Brad Fitzpatrick's avatar
      net/http: document some errors more, mark ErrWriteAfterFlush as unused · b3a130e8
      Brad Fitzpatrick authored
      Fixes #15150
      
      Change-Id: I1a892d5b0516a37dac050d3bb448e0a2571db16e
      Reviewed-on: https://go-review.googlesource.com/22658Reviewed-by: 's avatarAndrew Gerrand <adg@golang.org>
      b3a130e8
    • Josh Bleecher Snyder's avatar
      archive/zip: improve BenchmarkCompressedZipGarbage · d713e8e8
      Josh Bleecher Snyder authored
      Before this CL:
      
      $ go test -bench=CompressedZipGarbage -count=5 -run=NONE archive/zip
      BenchmarkCompressedZipGarbage-8        50  20677087 ns/op   42973 B/op      47 allocs/op
      BenchmarkCompressedZipGarbage-8       100  20584764 ns/op   24294 B/op      47 allocs/op
      BenchmarkCompressedZipGarbage-8        50  20859221 ns/op   42973 B/op      47 allocs/op
      BenchmarkCompressedZipGarbage-8       100  20901176 ns/op   24294 B/op      47 allocs/op
      BenchmarkCompressedZipGarbage-8        50  21282409 ns/op   42973 B/op      47 allocs/op
      
      The B/op number is effectively meaningless. There
      is a surprisingly large one-time cost that gets
      divided by the number of iterations that your
      machine can get through in a second.
      
      This CL discards the first run, which helps.
      It is not a panacea. Running with -benchtime=10s
      will allow the sync.Pool to be emptied,
      which brings the problem back.
      However, since there are more iterations to divide
      the cost through, it’s not quite as bad,
      and running with a high benchtime is rare.
      
      This CL changes the meaning of the B/op number,
      which is unfortunate, since it won’t have the
      same order of magnitude as previous Go versions.
      But it wasn’t really comparable before anyway,
      since it didn’t have any reliable meaning at all.
      
      After this CL:
      
      $ go test -bench=CompressedZipGarbage -count=5 -run=NONE archive/zip
      BenchmarkCompressedZipGarbage-8   	     100	  20881890 ns/op	    5616 B/op	      47 allocs/op
      BenchmarkCompressedZipGarbage-8   	      50	  20622757 ns/op	    5616 B/op	      47 allocs/op
      BenchmarkCompressedZipGarbage-8   	      50	  20628193 ns/op	    5616 B/op	      47 allocs/op
      BenchmarkCompressedZipGarbage-8   	     100	  20756612 ns/op	    5616 B/op	      47 allocs/op
      BenchmarkCompressedZipGarbage-8   	     100	  20639774 ns/op	    5616 B/op	      47 allocs/op
      
      Change-Id: Iedee04f39328974c7fa272a6113d423e7ffce50f
      Reviewed-on: https://go-review.googlesource.com/22585Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      d713e8e8
    • Brad Fitzpatrick's avatar
      doc: update go1.7.txt · 3836354f
      Brad Fitzpatrick authored
      Change-Id: I53dd5affc3a1e1f741fe44c7ce691bb2cd432764
      Reviewed-on: https://go-review.googlesource.com/22657Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      3836354f