A sentinel error http.ErrServerClosed is returned after Server.Shutdown
and Server.Close but it is not documented on the Server.Shutdown while
other methods such as Server.Serve are documented on it.
Change-Id: Id82886d9d6a1474a514d62e9169b35f3579a9eee
Reviewed-on: https://go-review.googlesource.com/c/go/+/671695
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Sean Liao <sean@liao.dev>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Sean Liao <sean@liao.dev>
Previously, Hijack allocated a new write buffer and the existing
connection write buffer used an extra 4KiB of memory until the handler
finished and the "conn" was garbage collected. Now, hijack re-uses the
existing write buffer and re-attaches it to the raw connection to avoid
referencing the net/http "conn" after returning.
After a handler that hijacked exited, the "conn" reference in
"connReader" will now be unset. This allows all of the "conn",
"response" and "Request" to get garbage collected.
Overall, this is reducing the memory usage by 43% or 6.7KiB per hijacked
connection (see BenchmarkServerHijackMemoryUsage in an earlier revision
of the CL).
CloseNotify will continue to work _before_ the handler has exited
(i.e. while the "conn" is still referenced in "connReader"). This aligns
with the documentation of CloseNotifier:
> After the Handler has returned, there is no guarantee that the channel
> receives a value.
goos: linux
goarch: amd64
pkg: net/http
cpu: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz
│ before │ after │
│ sec/op │ sec/op vs base │
ServerHijack-8 42.59µ ± 8% 39.47µ ± 16% ~ (p=0.481 n=10)
│ before │ after │
│ B/op │ B/op vs base │
ServerHijack-8 16.12Ki ± 0% 12.06Ki ± 0% -25.16% (p=0.000 n=10)
│ before │ after │
│ allocs/op │ allocs/op vs base │
ServerHijack-8 51.00 ± 0% 49.00 ± 0% -3.92% (p=0.000 n=10)
Change-Id: I20a37ee314ed0d47463a4657d712154e78e48138
GitHub-Last-Rev: 80f09dfa27
GitHub-Pull-Request: golang/go#70756
Reviewed-on: https://go-review.googlesource.com/c/go/+/634855
Reviewed-by: Sean Liao <sean@liao.dev>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Sean Liao <sean@liao.dev>
For #4385
For #72745
Change-Id: Ibd54fc03467eb948001299001bb2e2529512a7c0
Reviewed-on: https://go-review.googlesource.com/c/go/+/656135
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Clone the input slice before adjusting NextProtos
to add or remove "http/1.1" and "h2" entries,
so as not to modify a slice that the caller might be using.
(We clone the tls.Config that contains the slice, but
that's a shallow clone.)
Fixes#72100
Change-Id: I9f228b8fb6f6f2ca5023179ec114929c002dbda9
Reviewed-on: https://go-review.googlesource.com/c/go/+/654875
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The root cause of issue #65802 is a small race condition that occurs between
two events:
1. During the HTTP server shutdown, a connection in an idle state is identified
and closed.
2. The connection, although idle, has just finished reading a complete request
before being closed and hasn't yet updated its state to active.
In this scenario, despite the connection being closed, the request continues to
be processed. This not only wastes server resources but also prevents the
client request from being retried.
Fixes#65802
Change-Id: Ic22abb4497be04f6c84dff059df00f2c319d8652
GitHub-Last-Rev: 426099a3e7
GitHub-Pull-Request: golang/go#65805
Reviewed-on: https://go-review.googlesource.com/c/go/+/565277
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Sean Liao <sean@liao.dev>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Sean Liao <sean@liao.dev>
time.Time has had an AppendFormat method since go1.5 so there's no
need to carry around a custom implementation.
Change-Id: I8e7e5a9ac34e8bf251f5d70555405777ce4e22a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/647955
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Replace `for _, s := range {strings, bytes}.Split(v, sep)` with
`for s := range {strings, bytes}.SplitSeq(v, sep)`, to simplify
the code and reduce some memory allocations.
Change-Id: Idead4de1e3928fc75cc5ba8caeff85542f1243d5
GitHub-Last-Rev: 5fb196a073
GitHub-Pull-Request: golang/go#71554
Reviewed-on: https://go-review.googlesource.com/c/go/+/646216
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Add an UnencryptedHTTP2 protocol value.
Both Server and Transport implement "HTTP/2 with prior knowledge"
as described in RFC 9113, section 3.3. Neither supports the
deprecated HTTP/2 upgrade mechanism (RFC 7540, section 3.2 "h2c").
For Server, UnencryptedHTTP2 controls whether the server
will accept HTTP/2 connections on unencrypted ports.
When enabled, the server checks new connections for
the HTTP/2 preface and routes them appropriately.
For Transport, enabling UnencryptedHTTP2 and disabling HTTP1
causes http:// requests to be made over unencrypted HTTP/2
connections.
For #67816
Change-Id: I2763c4cdec1c2bc6bb8157edb93b94377de8a59b
Reviewed-on: https://go-review.googlesource.com/c/go/+/622976
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Support configuring which HTTP version(s) a server or client use
via an explicit set of protocols. The Protocols field takes
precedence over TLSNextProto and ForceAttemptHTTP2.
Fixes#67814
Change-Id: I09ece88f78ad4d98ca1f213157b5f62ae11e063f
Reviewed-on: https://go-review.googlesource.com/c/go/+/607496
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
For #70130
Change-Id: Idd7ca3d11b78887709b83dd5c868de9cc506ecff
Reviewed-on: https://go-review.googlesource.com/c/go/+/623835
Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Remove an unexported field from ServeMux that was there only to support
some Google-internal packages. It is no longer needed.
Change-Id: I6a4d542c6c016f5a9f3d24d0c73f6ddd44c9562e
Reviewed-on: https://go-review.googlesource.com/c/go/+/616355
Reviewed-by: Chressie Himpel <chressie@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Change-Id: If8e02760fe1fb095ecebc306fd98662a51a1f66f
GitHub-Last-Rev: 7b8099f1fe
GitHub-Pull-Request: golang/go#69426
Reviewed-on: https://go-review.googlesource.com/c/go/+/612736
Reviewed-by: Tim King <taking@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Add a field to Server and Transport containing HTTP/2 configuration
parameters.
This field will have no effect until golang.org/x/net/http2 is updated
to make use of it, and h2_bundle.go is updated with the new http2
package.
For #67813
Change-Id: I81d7f8e9ddea78f9666383983aec43e3884c13ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/602175
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
"receiver name `srv` should be consistent with the previous receiver name
`s` for Server" according to go-lint.
Change-Id: I3071ae30b7c1375999e5a599a0eee7b88494f17e
GitHub-Last-Rev: 093c7679b1
GitHub-Pull-Request: golang/go#65787
Reviewed-on: https://go-review.googlesource.com/c/go/+/565175
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Responses to HEAD requests don't have a body.
The ResponseWriter automatically discards writes to the response body
when responding to a HEAD request. ResponseWriter.ReadFrom was failing
to discard writes under some circumstances; fix it to do so.
Fixes#68609
Change-Id: I912f6b2b2a535df28ae37b875fcf15b10da1af2b
Reviewed-on: https://go-review.googlesource.com/c/go/+/601475
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Auto-Submit: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This CL is similar to CL 562557, and it takes over CL 594175.
While here, unrelatedly remove mapKeys function, use slices.Sorted(maps.Keys(ms))
to simplify code.
Fixes#67657
Change-Id: Id8b99216f87a6dcfd6d5fa61407b515324c79112
Reviewed-on: https://go-review.googlesource.com/c/go/+/594737
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Joedian Reid <joedian@google.com>
This reverts the changes to Error from CL 571995, and adds a
GODEBUG controlling the changes to ServeContent/ServeFile/ServeFS.
The change to remove the Content-Encoding header when serving an error
breaks middleware which sets Content-Encoding: gzip and wraps a
ResponseWriter in one which compresses the response body.
This middleware already breaks when ServeContent handles a Range request.
Correct uses of ServeContent which serve pre-compressed content with
a Content-Encoding: gzip header break if we don't remove that header
when serving errors. Therefore, we keep the change to ServeContent/
ServeFile/ServeFS, but we add the ability to disable the new behavior
by setting GODEBUG=httpservecontentkeepheaders=1.
We revert the change to Error, because users who don't want to include
a Content-Encoding header in errors can simply remove the header
themselves, or not add it in the first place.
Fixes#66343
Change-Id: Ic19a24b73624a5ac1a258ed7a8fe7d9bf86c6a38
Reviewed-on: https://go-review.googlesource.com/c/go/+/593157
Reviewed-by: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Just like for tls.Config.GetCertificate the http.Server.ServeTLS method
should be checking tls.Config.GetConfigForClient before trying top open
the specified certFile/keyFile.
This was previously fixed for crypto/tls when using tls.Listen in
CL205059, but the same change for net/http was missed. I've added a
comment src/crypto/tls/tls.go in the relevant section in the hope that
any future changes of a similar nature consider will consider updating
net/http as needed as well.
Change-Id: I312303bc497d92aa2f4627fe2620c70779cbcc99
GitHub-Last-Rev: 6ed29a9008
GitHub-Pull-Request: golang/go#66795
Reviewed-on: https://go-review.googlesource.com/c/go/+/578396
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
When sending a request with an "Expect: 100-continue" header,
we must send the request body before sending any further requests
on the connection.
When receiving a non-1xx response to an "Expect: 100-continue" request,
send the request body if the connection isn't being closed after
processing the response. In other words, if either the request
or response contains a "Connection: close" header, then skip sending
the request body (because the connection will not be used for
further requests), but otherwise send it.
Correct a comment on the server-side Expect: 100-continue handling
that implied sending the request body is optional. It isn't.
For #67555
Change-Id: Ia2f12091bee697771087f32ac347509ec5922d54
Reviewed-on: https://go-review.googlesource.com/c/go/+/591255
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Use the default frame scheduler (currently round-robin)
rather than overriding the default with the priority scheduler.
The priority scheduler is slow, known buggy, and implements
a deprecated stream prioritization mechanism. The default
changed in x/net about a year ago, but we missed that net/http
is overriding that default.
Fixes#67706
Change-Id: I6d76dd0cc8c55eb5dec5cd7d25a5084877e8e8d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/590796
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
Add linknames for most modules with ≥50 dependents.
Add linknames for a few other modules that we know
are important but are below 50.
Remove linknames from badlinkname.go that do not merit
inclusion (very small number of dependents).
We can add them back later if the need arises.
Fixes#67401. (For now.)
Change-Id: I1e49fec0292265256044d64b1841d366c4106002
Reviewed-on: https://go-review.googlesource.com/c/go/+/587756
Auto-Submit: Russ Cox <rsc@golang.org>
TryBot-Bypass: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
When a request contains an "Expect: 100-continue" header,
the first read from the request body causes the server to
write a 100-continue status.
This write caused a panic when performed after the server handler
has exited. Disable the write when cleaning up after a handler
exits.
This also fixes a bug where an implicit 100-continue could be
sent after a call to WriteHeader has sent a non-1xx header.
This change drops tracking of whether we've written a
100-continue or not in response.wroteContinue. This tracking
was used to determine whether we should consume the remaining
request body in chunkWriter.writeHeader, but the discard-the-body
path was only taken when the body was already consumed.
(If the body is not consumed, we set closeAfterReply, and we
don't consume the remaining body when closeAfterReply is set.
If the body is consumed, then we may attempt to discard the
remaining body, but there is obviously no body remaining.)
Fixes#53808
Change-Id: I3542df26ad6cdfe93b50a45ae2d6e7ef031e46fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/585395
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
This is a reapply of CL 544019 and CL 569815, but with
less aggressive semantics as discussed in proposal #66343.
Error deletes Content-Encoding, since it is writing the response
and any preset encoding may not be correct.
On the error-serving path in ServeContent/ServeFile/ServeFS,
these functions delete additional headers: Etag, Last-Modified,
and Cache-Control. The caller may have set these intending
them for the success response, and they may well not be correct
for error responses.
Fixes#50905.
Fixes#66343.
Change-Id: I873d33edde1805990ca16d85ea8d7735b7448626
Reviewed-on: https://go-review.googlesource.com/c/go/+/571995
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Change-Id: I826412175876a84ab978aba9418be28593484fba
GitHub-Last-Rev: d35753c7e0
GitHub-Pull-Request: golang/go#67112
Reviewed-on: https://go-review.googlesource.com/c/go/+/582435
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
We log TLS handshake errors in general, but currently do not log errors
when the first TLS record looks like an attempt to send HTTP to an HTTPS
port. There doesn't seem to be any principled reason to log the one and
not the other, so just log all TLS handshake errors.
Fixes#66501
Change-Id: I5d78a754d054c220be935513448515721fa387a6
Reviewed-on: https://go-review.googlesource.com/c/go/+/573979
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Auto-Submit: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
"strSliceContains" is replaced by "slices.Contains".
Replace "sort.Strings" with "slices.Sort" since it becomes a wrapper
of "slices.Sort" from Go 1.22.
"headerSorter" no longer has to implement "sort.Interface".
We use "slice.SortFunc" to sort kvs.
Change-Id: Ic29b4c3db147c16079575eca7ad6ff6c0f581188
GitHub-Last-Rev: 78221d5aa2
GitHub-Pull-Request: golang/go#66440
Reviewed-on: https://go-review.googlesource.com/c/go/+/573275
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: qiulaidongfeng <2645477756@qq.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
Change-Id: I0d6336e6a21aef14e7229594a335899083fa98b1
Reviewed-on: https://go-review.googlesource.com/c/go/+/570396
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: David Chase <drchase@google.com>
This reverts CL 544019 and CL 569815, because they break a variety
of tests inside Google that do not expect the Cache-Control header
to be set to no-cache.
A followup CL will add this functionality back after a proposal.
For #50905.
Change-Id: Ie377bfb72ce2c77d11bf31f9617ab6db342a408a
Reviewed-on: https://go-review.googlesource.com/c/go/+/571975
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This reverts commit 2b58355ef6.
Reason for revert: This breaks tons of tests for no real reason.
Change-Id: I89773f48cf983c0b6346e46c37a0ebbe2620e3b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/571675
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
CL 544019 changes http.Error to remove misleading response headers.
However, it also adds new "Cache-Control" header unconditionally, which
may breaks existing clients out there, who do not expect to see the
this header in the response like test in golang.org/x/net/http2.
To keep thing backward compatible, http.Error should only add
Cache-Control header if it has been presented.
Updates #50905
Change-Id: I989e9f999a30ec170df4fb28905f50aed0267dad
Reviewed-on: https://go-review.googlesource.com/c/go/+/569815
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
ServeContent API is to set some headers you want to see in the response
before calling ServeContent. But if there is an error, those headers
should be removed otherwise they might confused the client.
Removing those headers is useful in general in the case of an error,
so we remove them in http.Error.
Fixes#50905.
Change-Id: If8d2786c1512906ac93e6b388df6ab1c5ecd1ea9
GitHub-Last-Rev: 32b6f045a7
GitHub-Pull-Request: golang/go#64312
Reviewed-on: https://go-review.googlesource.com/c/go/+/544019
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
When reading through the docs, I found that the sentence flows better with
the `to` present.
Change-Id: I51c21fa33c7a13748c0814dd87c76b9a8d64e2ec
GitHub-Last-Rev: 0642bd7185
GitHub-Pull-Request: golang/go#63587
Reviewed-on: https://go-review.googlesource.com/c/go/+/535935
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Error replies to a request with an error message and HTTP code.
Delete any preexisting Content-Length header before writing the header;
if a Content-Length is present, it's probably for content that the
caller has given up on writing.
For #50905
Change-Id: Ia3d4ca008be46fa5d41afadf29ca5cacb1c47660
Reviewed-on: https://go-review.googlesource.com/c/go/+/554216
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Do not add a trailing slash and redirect if the path already
ends in a slash.
Also, and unrelatedly, add a test for cleanPath.
Fixes#65624.
Change-Id: Ifcf9edc929d2eb6db88132c09d2bade85c5dda3d
Reviewed-on: https://go-review.googlesource.com/c/go/+/562557
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This commit is aimed at improving the readability and consistency
of the code base. Extraneous newline characters were present after
some return statements, creating unnecessary separation in the code.
Fixes#64610
Change-Id: Ic1b05bf11761c4dff22691c2f1c3755f66d341f7
Reviewed-on: https://go-review.googlesource.com/c/go/+/548316
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This is inspired by CL 539915, I'm only submitting now that
CL 456435 has been merged.
This divide the number of objects kept alive by the heap by two
and remove the slice header allocation in New and in the put back.
Change-Id: Ibcd5166bac5a37f365a533e09a28f3b79f81ad58
Reviewed-on: https://go-review.googlesource.com/c/go/+/543515
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: qiulaidongfeng <2645477756@qq.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
When the httpmuxgo121 GODEBUG setting was active, we were registering
patterns in the old and the new way. Fix to register only in the old
way.
Change-Id: Ibc1fd41e7f4d162ee5bc34575df409e1db5657cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/533095
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Olena Synenka <olenasynenka@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Make sure a ServeMux with no patterns is well-behaved.
Updates #61410.
Change-Id: Ib3eb85b384e1309e785663902d2c45ae01e64807
Reviewed-on: https://go-review.googlesource.com/c/go/+/530479
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Add the GODEBUG setting httpmuxgo121.
When set to "1", ServeMux behaves exactly like it did in Go 1.21.
Implemented by defining a new, unexported type, serveMux121, that
uses the original code.
Updates #61410.
Change-Id: I0a9d0fe2a2286e442d680393e62895ab50683cea
Reviewed-on: https://go-review.googlesource.com/c/go/+/530461
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
When parsing patterns and matching, split the path into segments at
slashes, then unescape each segment.
This behaves as most people would expect:
- The pattern "/%61" matches the paths "/a" and "/%61".
- The pattern "/%7B" matches the path "/{". (If we did not unescape
patterns, there would be no way to write that pattern: because "/{"
is a parse error because it is an invalid wildcard.)
- The pattern "/user/{u}" matches "/user/john%2Fdoe" with u set to
"john/doe".
- The unexpected redirections of #21955 will not occur.
A later CL will restore the old behavior behind a GODEBUG setting.
Updates #61410.
Fixes#21955.
Change-Id: I99025e149021fc94bf87d351699270460db532d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/530575
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
It can be difficult to tell at a glance why two patterns conflict, so
explain it with example paths.
Change-Id: Ie384f0a4ef64f30e6e6898bce4b88027bc81034b
Reviewed-on: https://go-review.googlesource.com/c/go/+/529122
Run-TryBot: Jonathan Amsterdam <jba@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Add an index so that pattern registration isn't always quadratic.
If there were no index, then every pattern that was registered would
have to be compared to every existing pattern for conflicts. This
would make registration quadratic in the number of patterns, in every
case.
The index in this CL should help most of the time. If a pattern has a
literal segment, it will weed out all other patterns that have a
different literal in that position.
The worst case will still be quadratic, but it is unlikely that a set
of such patterns would arise naturally.
One novel (to me) aspect of the CL is the use of fuzz testing on data
that is neither a string nor a byte slice. The test uses fuzzing to
generate a byte slice, then decodes the byte slice into a valid
pattern (most of the time). This test actually caught a bug: see
https://go.dev/cl/529119.
Change-Id: Ice0be6547decb5ce75a8062e4e17227815d5d0b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/529121
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
