aboutsummaryrefslogtreecommitdiff
path: root/src/net/http/transport_test.go
AgeCommit message (Collapse)Author
2026-02-02net/http: try to drain response body upon closing for better connection re-useNicholas S. Husin
Currently, we have a rather inconsistent behavior in terms of whether a connection can be re-used or not when an HTTP body is not read to completion: - In HTTP/2, not reading bodies to completion is not an issue, since a new HTTP/2 stream can be created on the same TCP connection. - In HTTP/1 server, we discard up to 256 KiB of unconsumed request body, to potentially allow re-use. - In HTTP/1 client, we do not do anything, and fail to re-use a TCP connection if there are any unconsumed response body at all. This has led to some confusion. For example, some users have mistakenly discarded response body for HTTP/2 when doing so is not needed. Manually discarding response body can also be disadvantageous if the body is excessively large or is a never-ending stream. To solve this issue, this CL makes it so that closing a response body will cause any remaining content to be drained, up to a limit of 256 KiB or 50 milliseconds, whichever one is reached first. This allows better connection re-use for HTTP/1, and most users can now avoid having to manually drain their response body. For #77370 Change-Id: I71e1227fc9cf5f901362c8e234320817f6b0be24 Reviewed-on: https://go-review.googlesource.com/c/go/+/737720 Reviewed-by: Nicholas Husin <husin@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Damien Neil <dneil@google.com>
2025-10-17all: remove unnecessary loop variable copies in testsTobias Klauser
Copying the loop variable is no longer necessary since Go 1.22. Change-Id: Iebb21dac44a20ec200567f1d786f105a4ee4999d Reviewed-on: https://go-review.googlesource.com/c/go/+/711640 Reviewed-by: Florian Lehner <lehner.florian86@gmail.com> Auto-Submit: Damien Neil <dneil@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Damien Neil <dneil@google.com> Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-09-18net/http: avoid connCount underflow raceDamien Neil
Remove a race condition in counting the number of connections per host, which can cause a connCount underflow and a panic. The race occurs when: - A RoundTrip call attempts to use a HTTP/2 roundtripper (pconn.alt != nil) and receives an isNoCachedConn error. The call removes the pconn from the idle conn pool and decrements the connCount for its host. - A second RoundTrip call on the same pconn succeeds, and delivers the pconn to a third RoundTrip waiting for a conn. - The third RoundTrip receives the pconn at the same moment its request context is canceled. It places the pconn back into the idle conn pool. At this time, the connCount is incorrect, because the conn returned to the idle pool is not matched by an increment in the connCount. Fix this by not adding HTTP/2 pconns back to the idle pool in wantConn.cancel. Fixes #61474 Change-Id: I104d6cf85a54d0382eebf3fcf5dda99c69a7c3f6 Reviewed-on: https://go-review.googlesource.com/c/go/+/703936 Auto-Submit: Damien Neil <dneil@google.com> Reviewed-by: Nicholas Husin <husin@google.com> Reviewed-by: Nicholas Husin <nsh@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-08-27net/http: Ensure that CONNECT proxied requests respect MaxResponseHeaderBytesNicholas Husin
Currently, CONNECT proxied requests use an unlimited Reader. As a result, a malicious or misbehaving proxy server can send an unlimited number of bytes to a client; causing the client to indefinitely receive bytes until it runs out of memory. To prevent this, we now use a LimitedReader that limits the number of bytes according to MaxResponseHeaderBytes in Transport. If MaxResponseHeaderBytes is not provided, we use the default value of 10 MB that has historically been used (see #26315). Fixes #74633 Change-Id: I0b03bb354139dbc64318874402f7f29cc0fb42ce Reviewed-on: https://go-review.googlesource.com/c/go/+/698915 Reviewed-by: Damien Neil <dneil@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-05-21net/http: use synctest.Test rather than RunDamien Neil
Use the non-experimental Test function. As a bonus, this lets us drop the hacks we were doing to support t.Cleanup inside bubbles. Change-Id: I070624e1384494e9d5fcfee594cfbb7680c1beda Reviewed-on: https://go-review.googlesource.com/c/go/+/675315 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Damien Neil <dneil@google.com> Reviewed-by: Jonathan Amsterdam <jba@google.com>
2025-03-18net/http: add onClose hook to fake net listenerDamien Neil
Avoids a race condition: If we set an onClose hook on a conn created by a listener, then setting the hook can race with the connection closing. Change-Id: Ibadead3abbe4335d41f1e2cf84f4696fe98166b3 Reviewed-on: https://go-review.googlesource.com/c/go/+/658655 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Jonathan Amsterdam <jba@google.com> Auto-Submit: Damien Neil <dneil@google.com>
2025-02-14net/http: use runtime.AddCleanup instead of runtime.SetFinalizerCarlos Amedee
Replace the usage of runtime.SetFinalizer with runtime.AddCleanup in tests. Updates #70907 Change-Id: Idd3f1c07f6a7709352ca09948fbcb4a0ad9418bb Reviewed-on: https://go-review.googlesource.com/c/go/+/648655 Auto-Submit: Carlos Amedee <carlos@golang.org> Reviewed-by: Damien Neil <dneil@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-12-19net/http: fix nil panic in testRuss Cox
Observed on a builder in an unrelated CL. https://logs.chromium.org/logs/golang/buildbucket/cr-buildbucket/8728107031663629713/+/u/step/11/log/2 goroutine 27937 gp=0xc00000f6c0 m=20 mp=0xc000085008 [running]: panic({0x560ac0?, 0xa1f400?}) C:/b/s/w/ir/x/w/goroot/src/runtime/panic.go:806 +0x168 fp=0xc00043fac8 sp=0xc00043fa18 pc=0xa5f88 testing.tRunner.func1.2({0x560ac0, 0xa1f400}) C:/b/s/w/ir/x/w/goroot/src/testing/testing.go:1734 +0x219 fp=0xc00043fb78 sp=0xc00043fac8 pc=0x1537f9 testing.tRunner.func1() C:/b/s/w/ir/x/w/goroot/src/testing/testing.go:1737 +0x359 fp=0xc00043fce0 sp=0xc00043fb78 pc=0x153259 panic({0x560ac0?, 0xa1f400?}) C:/b/s/w/ir/x/w/goroot/src/runtime/panic.go:787 +0x132 fp=0xc00043fd90 sp=0xc00043fce0 pc=0xa5f52 runtime.panicmem(...) C:/b/s/w/ir/x/w/goroot/src/runtime/panic.go:262 runtime.sigpanic() C:/b/s/w/ir/x/w/goroot/src/runtime/signal_windows.go:401 +0x198 fp=0xc00043fdd8 sp=0xc00043fd90 pc=0x87938 net/http_test.testTransportIdleConnTimeout.func3(...) C:/b/s/w/ir/x/w/goroot/src/net/http/transport_test.go:5503 net/http_test.testTransportIdleConnTimeout(0xc000e83340, {0x5ec863, 0x2}) C:/b/s/w/ir/x/w/goroot/src/net/http/transport_test.go:5522 +0x4c1 fp=0xc00043ff20 sp=0xc00043fdd8 pc=0x47a841 net/http_test.run[...].func1() C:/b/s/w/ir/x/w/goroot/src/net/http/clientserver_test.go:93 +0xfe fp=0xc00043ff70 sp=0xc00043ff20 pc=0x49a21e testing.tRunner(0xc000e83340, 0xc0004687b0) C:/b/s/w/ir/x/w/goroot/src/testing/testing.go:1792 +0xcb fp=0xc00043ffc0 sp=0xc00043ff70 pc=0x152e4b testing.(*T).Run.gowrap1() C:/b/s/w/ir/x/w/goroot/src/testing/testing.go:1851 +0x25 fp=0xc00043ffe0 sp=0xc00043ffc0 pc=0x153e65 runtime.goexit({}) C:/b/s/w/ir/x/w/goroot/src/runtime/asm_amd64.s:1700 +0x1 fp=0xc00043ffe8 sp=0xc00043ffe0 pc=0xadfe1 created by testing.(*T).Run in goroutine 27899 C:/b/s/w/ir/x/w/goroot/src/testing/testing.go:1851 +0x3f6 Change-Id: I3f8bd7c7863b5031ff43d4837dfe11d26ac75652 Reviewed-on: https://go-review.googlesource.com/c/go/+/637897 Reviewed-by: Damien Neil <dneil@google.com> Auto-Submit: Russ Cox <rsc@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-11-26net/http: test for racing idle conn closure and new requestsDamien Neil
TestTransportRemovesH2ConnsAfterIdle is experiencing flaky failures due to a bug in idle connection handling. Upon inspection, TestTransportRemovesH2ConnsAfterIdle is slow and (I think) not currently testing the condition that it was added to test. Using the new synctest package, this CL: - Adds a test for the failure causing flakes in this test. - Rewrites the existing test to use synctest to avoid sleeps. - Adds a new test that covers the condition the test was intended to examine. The new TestTransportIdleConnRacesRequest exercises the scenario where a never-used connection is closed by the idle-conn timer at the same time as a new request attempts to use it. In this race, the new request should either successfully use the old connection (superseding the idle timer) or should use a new connection; it should not use the closing connection and fail. TestTransportRemovesConnsAfterIdle verifies that a connection is reused before the idle timer expires, and not reused after. TestTransportRemovesConnsAfterBroken verifies that a connection is not reused after it encounters an error. This exercises the bug fixed in CL 196665, which introduced TestTransportRemovesH2ConnsAfterIdle. For #70515 Change-Id: Id23026d2903fb15ef9a831b2df71177ea177b096 Reviewed-on: https://go-review.googlesource.com/c/go/+/631795 Reviewed-by: Jonathan Amsterdam <jba@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Damien Neil <dneil@google.com>
2024-11-22net/http: re-enable TestTransportServerProtocolsDmitri Shuralyov
The h2_bundle.go update was done in CL 631035, and the test now passes. Fixes #67816. Change-Id: Icd54c2774a9e2781e7dc9342ae70c3034eb9bab9 Reviewed-on: https://go-review.googlesource.com/c/go/+/631037 Auto-Submit: Damien Neil <dneil@google.com> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Damien Neil <dneil@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2024-11-22net/http: skip test which depends on h2_bundle.go updateDamien Neil
For #67816 Change-Id: I9ba3a245d6b18758944ca5e206a15892b2aa6028 Reviewed-on: https://go-review.googlesource.com/c/go/+/630976 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Auto-Submit: Damien Neil <dneil@google.com>
2024-11-21net/http: add support for unencrypted HTTP/2Damien Neil
Add an UnencryptedHTTP2 protocol value. Both Server and Transport implement "HTTP/2 with prior knowledge" as described in RFC 9113, section 3.3. Neither supports the deprecated HTTP/2 upgrade mechanism (RFC 7540, section 3.2 "h2c"). For Server, UnencryptedHTTP2 controls whether the server will accept HTTP/2 connections on unencrypted ports. When enabled, the server checks new connections for the HTTP/2 preface and routes them appropriately. For Transport, enabling UnencryptedHTTP2 and disabling HTTP1 causes http:// requests to be made over unencrypted HTTP/2 connections. For #67816 Change-Id: I2763c4cdec1c2bc6bb8157edb93b94377de8a59b Reviewed-on: https://go-review.googlesource.com/c/go/+/622976 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2024-11-06net/http: handle new HTTP/2 error for 1xx limit exceededDamien Neil
CL 615295 changed the error message produced by the HTTP/2 implementation when a server sends more 1xx headers than expected. Update a test that checks for this error. For #65035 Change-Id: I57e22f6a880412e3a448e58693127540806d5ddb Reviewed-on: https://go-review.googlesource.com/c/go/+/625195 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-11-05net/http: add Protocols field to Server and TransportDamien Neil
Support configuring which HTTP version(s) a server or client use via an explicit set of protocols. The Protocols field takes precedence over TLSNextProto and ForceAttemptHTTP2. Fixes #67814 Change-Id: I09ece88f78ad4d98ca1f213157b5f62ae11e063f Reviewed-on: https://go-review.googlesource.com/c/go/+/607496 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Jonathan Amsterdam <jba@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2024-10-24net/http: limit 1xx based on size, do not limit when deliveredDamien Neil
Replace Transport's limit of 5 1xx responses with a limit based on MaxResponseHeaderBytes: The total number of responses (including 1xx reponses and the final response) must not exceed this value. When the user is reading 1xx responses using a Got1xxResponse client trace hook, disable the limit: Each 1xx response is individually limited by MaxResponseHeaderBytes, but there is no limit on the total number of responses. The user is responsible for imposing a limit if they want one. For #65035 Change-Id: If4bbbbb0b808cb5016701d50963c89f0ce1229f8 Reviewed-on: https://go-review.googlesource.com/c/go/+/615255 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-09-26net/http: use sync.OnceFunc, sync.OnceValueapocelipes
Use sync.OnceFunc and sync.OnceValue to simplify the code. Change-Id: Ie47e0444c2b9d3260f6ef94cdc6ee8ee5bcf9f71 GitHub-Last-Rev: 520afbec2a392d73dfd9697035804be7c7cc8b77 GitHub-Pull-Request: golang/go#69634 Reviewed-on: https://go-review.googlesource.com/c/go/+/616037 Auto-Submit: Ian Lance Taylor <iant@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: David Chase <drchase@google.com>
2024-08-29net/http: add HTTP2ConfigDamien Neil
Add a field to Server and Transport containing HTTP/2 configuration parameters. This field will have no effect until golang.org/x/net/http2 is updated to make use of it, and h2_bundle.go is updated with the new http2 package. For #67813 Change-Id: I81d7f8e9ddea78f9666383983aec43e3884c13ed Reviewed-on: https://go-review.googlesource.com/c/go/+/602175 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Jonathan Amsterdam <jba@google.com>
2024-07-25net: use slices and maps to clean up testsapocelipes
Replace reflect.DeepEqual with slices.Equal/maps.Equal, which is much faster. Change-Id: I54600fb63a56460c11d3d5af9072da585e31b1a2 GitHub-Last-Rev: 08c1445ad5be94d071e8ceb4b060b8f4ab0d77ba GitHub-Pull-Request: golang/go#67606 Reviewed-on: https://go-review.googlesource.com/c/go/+/587816 Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Ian Lance Taylor <iant@google.com>
2024-06-06net/http: send body or close connection on expect-100-continue requestsDamien Neil
When sending a request with an "Expect: 100-continue" header, we must send the request body before sending any further requests on the connection. When receiving a non-1xx response to an "Expect: 100-continue" request, send the request body if the connection isn't being closed after processing the response. In other words, if either the request or response contains a "Connection: close" header, then skip sending the request body (because the connection will not be used for further requests), but otherwise send it. Correct a comment on the server-side Expect: 100-continue handling that implied sending the request body is optional. It isn't. For #67555 Change-Id: Ia2f12091bee697771087f32ac347509ec5922d54 Reviewed-on: https://go-review.googlesource.com/c/go/+/591255 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Jonathan Amsterdam <jba@google.com>
2024-05-23net/http: remove TestTransportDialCancelRaceDamien Neil
This test was added to cover a specific race condition in request cancellation, applying only to the deprecated Transport.CancelRequest cancellation path. The test assumes that canceling a request at the moment persistConn.RoundTrip begins guarantees that it will be canceled before being sent. This does not apply to the newer forms of canceling a request: Request.Cancel and context-based cancellation both send the cancel signal on a channel, and do not check for cancellation before sending a request. A recent refactoring unified the implementation of cancellation, so the Transport.CancelRequest path now translates into context-based cancellation internally. This makes this test flaky, since sometimes the request completes before we read from the context's done channel. Drop the test entirely. It's verifying the fix for a bug in a code path which no longer exists, and the property that it's testing for (canceling a request at a very specific point in the internal request flow) is not interesting. Fixes #67533 Change-Id: I8d71540f1b44a64e0621d31a1c545c9351ae897c Reviewed-on: https://go-review.googlesource.com/c/go/+/587935 Reviewed-by: Austin Clements <austin@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Damien Neil <dneil@google.com>
2024-05-17net/http: return correct error when reading from a canceled request bodyDamien Neil
CL 546676 inadvertently changed the error returned when reading from the body of a canceled request. Fix it. Rework various request cancelation tests to exercise all three ways of canceling a request. Fixes #67439 Change-Id: I14ecaf8bff9452eca4a05df923d57d768127a90c Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-linux-amd64-longtest-race Reviewed-on: https://go-review.googlesource.com/c/go/+/586315 Auto-Submit: Damien Neil <dneil@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Jonathan Amsterdam <jba@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-04-17net/http: don't cancel Dials when requests are canceledDamien Neil
Currently, when a Transport creates a new connection for a request, it uses the request's Context to make the Dial. If a request times out or is canceled before a Dial completes, the Dial is canceled. Change this so that the lifetime of a Dial call is not bound by the request that originated it. This change avoids a scenario where a Transport can start and then cancel many Dial calls in rapid succession: - Request starts a Dial. - A previous request completes, making its connection available. - The new request uses the now-idle connection, and completes. - The request Context is canceled, and the Dial is aborted. Fixes #59017 Change-Id: I996ffabc56d3b1b43129cbfd9b3e9ea7d53d263c Reviewed-on: https://go-review.googlesource.com/c/go/+/576555 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2024-03-26all: fix a large number of commentscui fliter
Partial typo corrections, following https://go.dev/wiki/Spelling Change-Id: I2357906ff2ea04305c6357418e4e9556e20375d1 Reviewed-on: https://go-review.googlesource.com/c/go/+/573776 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> Run-TryBot: shuang cui <imcusg@gmail.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com>
2024-03-21net/http: improve error reporting in TestCancelRequestWhenSharingConnectionDamien Neil
Ensure that errors are reported if an HTTP request unexpectedly fails. For #56587 Change-Id: I1adfb4fedc24d4177caf54e34c5033267e32caa6 Reviewed-on: https://go-review.googlesource.com/c/go/+/486075 Reviewed-by: Bryan Mills <bcmills@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Damien Neil <dneil@google.com> Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
2024-03-20net/http: validate outgoing/client request trailersEmmanuel T Odeke
This change validates outbound client request trailers just like we do for headers. This helps prevent header injection or other sorts of smuggling from easily being performed using the standard HTTP client. Fixes #64766 Change-Id: Idb34df876a0c308b1f57e9ae2695b118ac6bcc2d Reviewed-on: https://go-review.googlesource.com/c/go/+/572615 Reviewed-by: David Chase <drchase@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Damien Neil <dneil@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Damien Neil <dneil@google.com> Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com> Auto-Submit: Emmanuel Odeke <emmanuel@orijtech.com>
2024-03-18net/http: fix request canceler leak on connection closeAlexander Yastrebov
writeLoop goroutine closes persistConn closech in case of request body write error which in turn finishes readLoop without removing request canceler. Fixes #61708 Change-Id: Ib7c832a91b49bc7888a35a4fd2bd692236c04f86 GitHub-Last-Rev: b74b9055e87121d4dc5d97a3f3ef1afe545bc92d GitHub-Pull-Request: golang/go#62305 Reviewed-on: https://go-review.googlesource.com/c/go/+/523296 Reviewed-by: Carlos Amedee <carlos@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Damien Neil <dneil@google.com>
2024-03-11net/http: support socks5h proxy schema胡玮文
Extend the net/http Transport to recognize the 'socks5h' schema as an alias for 'socks5'. Traditionally, the 'socks5h' schema indicates that the hostname should be resolved by the proxy server, which is behavior already implemented in Go for 'socks5'. Fixes #24135 Change-Id: I0a6a92bbd282a3200dc4dc7b47a9b0628f931783 Reviewed-on: https://go-review.googlesource.com/c/go/+/569977 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Damien Neil <dneil@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Damien Neil <dneil@google.com>
2024-02-20net/http: add missing call to decConnsPerHostJulian Tibble
A recent change to Transport.dialConnFor introduced an early return that skipped dialing. This path did not call decConnsPerHost, which can cause subsequent HTTP calls to hang if Transport.MaxConnsPerHost is set. Fixes: #65705 Change-Id: I157591114b02a3a66488d3ead7f1e6dbd374a41c Reviewed-on: https://go-review.googlesource.com/c/go/+/564036 Reviewed-by: Damien Neil <dneil@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Damien Neil <dneil@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
2024-02-13net/http: close connection if OnProxyConnectResponse returns an errorDamien Neil
Fixes #64804 Change-Id: Ibe56ab8d114b8826e477b0718470d0b9fbfef9b0 Reviewed-on: https://go-review.googlesource.com/c/go/+/560856 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Jonathan Amsterdam <jba@google.com>
2023-12-01net/http: avoid leaking io.Copy goroutines (and hijacked connections) in ↵Bryan C. Mills
TestTransportNoReuseAfterEarlyResponse Fixes #64252 (maybe). Change-Id: Iba2a403a9347be4206f14acb11591dc2eb7f9fb8 Reviewed-on: https://go-review.googlesource.com/c/go/+/546616 Reviewed-by: Damien Neil <dneil@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Bryan Mills <bcmills@google.com>
2023-09-13net/http: scale rstAvoidanceDelay to reduce test flakinessBryan C. Mills
As far as I can tell, some flakiness is unavoidable in tests that race a large client request write against a server's response when the server doesn't read the full request. It does not appear to be possible to simultaneously ensure that well-behaved clients see EOF instead of ECONNRESET and also prevent misbehaving clients from consuming arbitrary server resources. (See RFC 7230 §6.6 for more detail.) Since there doesn't appear to be a way to cleanly eliminate this source of flakiness, we can instead work around it: we can allow the test to adjust the hard-coded delay if it sees a plausibly-related failure, so that the test can retry with a longer delay. As a nice side benefit, this also allows the tests to run more quickly in the typical case: since the test will retry in case of spurious failures, we can start with an aggressively short delay, and only back off to a longer one if it is really needed on the specific machine running the test. Fixes #57084. Fixes #51104. For #58398. Change-Id: Ia4050679f0777e5eeba7670307a77d93cfce856f Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest-race,gotip-linux-amd64-race,gotip-windows-amd64-race Reviewed-on: https://go-review.googlesource.com/c/go/+/527196 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Damien Neil <dneil@google.com> Auto-Submit: Bryan Mills <bcmills@google.com>
2023-08-28net/http: document setting of Proxy-Authorization headerDamien Neil
Add a test for setting a proxy username/password in the HTTP_PROXY environment variable as well. Fixes #61505 Change-Id: I31c3fa94c7bc463133321e9af9289fd47da75b46 Reviewed-on: https://go-review.googlesource.com/c/go/+/512555 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Damien Neil <dneil@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-08-23net/http: revert fix request canceler leak on connection closeAlexander Yastrebov
This reverts CL 515796 due to a flaking test. Updates #61708 Fixes #62224 Change-Id: I53911a07677d08c3196daaaa2708269593baf472 GitHub-Last-Rev: 3544648ecc3783dcb10d54fc2b266797c02f9a75 GitHub-Pull-Request: golang/go#62233 Reviewed-on: https://go-review.googlesource.com/c/go/+/522097 Run-TryBot: Bryan Mills <bcmills@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
2023-08-22net/http: fix request canceler leak on connection closeAlexander Yastrebov
Due to a race condition persistConn could be closed without removing request canceler. Note that without the fix test occasionally passes and to demonstrate the issue it has to be run multiple times, e.g. using -count=10. Fixes #61708 Change-Id: I9029d7d65cf602dd29ee1b2a87a77a73e99d9c92 GitHub-Last-Rev: 6b31f9826da71dad4ee8c0491efba995a8f51440 GitHub-Pull-Request: golang/go#61745 Reviewed-on: https://go-review.googlesource.com/c/go/+/515796 Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Damien Neil <dneil@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-08-21net/http: use cancelKey to cancel requestAlexander Yastrebov
Follows up on CL 245357 and adds missing returns in waitCondition (CL 477196) Fixes #51354 Change-Id: I7950ff889ad72c4927a969c35fedc0186e863bd6 GitHub-Last-Rev: 52ce05bc83ef88c7104df9254bc1add0dda83ae0 GitHub-Pull-Request: golang/go#61724 Reviewed-on: https://go-review.googlesource.com/c/go/+/515435 Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Damien Neil <dneil@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Damien Neil <dneil@google.com>
2023-06-29net/http: validate Host header before sendingDamien Neil
Verify that the Host header we send is valid. Avoids surprising behavior such as a Host of "go.dev\r\nX-Evil:oops" adding an X-Evil header to HTTP/1 requests. Add a test, skip the test for HTTP/2. HTTP/2 is not vulnerable to header injection in the way HTTP/1 is, but x/net/http2 doesn't validate the header and will go into a retry loop when the server rejects it. CL 506995 adds the necessary validation to x/net/http2. For #60374 Change-Id: I05cb6866a9bead043101954dfded199258c6dd04 Reviewed-on: https://go-review.googlesource.com/c/go/+/506996 Reviewed-by: Tatiana Bradley <tatianabradley@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Damien Neil <dneil@google.com>
2023-05-24net/http: fix spelling issues in comments and testsOleksandr Redko
Change-Id: I1b90619fd073a0c41188278a50ed149b763f0fa8 Reviewed-on: https://go-review.googlesource.com/c/go/+/496135 Run-TryBot: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> Auto-Submit: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-05-10all: fix a lot of commentscui fliter
Fix comments, including duplicate is, wrong phrases and articles, misspellings, etc. Change-Id: I8bfea53b9b275e649757cc4bee6a8a026ed9c7a4 Reviewed-on: https://go-review.googlesource.com/c/go/+/493035 Reviewed-by: Benny Siegert <bsiegert@gmail.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: shuang cui <imcusg@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com>
2023-04-12net/http: avoid leaking writer goroutines in testsBryan C. Mills
In TestTransportPrefersResponseOverWriteError and TestMaxBytesHandler, the server may respond to an incoming request without ever reading the request body. The client's Do method will return as soon as the server's response headers are read, but the Transport will remain active until it notices that the server has closed the connection, which may be arbitrarily later. When the server has closed the connection, it will call the Close method on the request body (if it has such a method). So we can use that method to find out when the Transport is close enough to done for the test to complete without interfering too much with other tests. For #57612. For #59526. Change-Id: Iddc7a3b7b09429113ad76ccc1c090ebc9e1835a1 Reviewed-on: https://go-review.googlesource.com/c/go/+/483895 Run-TryBot: Bryan Mills <bcmills@google.com> Commit-Queue: Bryan Mills <bcmills@google.com> Auto-Submit: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
2023-04-07net/http: wait forever for write results in testsDamien Neil
After performing a round trip on a connection, the connection is usually returned to the idle connection pool. If the write of the request did not complete successfully, the connection is not returned. It is possible for the response to be read before the write goroutine has finished signalling that its write has completed. To allow for this, the check to see if the write completed successfully waits for 50ms for the write goroutine to report the result of the write. See comments in persistConn.wroteRequest for more details. On a slow builder, it is possible for the write goroutine to take longer than 50ms to report the status of its write, leading to test flakiness when successive requests unexpectedly use different connections. Set the timeout for waiting for the writer to an effectively infinite duration in tests. Fixes #51147 Fixes #56275 Fixes #56419 Fixes #56577 Fixes #57375 Fixes #57417 Fixes #57476 Fixes #57604 Fixes #57605 Change-Id: I5e92ffd66b676f3f976d8832c0910f27456a6991 Reviewed-on: https://go-review.googlesource.com/c/go/+/483116 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Bryan Mills <bcmills@google.com>
2023-04-04net/http: drop client address comparison in ↵Bryan C. Mills
TestTransportRemovesDeadIdleConnections Since the first client connection is explicitly closed before making the second request, we cannot in general assume that the second request uses a different port (it is equally valid to open the new connection on the same port as the old one that was closed). Fixes #59438. Change-Id: I52d5fe493bd8b1b49270d3996d2019d38d375ce9 Reviewed-on: https://go-review.googlesource.com/c/go/+/482175 Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Damien Neil <dneil@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-03-22net/http: simplify Conn lifetimes in TestClientTimeoutKillsConn testsBryan C. Mills
This is intended to fix the failure mode observed in https://build.golang.org/log/f153e06ed547517fb2cddb0fa817fea40a6146f7, but I haven't been able to reproduce that failure mode locally so I'm not sure whether it actually does. Change-Id: Ib14378f1299a76b54013419bdc715a9dbdd94667 Reviewed-on: https://go-review.googlesource.com/c/go/+/478235 Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Damien Neil <dneil@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-03-22net/http: in the IdleConnStrsForTesting_h2 helper, omit conns that cannot be ↵Bryan C. Mills
reused In #59155, we observed that the IdleConnStrsForTesting_h2 helper function sometimes reported extra connections after a "client conn not usable" failure and retry. It turns out that that state corresponds exactly to the http2clientConnIdleState.canTakeNewRequest field, so (with a bit of extra nethttpomithttp2 plumbing) we can use that field in the helper to filter out the unusable connections. Fixes #59155. Change-Id: Ief6283c9c8c5ec47dd9f378beb0ddf720832484e Reviewed-on: https://go-review.googlesource.com/c/go/+/477856 Reviewed-by: Damien Neil <dneil@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Bryan Mills <bcmills@google.com> Auto-Submit: Bryan Mills <bcmills@google.com>
2023-03-17net/http: eliminate more arbitrary timeouts in testsBryan C. Mills
Change-Id: I5b3158ecd0eb20dc433a53a2b03eb4551cbb3f7d Reviewed-on: https://go-review.googlesource.com/c/go/+/477196 Auto-Submit: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Bryan Mills <bcmills@google.com> Reviewed-by: Damien Neil <dneil@google.com>
2023-02-28all: fix typospgxiaolianzi
Change-Id: Ica8d5e5799a4de532764ae86cdb623508d3a8e18 GitHub-Last-Rev: 3e97cca9de3885f2fe0d7deb776e59cc1c73146d GitHub-Pull-Request: golang/go#58689 Reviewed-on: https://go-review.googlesource.com/c/go/+/471021 Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com>
2023-02-17net/http: remove five second timeout from TestTransportClosesBodyOnErrorDamien Neil
Wait forever and let the test time out with a stack trace if the expected response doesn't happen. Fixes #57990 Change-Id: I835def63db113752cdd06e03e258cb10d63a6a25 Reviewed-on: https://go-review.googlesource.com/c/go/+/463222 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Bryan Mills <bcmills@google.com>
2023-01-20net/http: close Request.Body when pconn write loop exits earlyDamien Neil
The pconn write loop closes a request's body after sending the request, but in the case where the write loop exits with an unsent request in writech the body is never closed. Close the request body in this case. Fixes #49621 Change-Id: Id94a92937bbfc0beb1396446f4dee32fd2059c7e Reviewed-on: https://go-review.googlesource.com/c/go/+/461675 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2022-12-16net/http: improve errors in TestCancelRequestWhenSharingConnectionDamien Neil
Provide more information about why this test might be hanging waiting for PutIdleConn to be called (#56587): If the round trip that should result in PutIdleConn being invoked completes, report that to the goroutine waiting for PutIdleConn. For #56587 Change-Id: Ie476ea0ce4a48d2bda6b9b109f89d675a10e7e45 Reviewed-on: https://go-review.googlesource.com/c/go/+/457775 Auto-Submit: Damien Neil <dneil@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Bryan Mills <bcmills@google.com>
2022-11-19net/http: deflake TestIssue4191_InfiniteGetTimeoutDamien Neil
This test exercises the case where a net.Conn error occurs while writing a response body. It injects an error by setting a timeout on the Conn. If this timeout expires before response headers are written, the test fails. The test attempts to recover from this failure by extending the timeout and retrying. Set the timeout after the response headers are removed, and remove the retry loop. Fixes #56274. Change-Id: I293f8bedb7b20a21d14f43ea9bb48fc56b59441c Reviewed-on: https://go-review.googlesource.com/c/go/+/452175 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Damien Neil <dneil@google.com>
2022-11-18crypto/tls: add CertificateVerificationError to tls handshakeGabor Tanz
Fixes #48152 Change-Id: I503f088edeb5574fd5eb5905bff7c3c23b2bc8fc GitHub-Last-Rev: 2b0e982f3f6bca33062b0bbd64ed1804801e2c13 GitHub-Pull-Request: golang/go#56686 Reviewed-on: https://go-review.googlesource.com/c/go/+/449336 Run-TryBot: Roland Shoemaker <roland@golang.org> Auto-Submit: Roland Shoemaker <roland@golang.org> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Julie Qiu <julieqiu@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org>