- 01 Feb, 2016 1 commit
-
-
Brad Fitzpatrick authored
This adds a way for http.Handlers to set trailers after the header has already been flushed. This comment from the code explains: // promoteUndeclaredTrailers permits http.Handlers to set trailers // after the header has already been flushed. Because the Go // ResponseWriter interface has no way to set Trailers (only the // Header), and because we didn't want to expand the ResponseWriter // interface, and because nobody used trailers, and because RFC 2616 // says you SHOULD (but not must) predeclare any trailers in the // header, the official ResponseWriter rules said trailers in Go must // be predeclared, and then we reuse the same ResponseWriter.Header() // map to mean both Headers and Trailers. When it's time to write the // Trailers, we pick out the fields of Headers that were declared as // trailers. That worked for a while, until we found the first major // user of Trailers in the wild: gRPC (using them only over http2), // and gRPC libraries permit setting trailers mid-stream without // predeclarnig them. So: change of plans. We still permit the old // way, but we also permit this hack: if a Header() key begins with // "Trailer:", the suffix of that key is a Trailer. Because ':' is an // invalid token byte anyway, there is no ambiguity. (And it's already // filtered out) It's mildly hacky, but not terrible. The official pre-declaring way still works. Example from net/http docs: https://golang.org/pkg/net/http/#example_ResponseWriter_trailers And ResponseWriter docs explaining it: https://golang.org/pkg/net/http/#ResponseWriter I don't want to add a new interface-assertable upgrade type (like Hijacker or Flusher) for this because it's hurts composability and makes everybody in the ecocsystem implement those, and two optional interfaces is already bad enough. This is a weird enough feature (Trailers by itself is weird enough), that I don't feel like a third optional interface is worth it. This code also filters invalid header fields (updates golang/go#14048), since I had to update that code as part of this. But I want to later return an error back to the user if possible. Or log something. With this CL, all the grpc-go end2end tests pass with a new http2-based Server implementation: https://github.com/bradfitz/grpc-go/commit/a06f8f0593bfa8a0af72e57fb3916144f7b30121 Change-Id: I80f863d05a1810bd6f302f34932ad9df0a6646a6 Reviewed-on: https://go-review.googlesource.com/19131Reviewed-by: Andrew Gerrand <adg@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 26 Jan, 2016 3 commits
-
-
Brad Fitzpatrick authored
Leftover from https://golang.org/cl/18932 Change-Id: I41c1adfdebd7dff0f75c2ba2b669f13b163984a2 Reviewed-on: https://go-review.googlesource.com/18936Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Brad Fitzpatrick authored
Recognize connection aborted errors on Windows and don't log them by default, like the Unix case. Log frame reading errors only at verbose level, to match net/http.Server. Updates golang/go#13925 Updates golang/go#14061 Change-Id: I87998a924b11d4dad5512e010b29d2da6b4bf867 Reviewed-on: https://go-review.googlesource.com/18932Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Brad Fitzpatrick authored
Fixes golang/go#14065 Change-Id: Ic19a0f740cddced8fb782f65cea14da383b047b1 Reviewed-on: https://go-review.googlesource.com/18802Reviewed-by: Olivier Poitrey <rs@rhapsodyk.net> Reviewed-by: Daniel Morsing <daniel.morsing@gmail.com> Reviewed-by: Chris Broadfoot <cbro@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
-
- 21 Jan, 2016 1 commit
-
-
Brad Fitzpatrick authored
(addressing review comments from Ralph Corderoy in https://golang.org/cl/18728) Change-Id: I22457a6f768f9136a0e6b84964f0eaf33983c75f Reviewed-on: https://go-review.googlesource.com/18801 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ralph Corderoy <ralph@inputplus.co.uk> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
- 20 Jan, 2016 2 commits
-
-
Brad Fitzpatrick authored
This validates incoming header field values in Server and Transport to make sure the peer isn't sending us a \x00, CR, NL or other non-VCHAR except space and tab. It does not yet validate that we don't send such things, though. Updates golang/go#14029 Change-Id: I7c6a56d5d0d255f1b8fa64480b34b3b5e1f4f367 Reviewed-on: https://go-review.googlesource.com/18727Reviewed-by: Andrew Gerrand <adg@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Brad Fitzpatrick authored
Updates letsencrypt/boulder#1374 Change-Id: I853e08d94cbe235a3a1bbff28e1b121c4589b810 Reviewed-on: https://go-review.googlesource.com/18724Reviewed-by: Andrew Gerrand <adg@golang.org>
-
- 19 Jan, 2016 2 commits
-
-
Brad Fitzpatrick authored
Forgot to git mail after https://golang.org/cl/18721 Change-Id: Ie5e2ad91e7580d5283b19b68491fd10978fa2488 Reviewed-on: https://go-review.googlesource.com/18722 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Brad Fitzpatrick authored
The http2 Transport now respects the http1 Transport's DisableCompression, DisableKeepAlives, and ResponseHeaderTimeout, if the http2 and http1 Transports are wired up together, as they are in the upcoming Go 1.6. Updates golang/go#14008 Change-Id: I2f477f6fe5dbef9d0e5439dfc7f3ec2c0da7f296 Reviewed-on: https://go-review.googlesource.com/18721Reviewed-by: Andrew Gerrand <adg@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 18 Jan, 2016 1 commit
-
-
Brad Fitzpatrick authored
Same policy and logic (and comments) as the net/http.Transport. Updates golang/go#14003 Change-Id: I5744140fed16c00b0dc9a4bc74631b7df7d8241c Reviewed-on: https://go-review.googlesource.com/18709Reviewed-by: Andrew Gerrand <adg@golang.org>
-
- 16 Jan, 2016 1 commit
-
-
Brad Fitzpatrick authored
This is needed so another CL in the main repo can keep the pointer around to pass through Transport.CloseIdleConnections from the http1 transport. This CL doesn't modify the exported ConfigureTransport signature. We'll use the private one in the standard library for now. (since it gets bundled into the same package) Updates golang/go#13975 Change-Id: I824e9ac4a44616c8c2a480f83bd3dc62bffc30e4 Reviewed-on: https://go-review.googlesource.com/18678Reviewed-by: Andrew Gerrand <adg@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 15 Jan, 2016 2 commits
-
-
Brad Fitzpatrick authored
If a user starts two HTTP requests when no http2 connection is available, both end up creating new TCP connections, since the server's protocol (h1 or h2) isn't yet known. Once it turns out that the server supports h2, one of the connections is useless. Previously we kept upgrading both TLS connections to h2 (SETTINGS frame exchange, etc). Now the unnecessary connections are closed instead, before the h2 preface/SETTINGS. Tests in the standard library (where it's easier to test), in the commit which updates h2_bundle.go with this change. Updates golang/go#13957 Change-Id: I5af177e6ea755d572b551cc0b0de9da865ef4ae7 Reviewed-on: https://go-review.googlesource.com/18675Reviewed-by: Andrew Gerrand <adg@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Nigel Tao authored
Change-Id: I327897f8fa06e4f65dbd32b81be80fdc438bc6e0 Reviewed-on: https://go-review.googlesource.com/18656Reviewed-by: David Symonds <dsymonds@golang.org>
-
- 13 Jan, 2016 5 commits
-
-
Brad Fitzpatrick authored
I can't reproduce the user's bug yet, but this might fix or at least help clarify what's happening. Also deflakes a test. Updates golang/go#13932 Change-Id: If56bdd833f183d4502701e65e56749434bd82150 Reviewed-on: https://go-review.googlesource.com/18576Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Brad Fitzpatrick authored
plan9's network deadline & cancelation code is so brittle that it's not even worth testing this package there. It only results in 10 minute deadlocks and slows down the trybots which should be ~30 seconds, not 10 minutes. Change-Id: I097a885ae5887f0ecf357611aa7fae8885e18e05 Reviewed-on: https://go-review.googlesource.com/18578Reviewed-by: Chris Broadfoot <cbro@golang.org>
-
Brad Fitzpatrick authored
They lack terminal.MakeRaw and terminal.Restore. Updates golang/go#11811 Change-Id: I1e5d8ca90b2f9c13fe7a6396c2f86e0a5b392b84 Reviewed-on: https://go-review.googlesource.com/18577 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Chris Broadfoot <cbro@golang.org>
-
Alex Brainman authored
Updates golang/go#13434 Change-Id: Icc098d9a6e1af55d36e828fa21d88b967f2f0131 Reviewed-on: https://go-review.googlesource.com/18553Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Change-Id: I259fb17d9cf14c11e4930d48d1657947404b6ada Reviewed-on: https://go-review.googlesource.com/18474Reviewed-by: Blake Mizerany <blake.mizerany@gmail.com>
-
- 12 Jan, 2016 2 commits
-
-
Brad Fitzpatrick authored
When an active http2 connection closed, a stream's done channel could be closed twice and panic. Fixes golang/go#13924 Change-Id: I5e050b2788070321131ca2756a899f968e9bc0b2 Reviewed-on: https://go-review.googlesource.com/18571Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Brad Fitzpatrick authored
Make sure that both the server and client can see typed errors when the peer's body is interrupted by a stream reset. grpc will need this. Turns out things were okay, but the behavior wasn't locked in. Now it is. Change-Id: I449a52e368efe9a3d44c59cc9a4fc15365bc4f12 Reviewed-on: https://go-review.googlesource.com/18502Reviewed-by: Andrew Gerrand <adg@golang.org>
-
- 11 Jan, 2016 1 commit
-
-
Tal Shprecher authored
Change-Id: I43ad7497db6b4d57efd2ab94f7af26e3eb0dcdf5 Reviewed-on: https://go-review.googlesource.com/18485Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
- 09 Jan, 2016 1 commit
-
-
Blake Mizerany authored
Change-Id: I742866d94c6a9325a4970d528f1e46b9e2d7fdbc Reviewed-on: https://go-review.googlesource.com/18472Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
- 08 Jan, 2016 1 commit
-
-
Andy Balholm authored
The old test for EUC-KR was copied from the first web page that I could find that was encoded in EUC-KR; the new one is the first line of golang.org/x/text/internal/testtext.Korean. Change-Id: I3de076256c935088a06138056cde216190766a6d Reviewed-on: https://go-review.googlesource.com/18063Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>
-
- 07 Jan, 2016 5 commits
-
-
Brad Fitzpatrick authored
GODEBUG=h2debug=1 is now GODEBUG=http2debug=1, per golang/go#13611 (comment https://github.com/golang/go/issues/13611#issuecomment-169534496) and there is a new debugging level h2debug=2 for logging all written frames as well, which was code I originally wrote for debugging the lego/ACME/Akamai issues in golang/go#13637 and letsencrypt/boulder#1279. This also moves the common vlogf calls inside if VerboseLogs blocks, to avoid allocations. I didn't do the rare ones. Example client output, fetching https://ip.appspot.com/: 2016/01/07 23:24:52 http2: Transport failed to get client conn for ip.appspot.com:443: http2: no cached connection was available 2016/01/07 23:24:52 http2: Transport creating client conn to 64.233.183.141:443 2016/01/07 23:24:52 http2: Framer 0xc82028c420: wrote SETTINGS len=12, settings: ENABLE_PUSH=0, INITIAL_WINDOW_SIZE=4194304 2016/01/07 23:24:52 http2: Framer 0xc82028c420: wrote WINDOW_UPDATE len=4 (conn) incr=1073741824 2016/01/07 23:24:52 http2: Framer 0xc82028c420: wrote SETTINGS flags=ACK len=0 2016/01/07 23:24:52 http2: Transport encoding header ":authority" = "ip.appspot.com" 2016/01/07 23:24:52 http2: Transport encoding header ":method" = "GET" 2016/01/07 23:24:52 http2: Transport encoding header ":path" = "/" 2016/01/07 23:24:52 http2: Transport encoding header ":scheme" = "https" 2016/01/07 23:24:52 http2: Transport encoding header "accept-encoding" = "gzip" 2016/01/07 23:24:52 http2: Transport encoding header "user-agent" = "Go-http-client/2.0" 2016/01/07 23:24:52 http2: Transport received WINDOW_UPDATE len=4 (conn) incr=983041 2016/01/07 23:24:52 http2: Framer 0xc82028c420: wrote HEADERS flags=END_STREAM|END_HEADERS stream=1 len=35 2016/01/07 23:24:52 http2: Transport received SETTINGS flags=ACK len=0 2016/01/07 23:24:52 http2: Transport received HEADERS flags=END_HEADERS stream=1 len=123 2016/01/07 23:24:52 http2: Transport decoded header field ":status" = "200" 2016/01/07 23:24:52 http2: Transport decoded header field "content-type" = "text/plain;" 2016/01/07 23:24:52 http2: Transport decoded header field "date" = "Thu, 07 Jan 2016 23:24:52 GMT" 2016/01/07 23:24:52 http2: Transport decoded header field "server" = "Google Frontend" 2016/01/07 23:24:52 http2: Transport decoded header field "content-length" = "14" 2016/01/07 23:24:52 http2: Transport decoded header field "alternate-protocol" = "443:quic,p=1" 2016/01/07 23:24:52 http2: Transport decoded header field "alt-svc" = "quic=\":443\"; ma=604800; v=\"30,29,28,27,26,25\"" 2016/01/07 23:24:52 http2: Transport received DATA flags=END_STREAM stream=1 len=14 data="146.148.92.232" 2016/01/07 23:24:52 http2: Transport received PING len=8 ping="\x00\x00\x00\x00\x00\x00\x00\x00" 2016/01/07 23:24:52 http2: Framer 0xc82028c420: wrote PING flags=ACK len=8 ping="\x00\x00\x00\x00\x00\x00\x00\x00" Example server output, with a client fetching / and getting a 404: 2016/01/07 23:25:45 http2: server connection from 72.14.229.81:58273 on 0xc820066100 2016/01/07 23:25:45 http2: server: error reading preface from client 72.14.229.81:58273: EOF 2016/01/07 23:25:45 http2: Framer 0xc820228210: wrote SETTINGS len=18, settings: MAX_FRAME_SIZE=1048576, MAX_CONCURRENT_STREAMS=250, MAX_HEADER_LIST_SIZE=1048896 2016/01/07 23:25:45 http2: server connection from 72.14.229.81:6801 on 0xc820066100 2016/01/07 23:25:45 http2: Framer 0xc8202e8370: wrote SETTINGS len=18, settings: MAX_FRAME_SIZE=1048576, MAX_CONCURRENT_STREAMS=250, MAX_HEADER_LIST_SIZE=1048896 2016/01/07 23:25:45 http2: server: client 72.14.229.81:6801 said hello 2016/01/07 23:25:45 http2: server read frame SETTINGS len=12, settings: MAX_CONCURRENT_STREAMS=1000, INITIAL_WINDOW_SIZE=6291456 2016/01/07 23:25:45 http2: server processing setting [MAX_CONCURRENT_STREAMS = 1000] 2016/01/07 23:25:45 http2: server processing setting [INITIAL_WINDOW_SIZE = 6291456] 2016/01/07 23:25:45 http2: Framer 0xc8202e8370: wrote SETTINGS flags=ACK len=0 2016/01/07 23:25:45 http2: server read frame WINDOW_UPDATE len=4 (conn) incr=15663105 2016/01/07 23:25:45 http2: server read frame HEADERS flags=END_STREAM|END_HEADERS|PRIORITY stream=1 len=238 2016/01/07 23:25:45 http2: server decoded header field ":method" = "GET" 2016/01/07 23:25:45 http2: server decoded header field ":authority" = "(redacted):4430" 2016/01/07 23:25:45 http2: server decoded header field ":scheme" = "https" 2016/01/07 23:25:45 http2: server decoded header field ":path" = "/" 2016/01/07 23:25:45 http2: server decoded header field "cache-control" = "max-age=0" 2016/01/07 23:25:45 http2: server decoded header field "accept" = "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8" 2016/01/07 23:25:45 http2: server decoded header field "upgrade-insecure-requests" = "1" 2016/01/07 23:25:45 http2: server decoded header field "user-agent" = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537." 2016/01/07 23:25:45 http2: server decoded header field "accept-encoding" = "gzip, deflate, sdch" 2016/01/07 23:25:45 http2: server decoded header field "accept-language" = "en-US,en;q=0.8" 2016/01/07 23:25:45 http2: server encoding header ":status" = "404" 2016/01/07 23:25:45 http2: server encoding header "content-type" = "text/plain; charset=utf-8" 2016/01/07 23:25:45 http2: server encoding header "x-content-type-options" = "nosniff" 2016/01/07 23:25:45 http2: server encoding header "content-length" = "19" 2016/01/07 23:25:45 http2: server encoding header "date" = "Thu, 07 Jan 2016 23:25:45 GMT" 2016/01/07 23:25:45 http2: Framer 0xc8202e8370: wrote HEADERS flags=END_HEADERS stream=1 len=73 2016/01/07 23:25:45 http2: Framer 0xc8202e8370: wrote DATA flags=END_STREAM stream=1 len=19 data="404 page not found\n" 2016/01/07 23:25:45 http2: server read frame SETTINGS flags=ACK len=0 Change-Id: Ifb3fe4e588ff54abd8bc3facbb419c3c3809bcba Reviewed-on: https://go-review.googlesource.com/18372Reviewed-by: Blake Mizerany <blake.mizerany@gmail.com> Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Brad Fitzpatrick authored
Just re-reading the code and polishing things up. Nothing major. Enforcing the max header list size in the Transport and letting it be configurable (not exposed in Go 1.6, only via x/net) is the most notable. Mostly just tests. Change-Id: Iacbad5a0b1ba0df9296b1aecfbc8b9b83323d435 Reviewed-on: https://go-review.googlesource.com/18367Reviewed-by: Blake Mizerany <blake.mizerany@gmail.com>
-
Brad Fitzpatrick authored
This makes the Transport ignore 100-continue responses from servers, rather than get confused by them. This is good enough for golang/go#13659. I filed golang/go#13851 to do better later, but that's less important. This CL also adds comprehensive tests for the 36 different ways that frames can be arranged from servers when reading a response. That exposed some bugs (now fixed), and even affected the http2 API: I'd added a END_STREAM accessor on CONTINUATION frames, but it's not even valid there. I also renamed some confusing variables which sounded too similar. Updates golang/go#13659 Updates golang/go#13851 Change-Id: I58868a27258981267f1b2043f711f50a42ec744a Reviewed-on: https://go-review.googlesource.com/18370Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Mikio Hara authored
Change-Id: Ic4a3cc83d0f76a6a0d5e90b256761877151ab1e9 Reviewed-on: https://go-review.googlesource.com/18279Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
The Transport code wasn't always sending a RST_STREAM to the server in a few cases, and was also forgetting to flush its buffer. I believe each part of this change was part of making golang/go#13556 not flaky. No additional tests at the moment; TestTransportAndServerSharedBodyRace_h2 is pretty comprehensive as-is, at least for an integration test. I should probably add some finer-grained tests in the future. Updates golang/go#13556 Change-Id: Ie824202b20ba6ee85b20edeeee86ec977e6daeb2 Reviewed-on: https://go-review.googlesource.com/18288Reviewed-by: Andrew Gerrand <adg@golang.org>
-
- 06 Jan, 2016 2 commits
-
-
Brad Fitzpatrick authored
Tests in main repo, named: === RUN TestTransportUserAgent_h1 --- PASS: TestTransportUserAgent_h1 (0.00s) === RUN TestTransportUserAgent_h2 --- PASS: TestTransportUserAgent_h2 (0.03s) (in upcoming CL) Updates golang/go#13685 Change-Id: I2b62489eb03b7ff791f1f6ae6dc9c4e4f6895d39 Reviewed-on: https://go-review.googlesource.com/18285Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Brad Fitzpatrick authored
Support CONNECT requests in both the server & transport. See https://httpwg.github.io/specs/rfc7540.html#CONNECT When I bundle this into the main Go repo I will also add h1-vs-h2 compatibility tests there, making sure they match behavior. (I now expect that they do match) Updates golang/go#13717 Change-Id: I0c65ad47b029419027efb616fed3d8e0e2a363f4 Reviewed-on: https://go-review.googlesource.com/18266Reviewed-by: Andrew Gerrand <adg@golang.org>
-
- 05 Jan, 2016 1 commit
-
-
Dave Day authored
Fixes #13325. Change-Id: I17f35232cd0ea43e50ea12db09272195789426e9 Reviewed-on: https://go-review.googlesource.com/18188Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
- 04 Jan, 2016 1 commit
-
-
Tamir Duberstein authored
Without this, if the responses are compressed, Chrome's content-type detection will fail and it will attempt to download these pages rather than render them as HTML. Change-Id: Ib5f803f335d55a00a759de85d38855ee0ae13ee0 Reviewed-on: https://go-review.googlesource.com/18230Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
- 29 Dec, 2015 1 commit
-
-
Brad Fitzpatrick authored
Removes state machine complication and duplication out of Server & Transport and puts it into the Framer instead (where it's nicely tested). Also, for testing, start tracking the reason for errors. Later we'll use it in GOAWAY frames' debug data too. Change-Id: Ic933654a33edb62b4432c28fe09f7bfdb6f9b334 Reviewed-on: https://go-review.googlesource.com/18101Reviewed-by: Blake Mizerany <blake.mizerany@gmail.com>
-
- 24 Dec, 2015 2 commits
-
-
Brad Fitzpatrick authored
Change-Id: Icb13d896a79e44fbddba0a4776be2da7918edd33 Reviewed-on: https://go-review.googlesource.com/18109Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Brad Fitzpatrick authored
When the http2 Server reads a frame resulting in a ConnectionError it first sends a GOAWAY frame (optionally with debug data telling the peer's implementation what they did wrong) and then pauses for a bit before shutting down the connection. The pause is because in general, GOAWAY frames are used for graceful shutdown where the server tells the client which maximum stream ID it received and will process. and the client knows it can retry higher stream IDs. The Go server was spinning in readFrames in the time between reading certain types of errors and the connection going away. Change-Id: Ie8c4988684a82cbb87be20086ba371355947163a Reviewed-on: https://go-review.googlesource.com/18105Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
- 21 Dec, 2015 1 commit
-
-
Jeff R. Allen authored
Return DebugGoroutines to its original setting after turning it on for the test. Change-Id: I860f3b03d3736617657f124f957efe89fbe12104 Reviewed-on: https://go-review.googlesource.com/18070Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
- 19 Dec, 2015 1 commit
-
-
Marcel van Lohuizen authored
Change-Id: I4083c38468981128c3d74310cd02335c35eafa5d Reviewed-on: https://go-review.googlesource.com/17966Reviewed-by: Andy Balholm <andy@balholm.com> Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
-
- 17 Dec, 2015 3 commits
-
-
Brad Fitzpatrick authored
The Transport's Response.Body.Close call was closing the Response.Body, but the Reader implementation was yielding its buffered data before returning the error. Add a new method to force an immediate close. An audit of the other CloseWithError callers found that the after-buffered-data behavior was correct for them. New tests in the main go repo in net/http/clientserver_test.go: TestResponseBodyReadAfterClose_h1 and TestResponseBodyReadAfterClose_h2 Updates golang/go#13648 Change-Id: If3a13a20c106b5a7bbe668ccb4e3c704a0e0682b Reviewed-on: https://go-review.googlesource.com/17937Reviewed-by: Russ Cox <rsc@golang.org>
-
Blake Mizerany authored
Change-Id: I9cb50eeb3f183f4237d7ba123b8123582fd37882 Reviewed-on: https://go-review.googlesource.com/17912Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Marcel van Lohuizen authored
Change-Id: I11ffc61623496fae6b32e678c91f7609d71aefe5 Reviewed-on: https://go-review.googlesource.com/17961Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com> Reviewed-by: Andy Balholm <andy@balholm.com>
-