Use the socket option constants defined in the golang.org/x/sys/unix
package instead of duplicating them in this package.
Note that for now, sysIP_RECVDSTADDR, sysIP_RECVIF and sysIP_RECVTTL
still need to be defined because they are used in code shared with other
platforms.
Change-Id: I2b3b8621108c9399f1d36bab97c65fd349fa0839
Reviewed-on: https://go-review.googlesource.com/c/net/+/304712
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>
Use the socket option constants defined in the golang.org/x/sys/unix
package instead of duplicating them in this package.
Note that for now, sysIP_RECVDSTADDR, sysIP_RECVIF, sysIP_RECVTTL and
sysIP_PKTINFO still need to be defined because they are used in code
shared with other platforms.
Change-Id: I900ac4460d350d5d8959d34db339831657b7e03f
Reviewed-on: https://go-review.googlesource.com/c/net/+/304711
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>
Use the socket option constants defined in the golang.org/x/sys/unix
package instead of duplicating them in this package.
Note that for now, sysIP_RECVDSTADDR, sysIP_RECVIF and sysIP_RECVTTL
still need to be defined because they are used in code shared with other
platforms.
Change-Id: I6a6b39e94ec123889c08b55bc469ad51107399cb
Reviewed-on: https://go-review.googlesource.com/c/net/+/304710
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>
Use the socket option constants defined in the golang.org/x/sys/unix
package instead of duplicating them in this package.
Note that for now, sysIP_RECVDSTADDR, sysIP_RECVIF and sysIP_RECVTTL
still need to be defined because they are used in code shared with other
platforms.
Change-Id: Ic937ccbc0a554c8dd6e0b9f36b1601ba86f62f5f
Reviewed-on: https://go-review.googlesource.com/c/net/+/304709
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Use the socket option constants defined in the golang.org/x/sys/unix
package instead of duplicating them in this package.
Note that for now, sysIP_PKTINFO and sysIP_RECVTTL are still needed
because they are used in code shared with other platforms.
Change-Id: Iae627111837a3707fc9079d490d11e34ee3365cf
Reviewed-on: https://go-review.googlesource.com/c/net/+/304330
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>
Use the socket option constants defined in the golang.org/x/sys/unix
package instead of duplicating them in this package.
Note that for now, sysIP_RECVDSTADDR, sysIP_RECVIF, sysIP_RECVTTL and
sysIP_PKTINFO still need to be defined because they are used in code
shared with other platforms.
Change-Id: I9bb953dc72dea19e9e9d84dc641346fe95bad070
Reviewed-on: https://go-review.googlesource.com/c/net/+/303909
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
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>
