chore: upgrade to go1.21.8 #60
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Long ago we decided that panic(nil) was too unlikely to bother
making a special case for purposes of recover. Unfortunately,
it has turned out not to be a special case. There are many examples
of code in the Go ecosystem where an author has written panic(nil)
because they want to panic and don't care about the panic value.
Using panic(nil) in this case has the unfortunate behavior of
making recover behave as though the goroutine isn't panicking.
As a result, code like:
func f() {
defer func() {
if err := recover(); err != nil {
log.Fatalf("panicked! %v", err)
}
}()
call1()
call2()
}
looks like it guarantees that call2 has been run any time f returns,
but that turns out not to be strictly true. If call1 does panic(nil),
then f returns "successfully", having recovered the panic, but
without calling call2.
Instead you have to write something like:
func f() {
done := false
defer func() {
if err := recover(); !done {
log.Fatalf("panicked! %v", err)
}
}()
call1()
call2()
done = true
}
which defeats nearly the whole point of recover. No one does this,
with the result that almost all uses of recover are subtly broken.
One specific broken use along these lines is in net/http, which
recovers from panics in handlers and sends back an HTTP error.
Users discovered in the early days of Go that panic(nil) was a
convenient way to jump out of a handler up to the serving loop
without sending back an HTTP error. This was a bug, not a feature.
Go 1.8 added panic(http.ErrAbortHandler) as a better way to access the feature.
Any lingering code that uses panic(nil) to abort an HTTP handler
without a failure message should be changed to use http.ErrAbortHandler.
Programs that need the old, unintended behavior from net/http
or other packages can set GODEBUG=panicnil=1 to stop the run-time error.
Uses of recover that want to detect panic(nil) in new programs
can check for recover returning a value of type *runtime.PanicNilError.
Because the new GODEBUG is used inside the runtime, we can't
import internal/godebug, so there is some new machinery to
cross-connect those in this CL, to allow a mutable GODEBUG setting.
That won't be necessary if we add any other mutable GODEBUG settings
in the future. The CL also corrects the handling of defaulted GODEBUG
values in the runtime, for #56986.
Fixes #25448.
Change-Id: I2b39c7e83e4f7aa308777dabf2edae54773e03f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/461956
Reviewed-by: Robert Griesemer <gri@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
…rics Allow GODEBUG users to report how many times a setting resulted in non-default behavior. Record non-default-behaviors for all existing GODEBUGs. Also rework tests to ensure that runtime is in sync with runtime/metrics.All, and generate docs mechanically from metrics.All. For #56986. Change-Id: Iefa1213e2a5c3f19ea16cd53298c487952ef05a4 Reviewed-on: https://go-review.googlesource.com/c/go/+/453618 TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
The pconn write loop closes a request's body after sending the request, but in the case where the write loop exits with an unsent request in writech the body is never closed. Close the request body in this case. Fixes #49621 Change-Id: Id94a92937bbfc0beb1396446f4dee32fd2059c7e Reviewed-on: https://go-review.googlesource.com/c/go/+/461675 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Preserve sensitive headers on a redirect to a different port of the same host. Fixes #35104 Change-Id: I5ab57c414ce92a70e688ee684b9ff02fb062b3c6 GitHub-Last-Rev: 8d53e71e2243c141d70d27a503d0f7e6dee64c3c GitHub-Pull-Request: golang/go#54539 Reviewed-on: https://go-review.googlesource.com/c/go/+/424935 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Damien Neil <dneil@google.com> Run-TryBot: Damien Neil <dneil@google.com>
Change-Id: I324cedfcdfa1d7eac7be43dc89febb584359c8e3 GitHub-Last-Rev: 7724cd84f323b531215db0406f72481394d0b206 GitHub-Pull-Request: golang/go#57799 Reviewed-on: https://go-review.googlesource.com/c/go/+/462039 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Damien Neil <dneil@google.com> Auto-Submit: Damien Neil <dneil@google.com> Run-TryBot: Damien Neil <dneil@google.com>
NodeJS 18 introduced support for the fetch API for making HTTP requests. This broke all wasm tests that were relying on NodeJS falling back to the fake network implementation in net_fake.go. Disable the fetch API on NodeJS to get tests passing. Fixes #57613 Change-Id: Icb2cce6d5289d812da798e07366f8ac26b5f82cb Reviewed-on: https://go-review.googlesource.com/c/go/+/463976 Reviewed-by: Evan Phoenix <evan@phx.io> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Change-Id: I2379cceeb74cb8511058b24cdd100b21649505ce Reviewed-on: https://go-review.googlesource.com/c/go/+/462197 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Damien Neil <dneil@google.com>
CopyBuffer allocates a 32k buffer when no buffer is available. Allocate these buffers from a sync.Pool. This removes an optimization where the copy buffer size was reduced when the source is a io.LimitedReader (including the case of CopyN) with a limit less than the default buffer size. This change could cause a program which only uses io.Copy with sources with a small limit to allocate unnecessarily large buffers. Programs which care about the transient buffer allocation can avoid this by providing their own buffer. name old time/op new time/op delta CopyNSmall-10 165ns ± 7% 117ns ± 7% -29.19% (p=0.001 n=7+7) CopyNLarge-10 7.33µs ±34% 4.07µs ± 2% -44.52% (p=0.001 n=7+7) name old alloc/op new alloc/op delta CopyNSmall-10 2.20kB ±12% 1.20kB ± 4% -45.24% (p=0.000 n=8+7) CopyNLarge-10 148kB ± 9% 81kB ± 4% -45.26% (p=0.000 n=8+7) name old allocs/op new allocs/op delta CopyNSmall-10 2.00 ± 0% 1.00 ± 0% -50.00% (p=0.000 n=8+8) CopyNLarge-10 2.00 ± 0% 1.00 ± 0% -50.00% (p=0.000 n=8+8) For #57202 Change-Id: I2292226da9ba1dc09a2543f5d74fe5da06080d49 Reviewed-on: https://go-review.googlesource.com/c/go/+/456555 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Thomas Austad <thomas.austad@gmail.com> Auto-Submit: Damien Neil <dneil@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
Updates #37327 Change-Id: I87774be71ed54e9c45a27062122e6177888e890a Reviewed-on: https://go-review.googlesource.com/c/go/+/226137 Auto-Submit: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Bryan Mills <bcmills@google.com> Reviewed-by: Damien Neil <dneil@google.com>
Change-Id: I7e71626246af94047fbd1abb9bb77f2cd9b281fb Reviewed-on: https://go-review.googlesource.com/c/go/+/465195 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Damien Neil <dneil@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Damien Neil <dneil@google.com>
The Error type used in failed fetch invocations contain more information than we're currently extracting. Optimistically look for the cause field for extra context for errors. Change-Id: I6c8e4b230a21ec684af2107707aa605fc2148fcf Reviewed-on: https://go-review.googlesource.com/c/go/+/463978 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Evan Phoenix <evan@phx.io> Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Auto-Submit: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
This reverts CL 456555. Reason for revert: This seems too likely to exercise race conditions in code where a Write call continues to access its buffer after returning. The HTTP/2 ResponseWriter is one such example. Reverting this change while we think about this some more. For #57202 Change-Id: Ic86823f81d7da410ea6b3f17fb5b3f9a979e3340 Reviewed-on: https://go-review.googlesource.com/c/go/+/467095 Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Damien Neil <dneil@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
Change-Id: I6facfae14e850f6c9bf3bcb53489c8b475bbb860 Reviewed-on: https://go-review.googlesource.com/c/go/+/467297 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Damien Neil <dneil@google.com> Run-TryBot: David Chase <drchase@google.com>
Pull in HTTP/2 fix to deflake builders:
547e7edf38 http2: avoid referencing ResponseWrite.Write parameter after returning
For #58446
Change-Id: I7f3666bc1f20ee03a7ccf25f0e091033cbc635d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/467657
Auto-Submit: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Change-Id: I16ec916b47de2f417b681c8abff5a1375ddf491b Reviewed-on: https://go-review.googlesource.com/c/go/+/468055 Run-TryBot: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reader.ReadForm is documented as storing "up to maxMemory bytes + 10MB" in memory. Parsed forms can consume substantially more memory than this limit, since ReadForm does not account for map entry overhead and MIME headers. In addition, while the amount of disk memory consumed by ReadForm can be constrained by limiting the size of the parsed input, ReadForm will create one temporary file per form part stored on disk, potentially consuming a large number of inodes. Update ReadForm's memory accounting to include part names, MIME headers, and map entry overhead. Update ReadForm to store all on-disk file parts in a single temporary file. Files returned by FileHeader.Open are documented as having a concrete type of *os.File when a file is stored on disk. The change to use a single temporary file for all parts means that this is no longer the case when a form contains more than a single file part stored on disk. The previous behavior of storing each file part in a separate disk file may be reenabled with GODEBUG=multipartfiles=distinct. Update Reader.NextPart and Reader.NextRawPart to set a 10MiB cap on the size of MIME headers. Thanks to Jakob Ackermann (@das7pad) for reporting this issue. Fixes #58006 Fixes CVE-2022-41725 Change-Id: Ibd780a6c4c83ac8bcfd3cbe344f042e9940f2eab Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1714276 Reviewed-by: Julie Qiu <julieqiu@google.com> TryBot-Result: Security TryBots <security-trybots@go-security-trybots.iam.gserviceaccount.com> Reviewed-by: Roland Shoemaker <bracewell@google.com> Run-TryBot: Damien Neil <dneil@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/468124 Auto-Submit: Michael Pratt <mpratt@google.com> Run-TryBot: Michael Pratt <mpratt@google.com> Reviewed-by: Than McIntosh <thanm@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
With new releases of Chrome, Opera and Deno it is possible to stream the body of a POST request. Add support for using that interface when it is available. Change-Id: Ib23d63cd3dea634bd9e267abf4e9a9bfa9c525ad Reviewed-on: https://go-review.googlesource.com/c/go/+/458395 Auto-Submit: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> Reviewed-by: Michael Pratt <mpratt@google.com> Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Wait forever and let the test time out with a stack trace if the expected response doesn't happen. Fixes #57990 Change-Id: I835def63db113752cdd06e03e258cb10d63a6a25 Reviewed-on: https://go-review.googlesource.com/c/go/+/463222 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Bryan Mills <bcmills@google.com>
It's been years since the behavior here was changed, and there's little point in continuing to warn users of it. Fixes #49399 Change-Id: I95f64ca14cacb64ebe78296593b1cc3d837e6b77 Reviewed-on: https://go-review.googlesource.com/c/go/+/470315 Run-TryBot: Damien Neil <dneil@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
…t performance boost
goos: linux
goarch: amd64
pkg: net/http
cpu: DO-Premium-Intel
│ old │ new │
│ sec/op │ sec/op vs base │
HexEscapeNonASCII-4 469.6n ± 20% 371.1n ± 9% -20.98% (p=0.000 n=10)
│ old │ new │
│ B/op │ B/op vs base │
HexEscapeNonASCII-4 192.0 ± 0% 192.0 ± 0% ~ (p=1.000 n=10) ¹
¹ all samples are equal
│ old │ new │
│ allocs/op │ allocs/op vs base │
HexEscapeNonASCII-4 2.000 ± 0% 2.000 ± 0% ~ (p=1.000 n=10) ¹
¹ all samples are equal
Change-Id: Ic8d2b3ddcf2cf724dec3f51a2aba205f2c6e4fe6
Reviewed-on: https://go-review.googlesource.com/c/go/+/425786
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Andy Pan <panjf2000@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Change-Id: Ica8d5e5799a4de532764ae86cdb623508d3a8e18 GitHub-Last-Rev: 3e97cca9de3885f2fe0d7deb776e59cc1c73146d GitHub-Pull-Request: golang/go#58689 Reviewed-on: https://go-review.googlesource.com/c/go/+/471021 Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com>
Add support for concurrently reading from an HTTP/1 request body while writing the response. Normally, the HTTP/1 server automatically consumes any remaining request body before starting to write a response, to avoid deadlocking clients which attempt to write a complete request before reading the response. Add a ResponseController.EnableFullDuplex method which disables this behavior. For #15527 For #57786 Change-Id: Ie7ee8267d8333e9b32b82b9b84d4ad28ab8edf01 Reviewed-on: https://go-review.googlesource.com/c/go/+/472636 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org>
If the test actually deadlocks, we probably want a goroutine dump to debug it anyway. Otherwise, the arbitrary timeout can only cause spurious failures. Fixes #36179. Change-Id: Ic2037496959a38d3231eefdbc1dd5d45eebdf306 Reviewed-on: https://go-review.googlesource.com/c/go/+/474582 Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Damien Neil <dneil@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
This small PR allows optimizations made in io.Copy (like the use of io.WriterTo) to be used in one possible path of http.ServeContent (in case of a non-Range request). This, in turn, allows us to skip the buffer allocation in io.Copy. Change-Id: Ifa2ece206ecd4556aaaed15d663b65e95e00bb0a GitHub-Last-Rev: 94fc0318145ba1bd48502564f6488aade871c301 GitHub-Pull-Request: golang/go#56480 Reviewed-on: https://go-review.googlesource.com/c/go/+/446276 Reviewed-by: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Damien Neil <dneil@google.com> Reviewed-by: Damien Neil <dneil@google.com> Run-TryBot: Damien Neil <dneil@google.com>
This change eliminates the easy, arbitrary timouts that should never happen. It leaves in place a couple of more complicated ones that will probably need retry loops for robustness. For #49336. For #36179. Change-Id: I657ef223a66461413a915da5ce9150f49acec04a Reviewed-on: https://go-review.googlesource.com/c/go/+/476035 Run-TryBot: Bryan Mills <bcmills@google.com> Auto-Submit: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Damien Neil <dneil@google.com>
…down As soon as the test server closes its listener, its port may be reused for another test server. On some platforms port reuse takes a long time, because they cycle through the available ports before reusing an old one. However, other platforms reuse ports much more aggressively. net/http shouldn't know or care which kind of platform it is on — dialing wild connections is risky and can interfere with other tests no matter what platform we do it on. Instead of making the second request after the server has completely shut down, we can start (and finish!) the entire request while we are certain that the listener has been closed but the port is still open serving an existing request. If everything synchronizes as we expect, that should guarantee that the second request fails. Fixes #56421. Change-Id: I56add243bb9f76ee04ead8f643118f9448fd1280 Reviewed-on: https://go-review.googlesource.com/c/go/+/476036 Auto-Submit: Bryan Mills <bcmills@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Damien Neil <dneil@google.com>
Previously, the reverse proxy is unable to detect the support for hijack or flush if those things are residing in the response writer in a wrapped manner. The reverse proxy now makes use of the new http response controller as the means to discover the underlying flusher and hijacker associated with the response writer, allowing wrapped flusher and hijacker become discoverable. Change-Id: I53acbb12315c3897be068e8c00598ef42fc74649 Reviewed-on: https://go-review.googlesource.com/c/go/+/468755 Run-TryBot: Damien Neil <dneil@google.com> Auto-Submit: Damien Neil <dneil@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
Change-Id: I5b3158ecd0eb20dc433a53a2b03eb4551cbb3f7d Reviewed-on: https://go-review.googlesource.com/c/go/+/477196 Auto-Submit: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Bryan Mills <bcmills@google.com> Reviewed-by: Damien Neil <dneil@google.com>
…nnot be reused In #59155, we observed that the IdleConnStrsForTesting_h2 helper function sometimes reported extra connections after a "client conn not usable" failure and retry. It turns out that that state corresponds exactly to the http2clientConnIdleState.canTakeNewRequest field, so (with a bit of extra nethttpomithttp2 plumbing) we can use that field in the helper to filter out the unusable connections. Fixes #59155. Change-Id: Ief6283c9c8c5ec47dd9f378beb0ddf720832484e Reviewed-on: https://go-review.googlesource.com/c/go/+/477856 Reviewed-by: Damien Neil <dneil@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Bryan Mills <bcmills@google.com> Auto-Submit: Bryan Mills <bcmills@google.com>
This is intended to fix the failure mode observed in https://build.golang.org/log/f153e06ed547517fb2cddb0fa817fea40a6146f7, but I haven't been able to reproduce that failure mode locally so I'm not sure whether it actually does. Change-Id: Ib14378f1299a76b54013419bdc715a9dbdd94667 Reviewed-on: https://go-review.googlesource.com/c/go/+/478235 Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Damien Neil <dneil@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
Change-Id: I3b6dd9c40b3c10db2eda6a25b9d556c9c3733bbc GitHub-Last-Rev: fd9b0c4193511a75b4a0073f37aa3116db23a46f GitHub-Pull-Request: golang/go#57448 Reviewed-on: https://go-review.googlesource.com/c/go/+/458876 Reviewed-by: Javad Rajabzadeh <ja7ad@live.com> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
This is a second round of CL 469095 which has been fixed after the issue discovered in the revert CL 495017. The issue was a missing res.Body.Close() in the newly added test. Change-Id: Ifd9d8458022e59f4486397443a2862d06383e990 Reviewed-on: https://go-review.googlesource.com/c/go/+/495115 Reviewed-by: Damien Neil <dneil@google.com> Run-TryBot: Jorropo <jorropo.pgm@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Generated with x/build/cmd/updatestd. Updates #36905. Change-Id: Iecd76e820c5f40a0f5e013684f7e7bef4c3fd482 Reviewed-on: https://go-review.googlesource.com/c/go/+/498598 Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
Failing to close the response body before returning leaks the in-progress request past the test lifetime. Fixes #60264 Change-Id: Ic327d9f8e02e87ed656324aaa042f833d9ea18ca Reviewed-on: https://go-review.googlesource.com/c/go/+/501309 Run-TryBot: Damien Neil <dneil@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com>
There are some symbol mismatches in the comments, this commit attempts to fix them Change-Id: I5c9075e5218defe9233c075744d243b26ff68496 Reviewed-on: https://go-review.googlesource.com/c/go/+/492996 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: shuang cui <imcusg@gmail.com> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Run-TryBot: Michael Pratt <mpratt@google.com> Auto-Submit: Michael Pratt <mpratt@google.com>
The Fetch API was meant to only be disabled in tests. Since wasm_exec.js defines a global 'process' object, it ended up being disabled anywhere that script is used. Make the heuristic stricter so that it's less likely to trigger anywhere but when testing js/wasm using Node.js. For #57613. Fixes #60808. Change-Id: Ief8def802b466ef4faad16daccefcfd72e4398b8 Reviewed-on: https://go-review.googlesource.com/c/go/+/503675 TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Damien Neil <dneil@google.com>
The main change here is fixing the panic where it was called even when req.Body was nil. It might also work better to keep the req.Body.Close calls closer after req.Body is read, so do that too. Calling readableStreamPull.Release on a js.Func with a zero value is currently a no-op, but it seems better to avoid it anyway. Also remove readableStreamStart, readableStreamCancel while here. They were used in the initial but not final patch set of CL 458395. Fixes #60809. Change-Id: I6ff2e3b6ec2cd4b0c9c67939903e32908312db8d Reviewed-on: https://go-review.googlesource.com/c/go/+/503676 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
RemoteAddr can return nil in some cases, this fix prevents a panic. I chatted with @neild about this beforehand, but what's happening in our case is that a connection comes in to the HTTP server which is then immediately closed (we discovered this issue by accident using nmap). The network implementation that we're using (it happens to be gVisor via its gonet adaptor) is returning nil from RemoteAddr(), presumably as there is no remote at that point. But, ultimately, since RemoteAddr returns an interface it is always possible for it to return nil, and indeed conn.RemoteAddr in this file does exactly that if the conn is not ok. Change-Id: Ibe67ae6e30b68e2776df5ee2911bf5f1dc539641 GitHub-Last-Rev: ff3505d1d0b00ca16c68ec2a05f542978b79b170 GitHub-Pull-Request: golang/go#60823 Reviewed-on: https://go-review.googlesource.com/c/go/+/503656 Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Damien Neil <dneil@google.com> Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
Verify that the Host header we send is valid. Avoids surprising behavior such as a Host of "go.dev\r\nX-Evil:oops" adding an X-Evil header to HTTP/1 requests. Add a test, skip the test for HTTP/2. HTTP/2 is not vulnerable to header injection in the way HTTP/1 is, but x/net/http2 doesn't validate the header and will go into a retry loop when the server rejects it. CL 506995 adds the necessary validation to x/net/http2. For #60374 Change-Id: I05cb6866a9bead043101954dfded199258c6dd04 Reviewed-on: https://go-review.googlesource.com/c/go/+/506996 Reviewed-by: Tatiana Bradley <tatianabradley@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Damien Neil <dneil@google.com>
Also fix a (minor) double-Close error in Serve that was exposed by the test fix. Serve accepts a net.Listener, which produces net.Conn instances. The documentation for net.Conn requires its methods to be safe for concurrent use, so most implementations likely allow Close to be called multiple times as a side effect of making it safe to call concurrently with other methods. However, the net.Conn interface is a superset of the io.Closer interface, io.Closer explicitly leaves the behavior of multiple Close calls undefined, and net.Conn does not explicitly document a stricter requirement. Perhaps more importantly, the test for the fcgi package calls unexported functions that accept an io.ReadWriteCloser (not a net.Conn), and at least one of the test-helper ReadWriteCloser implementations expects Close to be called only once. The goroutine leaks were exposed by a racy arbitrary timeout reported in #61271. Fixing the goroutine leak exposed the double-Close error: one of the leaked goroutines was blocked on reading from an unclosed pipe. Closing the pipe (to unblock the goroutine) triggered the second Close call. Fixes #61271. Change-Id: I5cfac8870e4bb4f13adeee48910d165dbd4b76fe Reviewed-on: https://go-review.googlesource.com/c/go/+/508815 Run-TryBot: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
Generated by: go install golang.org/x/tools/cmd/bundle@latest go install golang.org/x/build/cmd/updatestd@latest updatestd -goroot=$GOROOT -branch=master For #36905. For #55079. Fixes #61174 (vet checkers understanding Go language version). Fixes #61200 (slog InfoCtx -> InfoContext etc). Change-Id: I4f2c86960ce72d6df06e23da1b1297ab3ff2eecf Reviewed-on: https://go-review.googlesource.com/c/go/+/509099 Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Jonathan Amsterdam <jba@google.com> Reviewed-by: Alan Donovan <adonovan@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Damien Neil <dneil@google.com>
Change-Id: I5f06a4ef1d827eb0fe32a8d98444142108b0d573 Reviewed-on: https://go-review.googlesource.com/c/go/+/508996 Run-TryBot: Ian Lance Taylor <iant@google.com> Auto-Submit: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Keith Randall <khr@google.com>
h2_bundle.go is generated from x/net/http2, so it must not be edited manually. Change-Id: If76716ce8baf581321358734e5b8bef3541632ca Reviewed-on: https://go-review.googlesource.com/c/go/+/508922 Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: Bryan Mills <bcmills@google.com>
… CopyN not needed" This reverts CL 446276. Reason for revert: Causing surprising performance regression. Fixes #61530 Change-Id: Ic970f2e05d875b606ce274ea621f7e4c8c337481 Reviewed-on: https://go-review.googlesource.com/c/go/+/512615 Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> (cherry picked from commit df0a1297899aff1c46b66523e75aa12b0ff5049f) Reviewed-on: https://go-review.googlesource.com/c/go/+/515795 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Damien Neil <dneil@google.com>
…eaders Historically, the Transport has silently truncated invalid Host headers at the first '/' or ' ' character. CL 506996 changed this behavior to reject invalid Host headers entirely. Unfortunately, Docker appears to rely on the previous behavior. When sending a HTTP/1 request with an invalid Host, send an empty Host header. This is safer than truncation: If you care about the Host, then you should get the one you set; if you don't care, then an empty Host should be fine. Continue to fully validate Host headers sent to a proxy, since proxies generally can't productively forward requests without a Host. For #60374 Fixes #61431 Fixes #61904 Change-Id: If170c7dd860aa20eb58fe32990fc93af832742b6 Reviewed-on: https://go-review.googlesource.com/c/go/+/511155 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> Run-TryBot: Damien Neil <dneil@google.com> (cherry picked from commit b9153f6ef338baee5fe02a867c8fbc83a8b29dd1) Reviewed-on: https://go-review.googlesource.com/c/go/+/518856 Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Run-TryBot: Roland Shoemaker <roland@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
…ent in wasm" CL 458395 added support for streaming POST content in Wasm. Unfortunately, this breaks requests to servers that only support HTTP/1.1. Revert the change until a suitable fallback or opt-in strategy can be decided. For #61889. Fixes #62328. Change-Id: If53a77e1890132063b39abde867d34515d4ac2af Reviewed-on: https://go-review.googlesource.com/c/go/+/522955 Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> Reviewed-by: Damien Neil <dneil@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/524855 Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> Commit-Queue: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Pull in a security fix from x/net/http2: http2: limit maximum handler goroutines to MaxConcurrentStreamso For #63417 Fixes #63427 Fixes CVE-2023-39325 Change-Id: I70626734e6d56edf508f27a5b055ddf96d806eeb Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/2047402 Reviewed-by: Tatiana Bradley <tatianabradley@google.com> Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Ian Cottrell <iancottrell@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/534235 Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
…/http2 After CL 534295 was merged to fix a CVE it introduced an underflow when we try to decrement sc.curHandlers in handlerDone. Pull in a fix from x/net/http2: http2: fix underflow in http2 server push https://go-review.googlesource.com/c/net/+/535595 For #63511 Fixes #63560 Change-Id: I5c678ce7dcc53635f3ad5e4999857cb120dfc1ab GitHub-Last-Rev: 587ffa3cafbb9da6bc82ba8a5b83313f81e5c89b GitHub-Pull-Request: golang/go#63561 Reviewed-on: https://go-review.googlesource.com/c/go/+/535575 Run-TryBot: Mauri de Souza Meneguzzo <mauri870@gmail.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: David Chase <drchase@google.com> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> (cherry picked from commit 0046c1414c4910dfe54abfcdbe18e565dd5a60f6) Reviewed-on: https://go-review.googlesource.com/c/go/+/537996 Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The chunked transfer encoding adds some overhead to the content transferred. When writing one byte per chunk, for example, there are five bytes of overhead per byte of data transferred: "1\r\nX\r\n" to send "X". Chunks may include "chunk extensions", which we skip over and do not use. For example: "1;chunk extension here\r\nX\r\n". A malicious sender can use chunk extensions to add about 4k of overhead per byte of data. (The maximum chunk header line size we will accept.) Track the amount of overhead read in chunked data, and produce an error if it seems excessive. Updates #64433 Fixes #64435 Fixes CVE-2023-39326 Change-Id: I40f8d70eb6f9575fb43f506eb19132ccedafcf39 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/2076135 Reviewed-by: Tatiana Bradley <tatianabradley@google.com> Reviewed-by: Roland Shoemaker <bracewell@google.com> (cherry picked from commit 3473ae72ee66c60744665a24b2fde143e8964d4f) Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/2095408 Run-TryBot: Roland Shoemaker <bracewell@google.com> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/547356 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
… matches on IPv6 zones When deciding whether to forward cookies or sensitive headers across a redirect, do not attempt to interpret an IPv6 address as a domain name. Avoids a case where a maliciously-crafted redirect to an IPv6 address with a scoped addressing zone could be misinterpreted as a within-domain redirect. For example, we could interpret "::1%.www.example.com" as a subdomain of "www.example.com". Thanks to Juho Nurminen of Mattermost for reporting this issue. Fixes CVE-2023-45289 Fixes #65385 For #65065 Change-Id: I8f463f59f0e700c8a18733d2b264a8bcb3a19599 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/2131938 Reviewed-by: Tatiana Bradley <tatianabradley@google.com> Reviewed-by: Roland Shoemaker <bracewell@google.com> Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/2173775 Reviewed-by: Carlos Amedee <amedee@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/569239 Reviewed-by: Carlos Amedee <carlos@golang.org> Auto-Submit: Michael Knyszek <mknyszek@google.com> TryBot-Bypass: Michael Knyszek <mknyszek@google.com>
Conflicts: internal/chunked.go pprof/pprof.go request.go server.go transport.go transport_test.go
Make sure we explain the provenance of each package inside internal and update the diff invocations to cover more packages.
While there, further refine the documentation.
This prevents VSCode from updating imports when saving the file.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request upgrades to go1.21.8. While there, we adapt, improve, and better document the upgrade process.
Here's the diff between us and upstream.