| Age | Commit message (Collapse) | Author |
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|