Ensure that the implicitly created redirect
for
"/route"
after
"/route/"
has been registered doesn't lose the query string information.
A previous attempt (https://golang.org/cl/43779) changed http.Redirect, however, that change broke direct calls to http.Redirect.
To avoid that problem, this change touches ServeMux.Handler only.
Fixes#17841
Change-Id: I303c1b1824615304ae68147e254bb41b0ea339be
Reviewed-on: https://go-review.googlesource.com/61210
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tom Bergan <tombergan@google.com>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Fixes#20933
Change-Id: I827c8d265674a7448c51c1da991e9b3b4501ba11
Reviewed-on: https://go-review.googlesource.com/59850
Run-TryBot: Tom Bergan <tombergan@google.com>
Reviewed-by: Tom Bergan <tombergan@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
In TimeoutHandler, use a request whose context has been configured with
the handler's timeout
Fixes#20712
Change-Id: Ie670148f85fdad46841ff29232042309e15665ae
Reviewed-on: https://go-review.googlesource.com/46412
Run-TryBot: Tom Bergan <tombergan@google.com>
Reviewed-by: Tom Bergan <tombergan@google.com>
Went mainly for the ones that make no sense, such as the ones
mid-sentence or after commas.
Change-Id: Ie245d2c19cc7428a06295635cf6a9482ade25ff0
Reviewed-on: https://go-review.googlesource.com/57293
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
In the existing implementation, if pattern is an empty string,
program calls a panic with the message which is a concatenation of
"http: invalid pattern " and pattern.
In this case, pattern is an empty, so the commit removes
this concatenation and the trailing space.
Fixes: #21102
Change-Id: I49f58b52d835311a6ac642de871eb15646e48a54
Reviewed-on: https://go-review.googlesource.com/50350
Reviewed-by: Dmitri Shuralyov <shurcool@gmail.com>
Reviewed-by: Tom Bergan <tombergan@google.com>
Run-TryBot: Tom Bergan <tombergan@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Now that issue #12438 is resolved, this TODO can be completed.
Create a logf helper, which is similar to Server.logf method,
but takes a *Request to infer the *Server and its ErrorLog from.
Update documentation of Server.ErrorLog to mention a new type
of errors that may be logged to it.
Also update a statement in documentation of Server.ErrorLog from:
// If nil, logging goes to os.Stderr via the log package's
// standard logger.
To:
// If nil, logging is done via the log package's standard logger.
The motivation for doing so is to avoid making inaccurate claims.
Logging may not go to os.Stderr if anyone overrides the log package's
default output via https://godoc.org/log#SetOutput. Saying that
the standard logger is used should be sufficient to explain the
behavior, and users can infer that os.Stderr is used by default,
unless it's changed.
Updates #12438.
Change-Id: I3a4b0db51d652fd25fb2065fbc2157a3dec4dd38
Reviewed-on: https://go-review.googlesource.com/53950
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Setting the Content-Type header explicitly allows browsers to know what
the type of the content is. Otherwise, they have to guess the type from
the content itself, which could lead to unpredictable behavior, and
increases CPU usage.
Not setting the Content-Type despite writing a body may also trigger
unwanted warnings in user middleware, and make it more difficult to
resolve valid issues where the user forgets to set Content-Type in
some situations where it should be set.
There is some precedent for doing this in http.FileServer, which
sets "Content-Type" to "text/html; charset=utf-8" before writing
<pre><a href=...></a></pre> HTML.
Change-Id: I24286827bebf4da8adee9238b8c5a94d4069c8db
Reviewed-on: https://go-review.googlesource.com/50510
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
We can make it panic with a more explicit and readable error message
during Go 1.10, but document it for now. This has always been the
case; it's not a new rule.
Updates #20933
Change-Id: I53c1fefb47a8f4aae0bb32fa742afa3a2ed20e8a
Reviewed-on: https://go-review.googlesource.com/50634
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
In CL https://golang.org/cl/4893043 (6 years ago), a new package named
"url" was created (it is currently known as "net/url"). During that
change, some identifier name collisions were introduced, and two
parameters in net/http were renamed to "urlStr".
Since that time, Go has continued to put high emphasis on the quality
and readability of the documentation. Sometimes, that means making small
sacrifices in the implementation details of a package to ensure that
the godoc reads better, since that's what the majority of users interact
with. See https://golang.org/s/style#named-result-parameters:
> Clarity of docs is always more important than saving a line or two
> in your function.
I think the "urlStr" parameter name is suboptimal for godoc purposes,
and just "url" would be better.
During the review of https://golang.org/cl/4893043, it was also noted
by @rsc that having to rename parameters named "url" was suboptimal:
> It's unfortunate that naming the package url means
> you can't have a parameter or variable named url.
However, at the time, the name of the url package was still being
decided, and uri was an alternative name under consideration.
The reason urlStr was chosen is because it was a lesser evil
compared to naming the url package uri instead:
> Let's not get hung up on URI vs. URL, but I'd like s/uri/urlStr/ even for just
> that the "i" in "uri" looks very similar to the "l" in "url" in many fonts.
> Please let's go with urlStr instead of uri.
Now that we have the Go 1 compatibility guarantee, the name of the
net/url package is fixed. However, it's possible to improve the
signature of Redirect, NewRequest functions in net/http package
for godoc purposes by creating a package global alias to url.Parse,
and renaming urlStr parameter to url in the exported funcs. This CL
does so.
Updates #21077.
Change-Id: Ibcc10e3825863a663e6ad91b6eb47b1862a299a6
Reviewed-on: https://go-review.googlesource.com/49930
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Updates #18997
Change-Id: Ib1961a4c26b42f99b98b255beb7e2a74b632e0c1
Reviewed-on: https://go-review.googlesource.com/48551
Reviewed-by: Joe Shaw <joe@joeshaw.org>
Reviewed-by: Tom Bergan <tombergan@google.com>
Server.ServeTLS wraps Server.Serve with added TLS support. This is
particularly useful for serving on manually initialized listeners.
Example use-case includes ability to serve with TLS on listener
provided by systemd's socket activation.
A matching test heavily based on TestAutomaticHTTP2_ListenAndServe
is also included.
Original code by Gurpartap Singh as
https://go-review.googlesource.com/c/38114/Fixes#13228
Change-Id: I73bb703f501574a84d261c2d7b9243a89fa52d62
Reviewed-on: https://go-review.googlesource.com/44074
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
CL 43779/commit 6a6c792eef
broke the builds at tip, and that CL doesn't account for
cases where Redirect is directly invoked with a full URL
that itself has a query string.
Updates #17841
Change-Id: Idb0486bae8625e1f9e033ca4cfcd87de95bc835c
Reviewed-on: https://go-review.googlesource.com/44100
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This will be used to allow http2 servers to register a shutdown function
so that net/http.Server.Shutdown will work when the http2 server is
configured via a manual call to http2.ConfigureServer. Currently, Shutdown
only works when the http2 server is configured automatically by the
net/http package.
Updates #20302
Updates #18471
Change-Id: Ifc2b5f3126126a106b49ea4a7e999279852b9cc9
Reviewed-on: https://go-review.googlesource.com/44003
Run-TryBot: Tom Bergan <tombergan@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Ensure that the implicitly created redirect
for
"/route"
after
"/route/"
has been registered doesn't lose the query string information.
Fixes#17841.
Change-Id: Ib7df9242fab8c9368a18fc0da678003d6bec63b8
Reviewed-on: https://go-review.googlesource.com/43779
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It used to be simple, and then it got complicated for speed (to reduce
allocations, mostly), but that involved a mutex and hurt multi-core
performance, contending on the mutex.
A change was sent to try to improve that mutex contention in
https://go-review.googlesource.com/c/42110/2/src/net/http/server.go
but that introduced its own allocations (the string->interface{}
boxing for the sync.Map key), which runs counter to the whole point of
that statusLine function: to remove allocations.
Instead, make the code simple again and not have a mutex. It's a bit
slower for the single-core case, but nobody with a single-user HTTP
server cares about 50 nanoseconds:
name old time/op new time/op delta
ResponseStatusLine 37.5ns ± 2% 87.1ns ± 2% +132.42% (p=0.029 n=4+4)
ResponseStatusLine-2 63.1ns ± 1% 43.1ns ±12% -31.67% (p=0.029 n=4+4)
ResponseStatusLine-4 53.8ns ± 8% 40.2ns ± 2% -25.29% (p=0.029 n=4+4)
name old alloc/op new alloc/op delta
ResponseStatusLine 0.00B ±NaN% 0.00B ±NaN% ~ (all samples are equal)
ResponseStatusLine-2 0.00B ±NaN% 0.00B ±NaN% ~ (all samples are equal)
ResponseStatusLine-4 0.00B ±NaN% 0.00B ±NaN% ~ (all samples are equal)
name old allocs/op new allocs/op delta
ResponseStatusLine 0.00 ±NaN% 0.00 ±NaN% ~ (all samples are equal)
ResponseStatusLine-2 0.00 ±NaN% 0.00 ±NaN% ~ (all samples are equal)
ResponseStatusLine-4 0.00 ±NaN% 0.00 ±NaN% ~ (all samples are equal)
(Note the code could be even simpler with fmt.Fprintf, but that is
relatively slow and involves a bunch of allocations getting arguments
into interface{} for the call)
Change-Id: I1fa119132dbbf97a8e7204ce3e0707d433060da2
Reviewed-on: https://go-review.googlesource.com/42133
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
The LocalAddrContext should have the network address of the actual
interface.
Fixes#18686
Change-Id: I9c401eda312f3a0e7e65b013af827aeeef3b4d3d
Reviewed-on: https://go-review.googlesource.com/35490
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change strips the port in mux.Handler before attempting to
match handlers and adds a test for a request with port.
CONNECT requests continue to use the original path and port.
Fixes#10463
Change-Id: Iff3a2ca2b7f1d884eca05a7262ad6b7dffbcc30f
Reviewed-on: https://go-review.googlesource.com/38194
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The DefaultServeMux included in net/http uses a map to store routes,
but iterates all keys for every request to allow longer paths.
This change checks the map for an exact match first.
To check performance was better, BenchmarkServeMux has been added -
this adds >100 routes and checks the matches.
Exact matches are faster and more predictable on this benchmark
and on most existing package benchmarks.
https://perf.golang.org/search?q=upload:20170312.1
ServeMux-4 2.02ms ± 2% 0.04ms ± 2% −98.08% (p=0.004 n=5+6)
https://perf.golang.org/search?q=upload:20170312.2
ReadRequestChrome-4 184MB/s ± 8% 186MB/s ± 1% ~
ReadRequestCurl-4 45.0MB/s ± 1% 46.2MB/s ± 1% +2.71%
Read...Apachebench-4 45.8MB/s ±13% 48.7MB/s ± 1% ~
ReadRequestSiege-4 63.6MB/s ± 5% 69.2MB/s ± 1% +8.75%
ReadRequestWrk-4 30.9MB/s ± 9% 34.4MB/s ± 2% +11.25%
Change-Id: I8afafcb956f07197419d545a9f1c03ecaa307384
Reviewed-on: https://go-review.googlesource.com/38057
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
As of https://golang.org/cl/21530, rules are updated to state
that Handlers shouldn't modify the provided Request. This change
updates StripPrefix to follow that rule.
Resolves#18952.
Change-Id: I29bbb580722e871131fa75a97e6e038ec64fdfcd
Reviewed-on: https://go-review.googlesource.com/36483
Reviewed-by: Matt Layher <mdlayher@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Matt Layher <mdlayher@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Previously, if the Hijack called stopped the background read call
which read a byte, that byte was sitting in memory, buffered, ready to
be Read by Hijack's returned bufio.Reader, but it wasn't yet in the
bufio.Reader's buffer itself, so bufio.Reader.Buffered() reported 1
byte fewer.
This matters for callers who wanted to stitch together any buffered
data (with bufio.Reader.Peek(bufio.Reader.Buffered())) with Hijack's
returned net.Conn. Otherwise there was no way for callers to know a
byte was read.
Change-Id: Id7cb0a0a33fe2f33d79250e13dbaa9c0f7abba13
Reviewed-on: https://go-review.googlesource.com/35232
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Fixes#18447
Change-Id: I5d60c3632a5ce625d3bac9d85533ce689e301707
Reviewed-on: https://go-review.googlesource.com/34813
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
As discussed in #18095 the server should not log for bad user input.
Change-Id: I628a796926eff3a971e5b04abec17ea377c3f9b7
Reviewed-on: https://go-review.googlesource.com/33617
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
If the Server's Shutdown (or SetKeepAlivesEnabled) method was called
while a connection was in a Handler, but after the headers had been
written, the connection was not later closed.
Fixes#9478
Updates #17754 (reverts that workaround)
Change-Id: I65324ab8217373fbb38e12e2b8bffd0a91806072
Reviewed-on: https://go-review.googlesource.com/33141
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Updates http2 to x/net/http2 git rev 0e2717d for:
http2: conditionally log stacks from panics in Server Handlers like net/http
https://golang.org/cl/33102Fixes#17790
Change-Id: Idd3f0c65540398d41b412a33f1d80de3f7f31409
Reviewed-on: https://go-review.googlesource.com/33103
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Add an explicit way for Handlers to abort their response to the client
and also not spam their error log with stack traces.
panic(nil) also worked in the past (for http1 at least), so continue
to make that work (and test it). But ErrAbortHandler is more explicit.
Updates #17790 (needs http2 updates also)
Change-Id: Ib1456905b27e2ae8cf04c0983dc73e314a4a751e
Reviewed-on: https://go-review.googlesource.com/33099
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Server.TLSNextProto being nil is necessary but not sufficient but
http2 being automatically enabled.
Fixes#16588
Change-Id: I5b18690582f9b12ef05b58235e1eaa52483be285
Reviewed-on: https://go-review.googlesource.com/33090
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Go's http1 implementation originally had a mechanism to send HTTP
trailers based on pre-declaring the trailer keys whose values you'd
later let after the header was written.
http2 copied the same mechanism, but it was found to be unsufficient
for gRPC's wire protocol. A second trailer mechanism was added later
(but only to http2) for handlers that want to send a trailer without
knowing in advance they'd need to.
Copy the same mechanism back to http1 and document it.
Fixes#15754
Change-Id: I8c40d55e28b0e5b7087d3d1a904a392c56ee1f9b
Reviewed-on: https://go-review.googlesource.com/32479
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Also updates x/net/http2 to git rev 541150 for:
http2: add support for graceful shutdown of Server
https://golang.org/cl/32412
http2: make http2.Server access http1's Server via an interface check
https://golang.org/cl/32417Fixes#4674Fixes#9478
Change-Id: I8021a18dee0ef2fe3946ac1776d2b10d3d429052
Reviewed-on: https://go-review.googlesource.com/32329
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This is an alternate solution to https://golang.org/cl/31445
Instead of making NewRequest return a request with Request.Body == nil
to signal a zero byte body, add a well-known variable that means
explicitly zero.
Too many tests inside Google (and presumably the outside world)
broke.
Change-Id: I78f6ecca8e8aa1e12179c234ccfb6bcf0ee29ba8
Reviewed-on: https://go-review.googlesource.com/31726
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
This CL changes how the http1 Server reads from the client.
The goal of this change is to make the Request.Context given to Server
Handlers become done when the TCP connection dies (has seen any read
or write error). I didn't finish that for Go 1.7 when Context was
added to http package.
We can't notice the peer disconnect unless we're blocked in a Read
call, though, and previously we were only doing read calls as needed,
when reading the body or the next request. One exception to that was
the old pre-context CloseNotifier mechanism.
The implementation of CloseNotifier has always been tricky. The past
few releases have contained the complexity and moved the
reading-from-TCP-conn logic into the "connReader" type. This CL
extends connReader to make sure that it's always blocked in a Read
call, at least once the request body has been fully consumed.
In the process, this deletes all the old CloseNotify code and unifies
it with the context cancelation code. The two notification mechanisms
are nearly identical, except the CloseNotify path always notifies on
the arrival of pipelined HTTP/1 requests. We might want to change that
in a subsequent commit. I left a TODO for that. For now there's no
change in behavior except that the context now cancels as it was
supposed to.
As a bonus that fell out for free, a Handler can now use CloseNotifier
and Hijack together in the same request now.
Fixes#15224 (make http1 Server always in a Read, like http2)
Fixes#15927 (cancel context when underlying connection closes)
Updates #9763 (CloseNotifier + Hijack)
Change-Id: I972cf6ecbab7f1230efe8cc971e89f8e6e56196b
Reviewed-on: https://go-review.googlesource.com/31173
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Make a zero-byte write to a hijacked connection not log anything, so handlers
can test whether a connection is hacked by doing a Write(nil).
Fixes#16456
Change-Id: Id56caf822c8592067bd8422672f0c1aec89e866c
Reviewed-on: https://go-review.googlesource.com/30812
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
