aboutsummaryrefslogtreecommitdiff
path: root/src/net/http/client_test.go
AgeCommit message (Collapse)Author
2023-01-26net/http: keep sensitive headers on redirects to the same hostGustavo Falco
Preserve sensitive headers on a redirect to a different port of the same host. Fixes #35104 Change-Id: I5ab57c414ce92a70e688ee684b9ff02fb062b3c6 GitHub-Last-Rev: 8d53e71e2243c141d70d27a503d0f7e6dee64c3c GitHub-Pull-Request: golang/go#54539 Reviewed-on: https://go-review.googlesource.com/c/go/+/424935 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Damien Neil <dneil@google.com> Run-TryBot: Damien Neil <dneil@google.com>
2022-10-07net/http: refactor tests to run most in HTTP/1 and HTTP/2 modesDamien Neil
Replace the ad-hoc approach to running tests in HTTP/1 and HTTP/2 modes with a 'run' function that executes a test in various modes. By default, these modes are HTTP/1 and HTTP/2, but tests can opt-in to HTTPS/1 as well. The 'run' function also takes care of post-test cleanup (running the afterTest function). The 'run' function runs tests in parallel by default. Tests which can't run in parallel (generally because they use global test hooks) pass a testNotParallel option to disable parallelism. Update clientServerTest to use t.Cleanup to clean up after itself, rather than leaving this up to tests to handle. Drop an unnecessary mutex in SetReadLoopBeforeNextReadHook. Test hooks can't be set in parallel, and we want the race detector to notify us if two simultaneous tests try to set a hook. Fixes #56032 Change-Id: I16be64913c426fc93d84abc6ad85dbd3bc191224 Reviewed-on: https://go-review.googlesource.com/c/go/+/438137 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: David Chase <drchase@google.com>
2022-08-22net/http: skip Get flakes in TestClientTimeout tests on windows/arm4Bryan C. Mills
There is already a skip in case of a later failure in the same test on these platforms. Skip the failure if it occurs earlier too. For #43120. Change-Id: Id530370caa6a7df8cae593f6fdcb66871b86b125 Reviewed-on: https://go-review.googlesource.com/c/go/+/425096 Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Damien Neil <dneil@google.com>
2022-03-31net/http: handle 3xx responses with no LocationDamien Neil
RFC 7231 does not require that a 3xx response contain a Location header. When receiving such a response, just return it to the caller rather than treating it as an error. Fixes #49281. Change-Id: I66c06d81b0922016384a0f4ff32bf52e3a3d5983 Reviewed-on: https://go-review.googlesource.com/c/go/+/375354 Trust: Damien Neil <dneil@google.com> Run-TryBot: Damien Neil <dneil@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Trust: Brad Fitzpatrick <bradfitz@golang.org>
2022-01-18net/http: skip TestClientTimeout_Headers_h{1,2} on windows/arm and windows/arm64Bryan C. Mills
This extends the skip added in CL 375635 to the "_Headers" variant of the test, since we have observed similar failures in that variant on the builders. For #43120 Change-Id: Ib1c97fbb776b576271629272f3194da77913a941 Reviewed-on: https://go-review.googlesource.com/c/go/+/379156 Trust: Bryan Mills <bcmills@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Damien Neil <dneil@google.com>
2022-01-05net/http: skip TestClientTimeout_h{1,2} on windows/arm and windows/arm64Bryan C. Mills
These tests are empirically flaky on the windows/arm and windows/arm64 builders, with a consistent (but rare) failure mode. This change skips the test if that particular failure mode is encountered on those platforms; the skip can be removed if and when someone has the time to pin down the root cause. For #43120 Change-Id: Ie3a9a06bf47e3a907c7b07441acc1494a4631135 Reviewed-on: https://go-review.googlesource.com/c/go/+/375635 Trust: Bryan Mills <bcmills@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> Reviewed-by: Damien Neil <dneil@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2021-12-13all: gofmt -w -r 'interface{} -> any' srcRuss Cox
And then revert the bootstrap cmd directories and certain testdata. And adjust tests as needed. Not reverting the changes in std that are bootstrapped, because some of those changes would appear in API docs, and we want to use any consistently. Instead, rewrite 'any' to 'interface{}' in cmd/dist for those directories when preparing the bootstrap copy. A few files changed as a result of running gofmt -w not because of interface{} -> any but because they hadn't been updated for the new //go:build lines. Fixes #49884. Change-Id: Ie8045cba995f65bd79c694ec77a1b3d1fe01bb09 Reviewed-on: https://go-review.googlesource.com/c/go/+/368254 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
2021-11-12net/http: do not cancel request context on response body readDamien Neil
When sending a Request with a non-context deadline, we create a context with a timeout. This context is canceled when closing the response body, and also if a read from the response body returns an error (including io.EOF). Cancelling the context in Response.Body.Read interferes with the HTTP/2 client cleaning up after a request is completed, and is unnecessary: The user should always close the body, the impact from not canceling the context is minor (the context timer leaks until it fires). Fixes #49366. Change-Id: Ieaed866116916261d9079f71d8fea7a7b303b8fb Reviewed-on: https://go-review.googlesource.com/c/go/+/361919 Trust: Damien Neil <dneil@google.com> Run-TryBot: Damien Neil <dneil@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2021-11-04net/http: reduce TestClientTimeout_h{1,2} latencyBryan C. Mills
The test had been setting an arbitrary 200ms timeout to allow the server's handler to set up before timing out. That is not only potentially flaky on slow machines, but also typically much longer than necessary. Replace the hard-coded timeout with a much shorter initial timeout, and use exponential backoff to lengthen it if needed. This allows the test to be run about 20x faster in the typical case, which may make it easier to reproduce rare failure modes by running with a higher -count flag. For #43120 Change-Id: I1e0d0ec99d5a107fff56e3bcc7174d686ec582d1 Reviewed-on: https://go-review.googlesource.com/c/go/+/361275 Trust: Bryan C. Mills <bcmills@google.com> Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Damien Neil <dneil@google.com>
2021-10-06all: use bytes.Cut, strings.CutRuss Cox
Many uses of Index/IndexByte/IndexRune/Split/SplitN can be written more clearly using the new Cut functions. Do that. Also rewrite to other functions if that's clearer. For #46336. Change-Id: I68d024716ace41a57a8bf74455c62279bde0f448 Reviewed-on: https://go-review.googlesource.com/c/go/+/351711 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2021-09-02net/http: fix hang in probing for a zero-length request bodyDamien Neil
Fix a hang that occurs when making a request and all of the following apply: * The request method is one of GET, HEAD, DELETE, OPTIONS, PROPFIND, or SEARCH. * The Request.Body is non-nil. * The content length is not set, or is set to -1. * Transfer-Encoding: chunked is not set. * The request body does not respond to a read within 200ms. In this case, we give up on probing for a zero-length body and send the request while the probe completes in the background. Fix a bug in the io.Reader wrapping the in-flight probe: It should return io.EOF after the probe completes, but does not. Fixes #47568. Change-Id: I7f9188c96e1210055df68424081af927006e4816 Reviewed-on: https://go-review.googlesource.com/c/go/+/340256 Trust: Damien Neil <dneil@google.com> Run-TryBot: Damien Neil <dneil@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ingo Oeser <nightlyone@googlemail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2021-04-10all: fix spellingsNaman Gera
This follows the spelling choices that the Go project has made for English words. https://github.com/golang/go/wiki/Spelling Change-Id: Ie7c586d2cf23020cb492cfff58c0831d2d8d3a78 GitHub-Last-Rev: e16a32cd225a275f73d236bcb33703986d110ded GitHub-Pull-Request: golang/go#45442 Reviewed-on: https://go-review.googlesource.com/c/go/+/308291 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Trust: Emmanuel Odeke <emmanuel@orijtech.com>
2021-03-31net/http: use consistent case in URL in names徐志伟
Change-Id: Iff5074713e1a4484c04b8628fb2611b6d4e154c7 GitHub-Last-Rev: bb0861bbbe31bc2bbda667c05402b5ef886a762b GitHub-Pull-Request: golang/go#45294 Reviewed-on: https://go-review.googlesource.com/c/go/+/305772 Reviewed-by: Ben Shi <powerman1st@163.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ben Shi <powerman1st@163.com> TryBot-Result: Go Bot <gobot@golang.org>
2020-10-20all: update references to symbols moved from io/ioutil to ioRuss Cox
The old ioutil references are still valid, but update our code to reflect best practices and get used to the new locations. Code compiled with the bootstrap toolchain (cmd/asm, cmd/dist, cmd/compile, debug/elf) must remain Go 1.4-compatible and is excluded. Also excluded vendored code. For #41190. Change-Id: I6d86f2bf7bc37a9d904b6cee3fe0c7af6d94d5b1 Reviewed-on: https://go-review.googlesource.com/c/go/+/263142 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
2020-10-16net/http: ensure Request.Body.Close is called once and only onceRoss Light
Makes *Request.write always close the body, so that callers no longer have to close the body on returned errors, which was the trigger for double-close behavior. Fixes #40382 Change-Id: I128f7ec70415f240d82154cfca134b3f692191e3 Reviewed-on: https://go-review.googlesource.com/c/go/+/257819 Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Trust: Damien Neil <dneil@google.com> Trust: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Damien Neil <dneil@google.com> TryBot-Result: Go Bot <gobot@golang.org>
2020-03-31net/http: treat a nil Body from a custom RoundTripper as an empty oneBryan C. Mills
Fixes #38095 Change-Id: I4f65ce01e7aed22240eee979c41535d0b8b9a8dc Reviewed-on: https://go-review.googlesource.com/c/go/+/225717 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
2019-10-14net/http: fix and lock-in Client.Do docs on request cancelationEmmanuel T Odeke
Fixes the docs to correctly match the implementation and also adds a test locking-in the behavior to prevent any accidental future regressions on the docs. Fixes #33545 Change-Id: I6fdac6048cce8ac99beaa2db0dfc81d0dccc10f1 Reviewed-on: https://go-review.googlesource.com/c/go/+/200798 Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2019-09-25net/http: propagate Client.Timeout down into Request's context deadlineBrad Fitzpatrick
Fixes #31657 Change-Id: I85e9595d3ea30d410f1f4b787925a6879a72bdf2 Reviewed-on: https://go-review.googlesource.com/c/go/+/175857 Reviewed-by: Benny Siegert <bsiegert@gmail.com> Run-TryBot: Benny Siegert <bsiegert@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-08-28net/url: improve url parsing error messages by quotingStefan Baebler
Current implementation doesn't always make it obvious what the exact problem with the URL is, so this makes it clearer by consistently quoting the invalid URL, as is the norm in other parsing implementations, eg.: strconv.Atoi(" 123") returns an error: parsing " 123": invalid syntax Updates #29261 Change-Id: Icc6bff8b4a4584677c0f769992823e6e1e0d397d GitHub-Last-Rev: 648b9d93fe149ec90f3aeca73019158a344de03e GitHub-Pull-Request: golang/go#29384 Reviewed-on: https://go-review.googlesource.com/c/go/+/185117 Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-05-28net/http: quiet some log spam in testsBrad Fitzpatrick
One of these tests creates a bunch of connections concurrently, then discovers it doesn't need them all, which then makes the server log that the client went away midway through the TLS handshake. Perhaps the server should recognize that as a case not worthy of logging about, but this is a safer way to eliminate the stderr spam during go test for now. The other test's client gives up on its connection and closes it, similarly confusing the server. Change-Id: I49ce442c9a63fc437e58ca79f044aa76e8c317b5 Reviewed-on: https://go-review.googlesource.com/c/go/+/179179 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
2019-05-03net/http: strip escaped password from errorThanabodee Charoenpiriyakij
Using password that returns from User.Password() won't work in this case because password in Userinfo already unescaped. The solution is uses User.String() to escape password back again and then stringify it to error. Fixes #31808 Change-Id: I723aafd5a57a5b69f2dd7d3a21b82ebbd4174451 Reviewed-on: https://go-review.googlesource.com/c/go/+/175018 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-05-03net/http: add func NewRequestWithContext, Request.CloneBrad Fitzpatrick
Fixes #23544 Change-Id: Iaa31d76c4cda8ce22412d73c9025fc57e4fb1967 Reviewed-on: https://go-review.googlesource.com/c/go/+/174324 Reviewed-by: Andrew Bonventre <andybons@golang.org>
2018-11-12crypto/tls: enable TLS 1.3 and update testsFilippo Valsorda
To disable TLS 1.3, simply remove VersionTLS13 from supportedVersions, as tested by TestEscapeRoute, and amend documentation. To make it opt-in, revert the change to (*Config).supportedVersions from this CL. I did not have the heart to implement the early data skipping feature when I realized that it did not offer a choice between two abstraction-breaking options, but demanded them both (look for handshake type in case of HelloRetryRequest, trial decryption otherwise). It's a lot of complexity for an apparently small gain, but if anyone has strong opinions about it let me know. Note that in TLS 1.3 alerts are encrypted, so the close_notify peeking to return (n > 0, io.EOF) from Read doesn't work. If we are lucky, those servers that unexpectedly close connections after serving a single request will have stopped (maybe thanks to H/2) before they got updated to TLS 1.3. Relatedly, session tickets are now provisioned on the client first Read instead of at Handshake time, because they are, well, post-handshake messages. If this proves to be a problem we might try to peek at them. Doubled the tests that cover logic that's different in TLS 1.3. The benchmarks for TLS 1.2 compared to be0f3c286b5 (before TLS 1.3 and its refactors, after CL 142817 changed them to use real connections) show little movement. name old time/op new time/op delta HandshakeServer/RSA-8 795µs ± 1% 798µs ± 1% ~ (p=0.057 n=10+18) HandshakeServer/ECDHE-P256-RSA-8 903µs ± 0% 909µs ± 1% +0.68% (p=0.000 n=8+17) HandshakeServer/ECDHE-P256-ECDSA-P256-8 198µs ± 0% 204µs ± 1% +3.24% (p=0.000 n=9+18) HandshakeServer/ECDHE-X25519-ECDSA-P256-8 202µs ± 3% 208µs ± 1% +2.98% (p=0.000 n=9+20) HandshakeServer/ECDHE-P521-ECDSA-P521-8 15.5ms ± 1% 15.9ms ± 2% +2.49% (p=0.000 n=10+20) Throughput/MaxPacket/1MB-8 5.81ms ±23% 6.14ms ±44% ~ (p=0.605 n=8+18) Throughput/MaxPacket/2MB-8 8.91ms ±22% 8.74ms ±33% ~ (p=0.498 n=9+19) Throughput/MaxPacket/4MB-8 12.8ms ± 3% 14.0ms ±10% +9.74% (p=0.000 n=10+17) Throughput/MaxPacket/8MB-8 25.1ms ± 7% 24.6ms ±16% ~ (p=0.129 n=9+19) Throughput/MaxPacket/16MB-8 46.3ms ± 4% 45.9ms ±12% ~ (p=0.340 n=9+20) Throughput/MaxPacket/32MB-8 88.5ms ± 4% 86.0ms ± 4% -2.82% (p=0.004 n=10+20) Throughput/MaxPacket/64MB-8 173ms ± 2% 167ms ± 7% -3.42% (p=0.001 n=10+19) Throughput/DynamicPacket/1MB-8 5.88ms ± 4% 6.59ms ±64% ~ (p=0.232 n=9+18) Throughput/DynamicPacket/2MB-8 9.08ms ±12% 8.73ms ±21% ~ (p=0.408 n=10+18) Throughput/DynamicPacket/4MB-8 14.2ms ± 5% 14.0ms ±11% ~ (p=0.188 n=9+19) Throughput/DynamicPacket/8MB-8 25.1ms ± 6% 24.0ms ± 7% -4.39% (p=0.000 n=10+18) Throughput/DynamicPacket/16MB-8 45.6ms ± 3% 43.3ms ± 1% -5.22% (p=0.000 n=10+8) Throughput/DynamicPacket/32MB-8 88.4ms ± 3% 84.8ms ± 2% -4.06% (p=0.000 n=10+10) Throughput/DynamicPacket/64MB-8 175ms ± 3% 167ms ± 2% -4.63% (p=0.000 n=10+10) Latency/MaxPacket/200kbps-8 694ms ± 0% 694ms ± 0% -0.02% (p=0.000 n=9+9) Latency/MaxPacket/500kbps-8 279ms ± 0% 279ms ± 0% -0.09% (p=0.000 n=10+10) Latency/MaxPacket/1000kbps-8 140ms ± 0% 140ms ± 0% -0.15% (p=0.000 n=10+9) Latency/MaxPacket/2000kbps-8 71.1ms ± 0% 71.0ms ± 0% -0.09% (p=0.001 n=8+9) Latency/MaxPacket/5000kbps-8 30.5ms ± 6% 30.1ms ± 6% ~ (p=0.905 n=10+9) Latency/DynamicPacket/200kbps-8 134ms ± 0% 134ms ± 0% ~ (p=0.796 n=9+9) Latency/DynamicPacket/500kbps-8 54.8ms ± 0% 54.7ms ± 0% -0.18% (p=0.000 n=8+10) Latency/DynamicPacket/1000kbps-8 28.5ms ± 0% 29.1ms ± 8% ~ (p=0.173 n=8+10) Latency/DynamicPacket/2000kbps-8 15.3ms ± 6% 15.9ms ±10% ~ (p=0.905 n=9+10) Latency/DynamicPacket/5000kbps-8 9.14ms ±21% 9.65ms ±82% ~ (p=0.529 n=10+10) name old speed new speed delta Throughput/MaxPacket/1MB-8 175MB/s ±13% 167MB/s ±64% ~ (p=0.646 n=7+20) Throughput/MaxPacket/2MB-8 241MB/s ±25% 241MB/s ±40% ~ (p=0.660 n=9+20) Throughput/MaxPacket/4MB-8 328MB/s ± 3% 300MB/s ± 9% -8.70% (p=0.000 n=10+17) Throughput/MaxPacket/8MB-8 335MB/s ± 7% 340MB/s ±17% ~ (p=0.212 n=9+20) Throughput/MaxPacket/16MB-8 363MB/s ± 4% 367MB/s ±11% ~ (p=0.340 n=9+20) Throughput/MaxPacket/32MB-8 379MB/s ± 4% 390MB/s ± 4% +2.93% (p=0.004 n=10+20) Throughput/MaxPacket/64MB-8 388MB/s ± 2% 401MB/s ± 7% +3.25% (p=0.004 n=10+20) Throughput/DynamicPacket/1MB-8 178MB/s ± 4% 157MB/s ±73% ~ (p=0.127 n=9+20) Throughput/DynamicPacket/2MB-8 232MB/s ±11% 243MB/s ±18% ~ (p=0.415 n=10+18) Throughput/DynamicPacket/4MB-8 296MB/s ± 5% 299MB/s ±15% ~ (p=0.295 n=9+20) Throughput/DynamicPacket/8MB-8 334MB/s ± 6% 350MB/s ± 7% +4.58% (p=0.000 n=10+18) Throughput/DynamicPacket/16MB-8 368MB/s ± 3% 388MB/s ± 1% +5.48% (p=0.000 n=10+8) Throughput/DynamicPacket/32MB-8 380MB/s ± 3% 396MB/s ± 2% +4.20% (p=0.000 n=10+10) Throughput/DynamicPacket/64MB-8 384MB/s ± 3% 403MB/s ± 2% +4.83% (p=0.000 n=10+10) Comparing TLS 1.2 and TLS 1.3 at tip shows a slight (~5-10%) slowdown of handshakes, which might be worth looking at next cycle, but the latency improvements are expected to overshadow that. name old time/op new time/op delta HandshakeServer/ECDHE-P256-RSA-8 909µs ± 1% 963µs ± 0% +5.87% (p=0.000 n=17+18) HandshakeServer/ECDHE-P256-ECDSA-P256-8 204µs ± 1% 225µs ± 2% +10.20% (p=0.000 n=18+20) HandshakeServer/ECDHE-X25519-ECDSA-P256-8 208µs ± 1% 230µs ± 2% +10.35% (p=0.000 n=20+18) HandshakeServer/ECDHE-P521-ECDSA-P521-8 15.9ms ± 2% 15.9ms ± 1% ~ (p=0.444 n=20+19) Throughput/MaxPacket/1MB-8 6.14ms ±44% 7.07ms ±46% ~ (p=0.057 n=18+19) Throughput/MaxPacket/2MB-8 8.74ms ±33% 8.61ms ± 9% ~ (p=0.552 n=19+17) Throughput/MaxPacket/4MB-8 14.0ms ±10% 14.1ms ±12% ~ (p=0.707 n=17+20) Throughput/MaxPacket/8MB-8 24.6ms ±16% 25.6ms ±14% ~ (p=0.107 n=19+20) Throughput/MaxPacket/16MB-8 45.9ms ±12% 44.7ms ± 6% ~ (p=0.607 n=20+19) Throughput/MaxPacket/32MB-8 86.0ms ± 4% 87.9ms ± 8% ~ (p=0.113 n=20+19) Throughput/MaxPacket/64MB-8 167ms ± 7% 169ms ± 2% +1.26% (p=0.011 n=19+19) Throughput/DynamicPacket/1MB-8 6.59ms ±64% 6.79ms ±43% ~ (p=0.480 n=18+19) Throughput/DynamicPacket/2MB-8 8.73ms ±21% 9.58ms ±13% +9.71% (p=0.006 n=18+20) Throughput/DynamicPacket/4MB-8 14.0ms ±11% 13.9ms ±10% ~ (p=0.687 n=19+20) Throughput/DynamicPacket/8MB-8 24.0ms ± 7% 24.6ms ± 8% +2.36% (p=0.045 n=18+17) Throughput/DynamicPacket/16MB-8 43.3ms ± 1% 44.3ms ± 2% +2.48% (p=0.001 n=8+9) Throughput/DynamicPacket/32MB-8 84.8ms ± 2% 86.7ms ± 2% +2.27% (p=0.000 n=10+10) Throughput/DynamicPacket/64MB-8 167ms ± 2% 170ms ± 3% +1.89% (p=0.005 n=10+10) Latency/MaxPacket/200kbps-8 694ms ± 0% 699ms ± 0% +0.65% (p=0.000 n=9+10) Latency/MaxPacket/500kbps-8 279ms ± 0% 280ms ± 0% +0.68% (p=0.000 n=10+10) Latency/MaxPacket/1000kbps-8 140ms ± 0% 141ms ± 0% +0.59% (p=0.000 n=9+9) Latency/MaxPacket/2000kbps-8 71.0ms ± 0% 71.3ms ± 0% +0.42% (p=0.000 n=9+9) Latency/MaxPacket/5000kbps-8 30.1ms ± 6% 30.7ms ±10% +1.93% (p=0.019 n=9+9) Latency/DynamicPacket/200kbps-8 134ms ± 0% 138ms ± 0% +3.22% (p=0.000 n=9+10) Latency/DynamicPacket/500kbps-8 54.7ms ± 0% 56.3ms ± 0% +3.03% (p=0.000 n=10+8) Latency/DynamicPacket/1000kbps-8 29.1ms ± 8% 29.1ms ± 0% ~ (p=0.173 n=10+8) Latency/DynamicPacket/2000kbps-8 15.9ms ±10% 16.4ms ±36% ~ (p=0.633 n=10+8) Latency/DynamicPacket/5000kbps-8 9.65ms ±82% 8.32ms ± 8% ~ (p=0.573 n=10+8) name old speed new speed delta Throughput/MaxPacket/1MB-8 167MB/s ±64% 155MB/s ±55% ~ (p=0.224 n=20+19) Throughput/MaxPacket/2MB-8 241MB/s ±40% 244MB/s ± 9% ~ (p=0.407 n=20+17) Throughput/MaxPacket/4MB-8 300MB/s ± 9% 298MB/s ±11% ~ (p=0.707 n=17+20) Throughput/MaxPacket/8MB-8 340MB/s ±17% 330MB/s ±13% ~ (p=0.201 n=20+20) Throughput/MaxPacket/16MB-8 367MB/s ±11% 375MB/s ± 5% ~ (p=0.607 n=20+19) Throughput/MaxPacket/32MB-8 390MB/s ± 4% 382MB/s ± 8% ~ (p=0.113 n=20+19) Throughput/MaxPacket/64MB-8 401MB/s ± 7% 397MB/s ± 2% -0.96% (p=0.030 n=20+19) Throughput/DynamicPacket/1MB-8 157MB/s ±73% 156MB/s ±39% ~ (p=0.738 n=20+20) Throughput/DynamicPacket/2MB-8 243MB/s ±18% 220MB/s ±14% -9.65% (p=0.006 n=18+20) Throughput/DynamicPacket/4MB-8 299MB/s ±15% 303MB/s ± 9% ~ (p=0.512 n=20+20) Throughput/DynamicPacket/8MB-8 350MB/s ± 7% 342MB/s ± 8% -2.27% (p=0.045 n=18+17) Throughput/DynamicPacket/16MB-8 388MB/s ± 1% 378MB/s ± 2% -2.41% (p=0.001 n=8+9) Throughput/DynamicPacket/32MB-8 396MB/s ± 2% 387MB/s ± 2% -2.21% (p=0.000 n=10+10) Throughput/DynamicPacket/64MB-8 403MB/s ± 2% 396MB/s ± 3% -1.84% (p=0.005 n=10+10) Fixes #9671 Change-Id: Ieb57c5140eb2c083b8be0d42b240cd2eeec0dcf6 Reviewed-on: https://go-review.googlesource.com/c/147638 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Adam Langley <agl@golang.org>
2018-08-20net/http: add Client.CloseIdleConnectionsBrad Fitzpatrick
Fixes #26563 Change-Id: I22b0c72d45fab9d3f31fda04da76a8c0b10cd8b6 Reviewed-on: https://go-review.googlesource.com/130115 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Andrew Bonventre <andybons@golang.org>
2018-03-31net/http: strip password from error messageGregory Man
Strip password from URL then stringifying it to error. Fixes #24572 Change-Id: I1751ea9ccf87e7dff50c4c2a2010bf3f865702f8 Reviewed-on: https://go-review.googlesource.com/102855 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2017-10-16net/http: preserve Host header following a relative redirectTom Bergan
If the client sends a request with a custom Host header and receives a relative redirect in response, the second request should use the same Host header as the first request. However, if the response is an abolute redirect, the Host header should not be preserved. See further discussion on the issue tracker. Fixes #22233 Change-Id: I8796e2fbc1c89b3445e651f739d5d0c82e727c14 Reviewed-on: https://go-review.googlesource.com/70792 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com> Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2017-10-02net/http: use canonicalAddr on shouldCopyHeaderOnRedirectGuilherme Rezende
Change-Id: Ic3f7f575d3640706adb7d64545ed8027add6c58f Reviewed-on: https://go-review.googlesource.com/61350 Run-TryBot: Tom Bergan <tombergan@google.com> Reviewed-by: Tom Bergan <tombergan@google.com>
2017-06-05net/http: make Transport retry GetBody requests if nothing writtenDavid Glasser
This is another attempt at the change attempted in https://golang.org/cl/27117 and rolled back in https://golang.org/cl/34134 The difference between this and the previous attempt is that this version only retries if the new field GetBody is set on the Request. Additionally, this allows retries of requests with idempotent methods even if they have bodies, as long as GetBody is defined. This also fixes an existing bug where readLoop could make a redundant call to setReqCanceler for DELETE/POST/PUT/etc requests with no body with zero bytes written. This clarifies the existing TestRetryIdempotentRequestsOnError test (and changes it into a test with 4 subtests). When that test was written, it was in fact testing "retry idempotent requests" logic, but the logic had changed since then, and it was actually testing "retry requests with no body when no bytes have been written". (You can confirm this by changing the existing test from a GET to a DELETE; it passes without the changes in this CL.) We now test for the no-Body and GetBody cases for both idempotent and nothing-written-non-idempotent requests. Fixes #18241 Fixes #17844 Change-Id: I69a48691796f6dc08c31f7aa7887b7dfd67e278a Reviewed-on: https://go-review.googlesource.com/42142 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2017-03-08net/http: use httptest.Server Client in testsJohan Brandhorst
After merging https://go-review.googlesource.com/c/34639/, it was pointed out to me that a lot of tests under net/http could use the new functionality to simplify and unify testing. Using the httptest.Server provided Client removes the need to call CloseIdleConnections() on all Transports created, as it is automatically called on the Transport associated with the client when Server.Close() is called. Change the transport used by the non-TLS httptest.Server to a new *http.Transport rather than using http.DefaultTransport implicitly. The TLS version already used its own *http.Transport. This change is to prevent concurrency problems with using DefaultTransport implicitly across several httptest.Server's. Add tests to ensure the httptest.Server.Client().Transport RoundTripper interface is implemented by a *http.Transport, as is now assumed across large parts of net/http tests. Change-Id: I9f9d15f59d72893deead5678d314388718c91821 Reviewed-on: https://go-review.googlesource.com/37771 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2017-03-02net/http: clean up Transport.RoundTrip error handlingBrad Fitzpatrick
If I put a 10 millisecond sleep at testHookWaitResLoop, before the big select in (*persistConn).roundTrip, two flakes immediately started happening, TestTransportBodyReadError (#19231) and TestTransportPersistConnReadLoopEOF. The problem was that there are many ways for a RoundTrip call to fail (errors reading from Request.Body while writing the response, errors writing the response, errors reading the response due to server closes, errors due to servers sending malformed responses, cancelations, timeouts, etc.), and many of those failures then tear down the TCP connection, causing more failures, since there are always at least three goroutines involved (reading, writing, RoundTripping). Because the errors were communicated over buffered channels to a giant select, the error returned to the caller was a function of which random select case was called, which was why a 10ms delay before the select brought out so many bugs. (several fixed in my previous CLs the past few days). Instead, track the error explicitly in the transportRequest, guarded by a mutex. In addition, this CL now: * differentiates between the two ways writing a request can fail: the io.Copy reading from the Request.Body or the io.Copy writing to the network. A new io.Reader type notes read errors from the Request.Body. The read-from-body vs write-to-network errors are now prioritized differently. * unifies the two mapRoundTripErrorFromXXX methods into one mapRoundTripError method since their logic is now the same. * adds a (*Request).WithT(*testing.T) method in export_test.go, usable by tests, to call t.Logf at points during RoundTrip. This is disabled behind a constant except when debugging. * documents and deflakes TestClientRedirectContext I've tested this CL with high -count values, with/without -race, with/without delays before the select, etc. So far it seems robust. Fixes #19231 (TestTransportBodyReadError flake) Updates #14203 (source of errors unclear; they're now tracked more) Updates #15935 (document Transport errors more; at least understood more now) Change-Id: I3cccc3607f369724b5344763e35ad2b7ea415738 Reviewed-on: https://go-review.googlesource.com/37495 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
2017-03-01net/http: deflake TestClientRedirect308NoGetBodyBrad Fitzpatrick
In an unrelated CL I found a way to increase the likelihood of latent flaky tests and found this one. This is just like yesterday's https://golang.org/cl/37624 and dozens before it (all remnants from the great net/http test parallelization of Nov 2016 in https://golang.org/cl/32684). Change-Id: I3fe61d1645062e5109206ff27d74f573ef6ebb2e Reviewed-on: https://go-review.googlesource.com/37627 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
2017-03-01net/http: fix flaky TestClientRedirect308NoLocationBrad Fitzpatrick
This was a t.Parallel test but it was using the global DefaultTransport via the global Get func. Use a private Transport that won't have its CloseIdleConnections etc methods called by other tests. (I hit this flake myself while testing a different change.) Change-Id: If0665e3e8580ee198f8e5f3079bfaea55f036eca Reviewed-on: https://go-review.googlesource.com/37624 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
2017-01-24net/http: don't send body on redirects for 301, 302, 303 when GetBody is setBrad Fitzpatrick
The presence of Request.GetBody being set on a request was causing all redirected requests to have a body, even if the redirect status didn't warrant one. This bug came from 307/308 support (https://golang.org/cl/29852) which removed the line that set req.Body to nil after POST/PUT redirects. Change-Id: I2a4dd5320f810ae25cfd8ea8ca7c9700e5dbd369 Reviewed-on: https://go-review.googlesource.com/35633 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
2017-01-09net/http: preserve original HTTP method when possibleJoe Tsai
In Go1.7, a 301, 302, or 303 redirect on a HEAD method, would still cause the following redirects to still use a HEAD. In CL/29852 this behavior was changed such that those codes always caused a redirect with the GET method. Fix this such that both GET and HEAD will preserve the method. Fixes #18570 Change-Id: I4bfe69872a30799419e3fad9178f907fe439b449 Reviewed-on: https://go-review.googlesource.com/34981 Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-12-08net/http: don't retry Transport requests if they have a bodyBrad Fitzpatrick
This rolls back https://golang.org/cl/27117 partly, softening it so it only retries POST/PUT/DELETE etc requests where there's no Body (nil or NoBody). This is a little useless, since most idempotent requests have a body (except maybe DELETE), but it's late in the Go 1.8 release cycle and I want to do the proper fix. The proper fix will look like what we did for http2 and only retrying the request if Request.GetBody is defined, and then creating a new request for the next attempt. See https://golang.org/cl/33971 for the http2 fix. Updates #15723 Fixes #18239 Updates #18241 Change-Id: I6ebaa1fd9b19b5ccb23c8d9e7b3b236e71cf57f3 Reviewed-on: https://go-review.googlesource.com/34134 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Tom Bergan <tombergan@google.com>
2016-11-21net/http: deflake TestClientTimeoutBrad Fitzpatrick
Should fix flakes like: https://build.golang.org/log/c8da331317064227f38d5ef57ed7dba563ba1b38 --- FAIL: TestClientTimeout_h1 (0.35s) client_test.go:1263: timeout after 200ms waiting for timeout of 100ms FAIL Change-Id: I0a4dba607524e8d7a00f498e27d9598acde5d222 Reviewed-on: https://go-review.googlesource.com/33420 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2016-11-11net/http: make Server log on bad requests from clientsKenny Grant
Fixes #12745 Change-Id: Iebb7c97cb5b68dc080644d796a6ca1c120d41b26 Reviewed-on: https://go-review.googlesource.com/27950 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-11-11all: fix vet nitsJosh Bleecher Snyder
Fixes these complaints from vet: cmd/compile/internal/gc/noder.go:32: cmd/compile/internal/syntax.Error composite literal uses unkeyed fields cmd/compile/internal/gc/noder.go:1035: cmd/compile/internal/syntax.Error composite literal uses unkeyed fields cmd/compile/internal/gc/noder.go:1051: cmd/compile/internal/syntax.Error composite literal uses unkeyed fields cmd/compile/internal/syntax/parser_test.go:182: possible formatting directive in Error call net/http/client_test.go:1334: possible formatting directive in Fatal call Change-Id: I5f90ec30f3c106c7e66c92e2b6f8d3b4874fec66 Reviewed-on: https://go-review.googlesource.com/33133 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2016-11-10net/http: deflake TestClientTimeoutBrad Fitzpatrick
This test was only enabled by default today so it hasn't been hardened by build.golang.org. Welcome to the ring, TestClientTimeout. Change-Id: I1967f6c825699f13f6c659dc14d3c3c22b965272 Reviewed-on: https://go-review.googlesource.com/33101 Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
2016-11-10net/http: don't wrap request cancellation errors in timeoutsEmmanuel Odeke
Based on Filippo Valsorda's https://golang.org/cl/24230 Fixes #16094 Change-Id: Ie39b0834e220f0a0f4fbfb3bbb271e70837718c3 Reviewed-on: https://go-review.googlesource.com/32478 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-11-08net/http: deflake TestClientRedirectsBrad Fitzpatrick
Fix another case of a parallel test relying on a global variable (DefaultTransport) implicitly. Use the private Transport already in scope instead. It's closed at the end, instead of randomly via another test. Change-Id: I95e51926177ad19a766cabbb306782ded1bbb59b Reviewed-on: https://go-review.googlesource.com/32913 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2016-11-05net/http: deflake TestClientRedirectTypes and maybe some similar onesBrad Fitzpatrick
A few tests were using the global DefaultTransport implicitly. Be explicit instead. And then make some parallel while I'm there. Change-Id: I3c617e75429ecc8f6d23567d1470f5e5d0cb7cfd Reviewed-on: https://go-review.googlesource.com/32758 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-11-04net/http: speed up tests, use t.Parallel when it's safeBrad Fitzpatrick
Before: 8.9 seconds for go test -short After: 2.8 seconds There are still 250 tests without t.Parallel, but I got the important onces using a script: $ go test -short -v 2>&1 | go run ~/slowtests.go Where slowtests.go is https://play.golang.org/p/9mh5Wg1nLN The remaining 250 (the output lines from slowtests.go) all have a reported duration of 0ms, except one 50ms test which has to be serial. Where tests can't be parallel, I left a comment at the top saying why, so people don't add t.Parallel later and get surprised at failures. Updates #17751 Change-Id: Icbe32cbe2b996e23c89f1af6339287fa22af5115 Reviewed-on: https://go-review.googlesource.com/32684 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
2016-11-04net/http: tweak the new Client 307/308 redirect behavior a bitBrad Fitzpatrick
This CL tweaks the new (unreleased) 307/308 support added in https://golang.org/cl/29852 for #10767. Change 1: if a 307/308 response doesn't have a Location header in its response (as observed in the wild in #17773), just do what we used to do in Go 1.7 and earlier, and don't try to follow that redirect. Change 2: don't follow a 307/308 if we sent a body on the first request and the caller's Request.GetBody func is nil so we can't "rewind" the body to send it again. Updates #17773 (will be fixed more elsewhere) Change-Id: I183570f7346917828a4b6f7f1773094122a30406 Reviewed-on: https://go-review.googlesource.com/32595 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2016-10-30net/http: handle 3xx redirects properlyEmmanuel Odeke
Provides redirection support for 307, 308 server statuses. Provides redirection support for DELETE method. Updates old tests that assumed all redirects were treated the way 301, 302 and 303 are processed. Fixes #9348 Fixes #10767 Fixes #13994 Change-Id: Iffa8dbe0ff28a1afa8da59869290ec805b1dd2c4 Reviewed-on: https://go-review.googlesource.com/29852 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2016-10-26net/http: gofmt -w -sMikio Hara
Change-Id: I6815a8560dd9fe0a0ebd485a0693f7044ba09848 Reviewed-on: https://go-review.googlesource.com/32137 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-10-25net/http: fix redirect logic to handle mutations of cookiesJoe Tsai
In the situation where the Client.Jar is set and the Request.Header has cookies manually inserted, the redirect logic needs to be able to apply changes to cookies from "Set-Cookie" headers to both the Jar and the manually inserted Header cookies. Since Header cookies lack information about the original domain and path, the logic in this CL simply removes cookies from the initial Header if any subsequent "Set-Cookie" matches. Thus, in the event of cookie conflicts, the logic preserves the behavior prior to change made in golang.org/cl/28930. Fixes #17494 Updates #4800 Change-Id: I645194d9f97ff4d95bd07ca36de1d6cdf2f32429 Reviewed-on: https://go-review.googlesource.com/31435 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-09-26net/http: add Client tests for various 3xx redirect codesEmmanuel Odeke
Updates #13994 Updates #16840 Change-Id: Ia3cad5c211e0c688a945ed6b6277c2552592774c Reviewed-on: https://go-review.googlesource.com/29760 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2016-09-09net/http: make Client copy headers on redirectBrad Fitzpatrick
Copy all of the original request's headers on redirect, unless they're sensitive. Only send sensitive ones to the same origin, or subdomains thereof. Fixes #4800 Change-Id: Ie9fa75265c9d5e4c1012c028d31fd1fd74465712 Reviewed-on: https://go-review.googlesource.com/28930 Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com> Reviewed-by: Francesc Campoy Flores <campoy@golang.org> Reviewed-by: Ross Light <light@google.com> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-08-23net/http: if context is canceled, return its errorIan Lance Taylor
This permits the error message to distinguish between a context that was canceled and a context that timed out. Updates #16381. Change-Id: I3994b98e32952abcd7ddb5fee08fa1535999be6d Reviewed-on: https://go-review.googlesource.com/24978 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 08:14:07 +0000