This change introduces an internal package that provides the
manipulation of net package facilities by using runtime reflection.
The package is supposed to be used by ipv4 and ipv6 packages.
Change-Id: I73ec3b7d3762e675ca03ad9ee5e8a68e75ceb997
Reviewed-on: https://go-review.googlesource.com/27732
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The mod_h2 workaround CL (git rev 28d1bd4,
https://golang.org/cl/25362) introduced a regression where the
Transport could write two DATA frames, both with END_STREAM, if the
Request.Body returned (non-0, io.EOF). strings.Reader, bytes.Reader
are the most common Reader types used with HTTP requests and they only
return (0, io.EOF) so we got generally lucky and things seemed to
work, but other Readers do return (non-0, io.EOF), like the HTTP
transport/server Readers. This is why we broke the HTTP proxy code,
when proxying to HTTP/2.
Updates golang/go#16788 (fixes after it's bundled into std)
Change-Id: I42684017039eacfc27ee53e9c11431f713fdaca4
Reviewed-on: https://go-review.googlesource.com/27406
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Chris Broadfoot <cbro@golang.org>
Update the list to revision 533b016049473e520193e70156e4b54dc1f19568
(2016-08-05T11:21:15Z).
Change-Id: Ic79e83245a86a0c27ac855479073be41c970c527
Reviewed-on: https://go-review.googlesource.com/26851
Reviewed-by: Nigel Tao <nigeltao@golang.org>
The http2 spec says:
> When the value of SETTINGS_INITIAL_WINDOW_SIZE changes, a receiver
> MUST adjust the size of all stream flow-control windows that it
> maintains by the difference between the new value and the old value.
We didn't do this before, and it never mattered until
https://golang.org/cl/25362 for golang/go#16519 because we always knew
the peer's initial window size.
Once we started writing request bodies before hearing the peer's
setting (and thus assuming 64KB), it became very important that this
TODO was done. Should've done it earlier.
More details in the bug.
Updates golang/go#16612 (fixes after bundle into std)
Change-Id: I0ac0280bdd5f6e933ad82f8c9df3c4528295bac2
Reviewed-on: https://go-review.googlesource.com/25508
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Chris Broadfoot <cbro@golang.org>
If the Transport got a stream error on the response headers, it was
never unblocking the client. Previously, Response.Body reads would be
aborted with the stream error, but RoundTrip itself would never
unblock.
The Transport now also sends a RST_STREAM to the server when we
encounter a stream error.
Also, add a "Cause" field to StreamError with additional detail. The
old code was just returning the detail, without the stream error
header.
Fixesgolang/go#16572
Change-Id: Ibecedb5779f17bf98c32787b68eb8a9b850833b3
Reviewed-on: https://go-review.googlesource.com/25402
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
The http2 server implementation in Apache (mod_http2, aka mod_h2) had
a bug where it didn't reply to the initial SETTINGS frame until it had
received a request. Apache 2.4.17 was the first Apache version to
include mod_http2 and has the bug.
The bug was fixed 20 days ago
(de4e3031ae)
for Apache 2.5.0 and included in the out-of-tree mod_h2 1.5.12
(https://github.com/icing/mod_h2/releases/tag/v1.5.12) but most Apache
sites are running older versions making them incompatible with Go's
client. (At least Debian Stretch and Ubuntu Xenial, currently.)
Chrome, curl, Firefox et al don't wait for the initial SETTINGS
response & ACK before sending their first request, which is why
mod_http2 didn't notice their bug for some time.
This change makes Go's http2.Transport act like other common HTTP/2
clients and not wait for the peer's SETTINGS frame & ACK before
sending the first request.
As a bonus, this reduces the latency for the first request on
connections by one RTT.
The reason we waited for the initial settings is purely
historical. Andrew and I just wrote it that way when initially
developing the client on video (https://www.youtube.com/watch?v=yG-UaBJXZ80)
because we were working top-down through the protocol and didn't
get back to optimizing the RTT away. It also seemed more compliant to
wait for the peer's SETTINGS to know the frame size and such, but as
as spec says, it's permitted for clients to not wait:
http://httpwg.org/specs/rfc7540.html#rfc.section.3.5
> To avoid unnecessary latency, clients are permitted to send
> additional frames to the server immediately after sending the client
> connection preface, without waiting to receive the server connection
> preface. It is important to note, however, that the server
> connection preface SETTINGS frame might include parameters that
> necessarily alter how a client is expected to communicate with the
> server. Upon receiving the SETTINGS frame, the client is expected to
> honor any parameters established. In some configurations, it is
> possible for the server to transmit SETTINGS before the client sends
> additional frames, providing an opportunity to avoid this issue.
So, don't wait.
Fixesgolang/go#16519
Change-Id: I916827e49829f7f107a51838512816916fb553fc
Reviewed-on: https://go-review.googlesource.com/25362
Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
http://httpwg.org/specs/rfc7540.html#rfc.section.6.1 says:
> The entire DATA frame payload is included in flow control, including
> the Pad Length and Padding fields if present.
But we were just ignoring the padding and pad length, which could lead
to clients and servers getting out of sync and deadlock if peers used
padding. (Go never does, so it didn't affect Go<->Go)
In the process, fix a lingering bug from golang/go#16481 where we
didn't account for flow control returned to peers in the stream's
inflow, despite sending the peer a WINDOW_UPDATE.
Fixesgolang/go#16556
Updates golang/go#16481
Change-Id: If7150fa8f0da92a60f34af9c3f754a0346526ece
Reviewed-on: https://go-review.googlesource.com/25382
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
For both the server and the transport, return connection-level flow control in
two cases: 1) when a stream is closed with buffered data not read by the user,
or 2) when a DATA frame arrives but there the stream has since been closed.
Fixesgolang/go#16481
Change-Id: Ic7404180ed04a2903e8fd6e9599a907f88b4f72e
Reviewed-on: https://go-review.googlesource.com/25231
Reviewed-by: Andrew Gerrand <adg@golang.org>
NewClientConn starts a goroutine (which reads cc.singleUse at start),
so it's not safe to set cc.singleUse after calling NewClientConn.
Change-Id: I5c28db15e8e8fd8ec5ef0e04b7f81e61efbd873e
Reviewed-on: https://go-review.googlesource.com/25230
Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Fixes flakes like:
https://build.golang.org/log/56e0561f9f6a740b75538692a1c3288f08949dd0
I reproduced the flake above with a time.Sleep(50 * time.Millisecond)
before ClientConn.RoundTrip's final for{select{...}} loop (to give
multiple channels time to become readable on the first select), and
then ran (on linux/amd64) with:
go test -v -run=TestTransportReqBodyAfterResponse_403 -count=50 -race
Before, many failed. With this CL it never fails. (crosses fingers)
Fixesgolang/go#16102 (again)
Change-Id: I93fde46846cd09445e53c140e9668382965d95c5
Reviewed-on: https://go-review.googlesource.com/24984
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The test's server was replying with the stream closure before reading
the test client's request body. This should in theory be handled
better (and golang/go#16029 will be kept open to track it), but that's not
what this test was trying to test anyway.
Instead, make the test do things in the expected order so it can
continue to test its original subject reliably. (It was trying to test
all the orders of optional & optionally fragmented headers in responses.)
Updates golang/go#16029 (flaky http2 TestTransportResPattern_*)
Updates golang/go#11811 (subrepos need to be green)
Change-Id: I631730fce5dad598120bb2d1ea8895e39255d711
Reviewed-on: https://go-review.googlesource.com/24970
Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The old support for Request.Close was optimistic, but there were still
windows where two connections should share the same
connection. Instead, support it earlier and more explicitly.
This fixes a flaky test on FreeBSD which was probably only flaky due
to unfortunate scheduling/timing.
Change-Id: I2eed9e59116356257e1b7df7a034b1c5d5f6533a
Reviewed-on: https://go-review.googlesource.com/24810
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Also drop some leading zeroes in in the generated table.go file. Its
size drops from 140K to 124K. After gzipping, this is from 46K to 45K.
It's not a huge win, but it's a win.
Change-Id: Ib1c13fb8b58b4eca231b5d74c15297f245c62e7c
Reviewed-on: https://go-review.googlesource.com/24753
Reviewed-by: Andrew Gerrand <adg@golang.org>
TLS_RSA_WITH_AES_128_GCM_SHA256 and TLS_RSA_WITH_AES_256_GCM_SHA384
are also blacklisted in RFC 7540 Appendix A.
Because they are were implemented in Go 1.6, the isBadCipher
function has been moved into the version-tagged files so that the
repo doesn't break for Go 1.5 users.
Change-Id: If8ca058ede51e9a4a337ce8d645cfd9f370d49b4
Reviewed-on: https://go-review.googlesource.com/24214
Reviewed-by: Adam Langley <agl@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The http2 spec permits multiple GOAWAY frames if the conditions
change. Merge their error messages together, preferring the first
non-empty debug data, and first non-ErrCodeNo error code.
Updates golang/go#14627
Change-Id: I073b9234d71f128ed0713f09a24c728b56d7c1ae
Reviewed-on: https://go-review.googlesource.com/24600
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
Also follow the "go generate" convention, and have the generation
command be a bare "go run gen.go" without any need for explicit flags.
Stripping the for-debugging comments shrinks the generated table.go file
from 538K to 139K.
Also update table to latest list from publicsuffix.org:
revision ea9f4f9c51f5bfc5c85a41a5637ab671c07c542a
(2016-05-31T18:30:56Z)
Change-Id: Ib59366106e0142fd65a2102e73d6a9a29e53930e
Reviewed-on: https://go-review.googlesource.com/23930
Reviewed-by: Andrew Gerrand <adg@golang.org>
The contract for Read specifies that a caller should process n bytes of
data before handling an error value. The previous implementation may
have discarded the final data read from the underlying reader if err
was non nil.
Change-Id: I81547cd9ea62c4060f79523679beed6bbc6ccd95
Reviewed-on: https://go-review.googlesource.com/23534
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The existing transport implementation limit scheme to https, so
simple h2c can not be used, if we loose the limit to http scheme,
it works well with existing h2c server support.
Fixesgolang/go#15830
Change-Id: Icfe65d72b3e6fb41f69019539fb5b86144814378
Reviewed-on: https://go-review.googlesource.com/23181
Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Andrew Gerrand <adg@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Since Go's HTTP/2 Handlers can read & write concurrently, it was
previously possible for a Handler to get an HTTP Request with "Expect:
100-continue" and to first Write some data, then read some data, and
the read of the data was triggering the server's automatic
"100-continue" response path. But if the server had already replied
with a non-100 HEADERS frame, sending a HEADERS frame with :status 100
later is in violation of the spec.
Fix it by tracking whether we've already replied with something, and
ignoring the 100-continue when it's inappropriate.
Updates golang/go#14030
Change-Id: I6745ba0f257a31eaf63816e4263cadbef5a896a2
Reviewed-on: https://go-review.googlesource.com/23311
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
