We decided to glue together the HTTP/1 and HTTP/2 Transports in the
other direction, having the HTTP/1 code (net/http.Transport) start the
flow.
Remove the http2 Transport.Fallback for now, rather than leaving it
half implemented.
For background, see https://golang.org/cl/16090
Updates golang/go#6891
Change-Id: I511bc6d35a1a9a8e20010bd95ff694a894f42aa4
Reviewed-on: https://go-review.googlesource.com/16181
Reviewed-by: Andrew Gerrand <adg@golang.org>
This adds the http2 Transport method needed by
https://golang.org/cl/16090 to glue the HTTP/1 Transport
(net/http.Transport) to the http2.Transport without throwing away
fresh TCP connections after the TLS handshake determines which
NPN/ALPN protocol was selected.
Updates golang/go#6891
Change-Id: Iba004c8b1a149a5ee6c755d9a3fc1b19856a4e47
Reviewed-on: https://go-review.googlesource.com/16180
Reviewed-by: Andrew Gerrand <adg@golang.org>
This changes makes sure we never write to *writeData in the ServeHTTP
goroutine until the serve goroutine is done with it.
Also, it makes sure we don't transition the stream to the closed state
on the final DATA frame concurrently with the write.
To fix both, the writeFrameAsync goroutine no longer replies directly back
to the ServeHTTP goroutine with the write result. It's now passed to
the serve goroutine instead, which looks at the frameWriteMsg to
decide how to advance the state machine, then signals the ServeHTTP
goroutine with the result, and then advances the state machine.
Because advancing the state machine could transition it to closed,
which the ServeHTTP goroutine might also be selecting on, make the
ServeHTTP goroutine prefer its frameWriteMsg response channel for errors
over the stream closure in its select.
Various code simplifications and robustness in the process.
Tests now pass reliably even with high -count values, -race on/off,
etc. I've been unable to make h2load be unhappy now either.
Thanks to Tatsuhiro Tsujikawa (Github user @tatsuhiro-t) for the bug
report and debugging clues.
Fixesgolang/go#12998
Change-Id: I441c4c9ca928eaba89fd4728d213019606edd899
Reviewed-on: https://go-review.googlesource.com/16063
Reviewed-by: Andrew Gerrand <adg@golang.org>
ConfigureServer now returns an error if your config is wrong. It
doesn't attempt to fix it for you. Adjust this test accordingly.
Change-Id: Ie3de878ff58cef454de0ec9ab1a10459ca0ddd2d
Reviewed-on: https://go-review.googlesource.com/16061
Reviewed-by: Adam Langley <agl@golang.org>
This is required to work with the upcoming rewrite of the
httptest.Server's connection tracking in
https://go-review.googlesource.com/#/c/15151/
which (at least as of patchset 7) doesn't forcefully tear
down a StateNew connection during Server.Wait. That might
change.
In any case, this adds support for ConnState, which users would
expect regardless of protocol in a mixed HTTP/1 and HTTP/2
environment.
Change-Id: I124aafec29dda123a018935fa306f465ae99cd97
Reviewed-on: https://go-review.googlesource.com/15913
Reviewed-by: Andrew Gerrand <adg@golang.org>
In general, clean up and simplify the handling of frame writing from
handler goroutines. Always select on streams closing, and don't try
to pass around and re-use channels. It was too confusing. Instead,
reuse channels in a very local manner that's easy to reason about.
Thanks to Github user @pabbott0 (who has signed the Google CLA) for
the initial bug report and test cases.
Fixesbradfitz/http2#45
Change-Id: Ib72a87cb6e33a4bb118ae23d765ba594e9182ade
Reviewed-on: https://go-review.googlesource.com/15820
Reviewed-by: Andrew Gerrand <adg@golang.org>
There was a design problem earlier where the serve goroutine assumed
that the readFrame goroutine could return only connection-level
errors, but the readFrames goroutine (and the underlying Framer)
assumed it could return stream-level errors (type StreamError) and
have them handled as stream errors in the layers above. That's how it
should have been, and what this CL does.
Now readFrames returns both the Frame and error from ReadFrames
together as a pair, and an error isn't necessarily fatal to the
connection.
Fixesgolang/go#12733Fixesbradfitz/http2#53
Change-Id: If4406ceaa019886893d3c61e6bfce25ef74560d3
Reviewed-on: https://go-review.googlesource.com/15735
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
In the first attempt to enforce the SETTINGS_MAX_HEADER_LIST_SIZE
(https://go-review.googlesource.com/15751), the enforcement happened
in the hpack decoder and the hpack decoder returned errors on Write
and Close if the limit was violated. This was incorrect because the
decoder is used over the life of the connection and all subsequent
requests and could therefore get out of sync.
Instead, this moves the counting of the limit up to the http2 package
in the serverConn type, and replaces the hpack counting mechanism with
a simple on/off switch. When SetEmitEnabled is set false, the header
field emit callbacks will be suppressed and the hpack Decoder will do
less work (less CPU and garbage) if possible, but will still return
nil from Write and Close on valid input, and will still stay in sync
it the stream.
The http2 Server then returns a 431 error if emits were disabled while
processing the HEADER or any CONTINUATION frames.
Fixesgolang/go#12843
Change-Id: I3b41aaefc6c6ee6218225f8dc62bba6ae5fe8f2d
Reviewed-on: https://go-review.googlesource.com/15733
Reviewed-by: Andrew Gerrand <adg@golang.org>
Minor performance improvement, since len(staticTable) is then a
constant at compile time.
Change-Id: Ie51ecc985aa3f40d50f0a7d1ab6ac91738f696d5
Reviewed-on: https://go-review.googlesource.com/15731
Reviewed-by: Dmitri Shuralyov <shurcool@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
There are already tests which cover the behavior. This is simply
moving where it happens. I'm not adding new tests to cover the very
bad behavior because once the rest of the bug is fixed, it won't be
possible to observe anyway. But even for smallish inputs, this is
faster.
Part of golang/go#12843
Change-Id: I7d69f2409e2adb4a01d101a915e09cf887b03f21
Reviewed-on: https://go-review.googlesource.com/15601
Reviewed-by: Andrew Gerrand <adg@golang.org>
StripPrefix in the webdav package strips prefixes from requests
(including the Destination headers) but cannot handle the paths
in the xml entities responses which are confusing some clients
(e.g. cadaver).
This patch replaces StripPrefix with Prefix in the Handler to
handle prefixes both in the requests and in the xml entities
responses.
Change-Id: I67062e30337b2ae422c82a2f927454f5a8a00e34
Reviewed-on: https://go-review.googlesource.com/13857
Reviewed-by: Nigel Tao <nigeltao@golang.org>
These expose the main HTML rendering functions of this package
for use with alternate HTTP muxes and on alternate paths.
Fixesgolang/go#12195.
Change-Id: I679583fd26116bc83ff551a5d2a1d73ffa1e01f0
Reviewed-on: https://go-review.googlesource.com/13825
Reviewed-by: Dave Day <djd@golang.org>
Also fixes ping tests. Latest Linux kernels prohibit to access ICMPv6
properties with non-privileged sockets.
Fixesgolang/go#12163.
Change-Id: I439b41556e8d4c2f3a9f725131267469e08c9599
Reviewed-on: https://go-review.googlesource.com/13653
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When making a request to an IPv6 address with a zone identifier, for
exmaple [fe80::1%en0], RFC 6874 says HTTP clients must remove the zone
identifier "%en0" before writing the request for security reason.
This change removes any IPv6 zone identifer attached to URI in the Host
header field in requests.
See golang/go#9544.
Change-Id: Ie5d18a0bc5f2768a95c59ec2b159ac0abdf685e8
Reviewed-on: https://go-review.googlesource.com/13296
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
An event log is typically associated with a long-lived object, like an
RPC connection. Printf calls record events; Errorf calls record
events marked as errors. The HTTP endpoint /debug/events organizes
event logs by family (usually the Go type name) and by
time-since-last-error. The expanded view shows recent events in the
log and the call stack where the event log was created.
Change-Id: I3461e0d63f39ce6495e16300299048e572b3aa19
Reviewed-on: https://go-review.googlesource.com/12025
Reviewed-by: David Symonds <dsymonds@golang.org>
