When using h2c.NewHandler, the *http.Request object for h2c requests has a
.Context() that doesn't inherit from the *http.Server's BaseContext. This
is surprising for users of vanilla net/http, and is surprising to users of
http2.ConfigureServer; HTTP/1 requests inherit from that BaseContext, and
TLS h2 requests inherit from that BaseContext, but cleartext h2c requests
don't.
So, modify h2c.NewHander to respect that base Context, by way of the
hijacked Request's .Context().
Change-Id: Ibc24ae6e2fb153d9561827ad791329487dae8e5a
GitHub-Last-Rev: 821b2070f7
GitHub-Pull-Request: golang/net#88
Reviewed-on: https://go-review.googlesource.com/c/net/+/278972
Reviewed-by: Liam Haworth <liam@haworth.id.au>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Trust: Brad Fitzpatrick <bradfitz@golang.org>
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
If the server sends a GOAWAY at the same time that a client sends
HEADERS+DATA, the server will discard the HEADERS, but error on the DATA
frame. Luckily, the server doesn't turn this into a connection error
because it's already in a GOAWAY state. It just logs the PROTOCOL_ERROR,
but that produces a confusing log message.
This change effectively suppresses the log message by discarding the
DATA frame rather than erroring on it. Also, we now discard any frames for
streams with identifiers higher than the identified last stream. This is
done as per section 6.8 of the HTTP2 spec.
I also updated some stale documentation while I was trying to understand
the logic.
This is CL 188360 with a test
Fixesgolang/go#32112
Co-authored-by: Yunchi Luo <mightyguava@gmail.com>
Co-authored-by: Michael Fraenkel <michael.fraenkel@gmail.com>
Change-Id: I612c2bd82e37551e813af0961b16a98d14e77c38
Reviewed-on: https://go-review.googlesource.com/c/net/+/237957
Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Damien Neil <dneil@google.com>
Don't make the check for EWOULDBLOCK zos-specific. Most platforms define
EAGAIN and EWOULDBLOCK with the same underlying value. Thus, the
additional check will be a no-op on them. On platforms where EAGAIN and
EWOULDBLOCK have different underlying values, we probably want to check
both as well.
As pointed out by Michael Munday in CL 264028.
Change-Id: Id3404fc4440c66a3484975b4c94b4ebb788b80a1
Reviewed-on: https://go-review.googlesource.com/c/net/+/295569
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
These tests are known to be failing on OpenBSD 6.8 and need
investigation. The OpenBSD 6.8 builders are default TryBots
now, so skip them to prevent people working on other packages
from constantly getting a failure.
Issue 42064 remains open to do the work of determining if the
ipv6 package needs to be fixed, or if OpenBSD 6.8 has a problem
and the test can be permanently skipped as unsupported.
For golang/go#11811.
Updates golang/go#42064.
Updates golang/go#35712.
Change-Id: I59883384e4dbce679cb1a4e8e2c3f0fa7983010b
Reviewed-on: https://go-review.googlesource.com/c/net/+/280052
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Once a request body is scheduled to be written, a result of the write is always
expected. If the body writer is cancelled, and the write was never started,
send a successful result.
The test included is a modified version of the TestNoSniffExpectRequestBody_h2 found
in net/http.
Updates golang/go#42498
Change-Id: If3f23993170bdf10e9ae4244ec13ae269bd3877a
Reviewed-on: https://go-review.googlesource.com/c/net/+/269058
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
When executing the clienttester.run(), it would exit when both
the client and server completed successfully or if either side failed.
If one side fails, the other side may not have finished. If an error was
reported, the goroutine was caught executing after the test completed.
The expectation is always that both sides complete successfully. In the
case where one side fails, we still need to wait for the other side to
complete.
Close both client and server connections on error to expedite the
completion.
Fixesgolang/go#41299
Change-Id: If47fbe61de42495bb2b1327bd5b03d6c295670dc
Reviewed-on: https://go-review.googlesource.com/c/net/+/267760
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Assuming "in head noscript" insertion mode, the scripting flag will be disabled.
Thus, even if nested noscript tags exist,
the tokenizer should not go into the raw text mode.
This change makes the following test happy:
<head><noscript><noscript class="foo"><!--foo--></noscript>
Change-Id: I2620e751d8be3d313c3a2e2f992b1e21ce2dc2ee
Reviewed-on: https://go-review.googlesource.com/c/net/+/263878
Trust: Kunpei Sakai <namusyaka@gmail.com>
Trust: Nigel Tao <nigeltao@golang.org>
Reviewed-by: Nigel Tao <nigeltao@golang.org>
The ConfigureTransport function doesn't provide any way to get at the
http2 Transport it creates, making it impossible to configure transport
parameters such as ReadIdleTimeout.
Add a ConfigureTransports function which returns the http2 Transport.
The very similar names are unfortunate, but they'll sort next to each
other in godoc and the pluralized ConfigureTransports hints at its purpose:
it lets you configure both the http and http2 transports.
Fixesgolang/go#40201.
Updates golang/go#41721.
Change-Id: I97aa345f369f49462c41d3f60d35660c06c51287
Reviewed-on: https://go-review.googlesource.com/c/net/+/264017
Trust: Damien Neil <dneil@google.com>
Trust: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
When a new connection is created, and a write error occurs during the
initial exchange, the connection must be closed. There is no guarantee
that the caller will close the connection.
When a connection with an existing write error is used or being used, it
will stay in use until its read loop completes. Requests will continue
to use this connection and fail when writing its header. These
connections should be closed to force the cleanup in its readLoop.
Fixesgolang/go#39337
Change-Id: I45e1293309e40629531f4cbb69387864f4f71bc2
Reviewed-on: https://go-review.googlesource.com/c/net/+/240337
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Brad Fitzpatrick <bradfitz@golang.org>
Trust: Damien Neil <dneil@google.com>
When the body.Write fails during processData, the connection flow
control must be updated to account for the data received. The connection's
WINDOW_UPDATE should reflect the amount of data that was not successfully
written. The stream is about to be closed, so no update is required.
Fixesgolang/go#40423
Change-Id: I546597cedf3715e6617babcb3b62140bf1857a27
Reviewed-on: https://go-review.googlesource.com/c/net/+/245158
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Emmanuel Odeke <emm.odeke@gmail.com>
Go 1.12 and newer are using libSystem for syscalls on darwin.
Go 1.11 is the last release to use direct syscalls. It hasn't been
supported since the release of Go 1.13 in September 2019, so drop
support for direct syscalls on darwin from golang.org/x/net.
Change-Id: Ib53d64e8a6d12ad702951f8efc123ce92c01c4d9
Reviewed-on: https://go-review.googlesource.com/c/net/+/257057
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Continuing the work of CL 234817, we enforce the same for HTTP/2
connections; that Content-Length header values with a sign (such as
"+5") are rejected or ignored. In each place, the handling of such
incorrect headers follows the approach already in place.
Fixesgolang/go#39017
Change-Id: Ie4854962dd0091795cb861d1cb3a78ce753fd3a8
Reviewed-on: https://go-review.googlesource.com/c/net/+/236098
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Update the list to revision revision dbe9da0a8abeab1b6257c57668d1ecb584189951
(2020-05-27T00:50:31Z).
While here: Fix two wrong formating verbs in the code generating the
table.
Change-Id: Iaa59b313a1d38b06695b8f44acc81230a52e3c14
Reviewed-on: https://go-review.googlesource.com/c/net/+/235397
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Otherwise the server can stop the connection before
clientStream.writeRequestBody has a chance to see if there is any more
data beyond the specified content length.
Tested by adding time.Sleep(time.Millisecond) to chunkReader.Read,
which caused the test to reliably fail before this change,
and reliably pass afterward.
Fixesgolang/go#34616
Change-Id: I119bdf01bf916b2ded2c5d293655cba2596c0166
Reviewed-on: https://go-review.googlesource.com/c/net/+/234523
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In x/net/http2, tests TestServer_RejectsLargeFrames and
TestTransportBodyReadError_* are disabled on Windows because
they fail or flake, being dependent on the behaviour of the
OS network implementation when a connection is closed during
a large write.
The tests fail on Plan 9 for the same reason, so they should be
disabled there as well.
Workaround for golang/go#31260Fixesgolang/go#37321
Change-Id: Ifa1766eaa515c419fc4192126aaf796beefead0a
Reviewed-on: https://go-review.googlesource.com/c/net/+/231877
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
