-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: upgrade to go1.21.8 #60
Merged
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 <[email protected]> Run-TryBot: Russ Cox <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Auto-Submit: Russ Cox <[email protected]>
…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 <[email protected]> Auto-Submit: Russ Cox <[email protected]> Run-TryBot: Russ Cox <[email protected]> Reviewed-by: Michael Knyszek <[email protected]>
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 <[email protected]> Run-TryBot: Damien Neil <[email protected]> Reviewed-by: Cherry Mui <[email protected]> Reviewed-by: Brad Fitzpatrick <[email protected]>
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 <[email protected]> Reviewed-by: Cherry Mui <[email protected]> Reviewed-by: Damien Neil <[email protected]> Run-TryBot: Damien Neil <[email protected]>
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 <[email protected]> Reviewed-by: Matthew Dempsky <[email protected]> Reviewed-by: Damien Neil <[email protected]> Auto-Submit: Damien Neil <[email protected]> Run-TryBot: Damien Neil <[email protected]>
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 <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> Run-TryBot: Dmitri Shuralyov <[email protected]> Reviewed-by: Michael Knyszek <[email protected]>
Change-Id: I2379cceeb74cb8511058b24cdd100b21649505ce Reviewed-on: https://go-review.googlesource.com/c/go/+/462197 Run-TryBot: Russ Cox <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Damien Neil <[email protected]>
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 <[email protected]> Run-TryBot: Damien Neil <[email protected]> Reviewed-by: Thomas Austad <[email protected]> Auto-Submit: Damien Neil <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]>
Updates #37327 Change-Id: I87774be71ed54e9c45a27062122e6177888e890a Reviewed-on: https://go-review.googlesource.com/c/go/+/226137 Auto-Submit: Bryan Mills <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Run-TryBot: Bryan Mills <[email protected]> Reviewed-by: Damien Neil <[email protected]>
Change-Id: I7e71626246af94047fbd1abb9bb77f2cd9b281fb Reviewed-on: https://go-review.googlesource.com/c/go/+/465195 Reviewed-by: Dmitri Shuralyov <[email protected]> Auto-Submit: Dmitri Shuralyov <[email protected]> Reviewed-by: Damien Neil <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Run-TryBot: Damien Neil <[email protected]>
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 <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> Reviewed-by: David Chase <[email protected]> Reviewed-by: Evan Phoenix <[email protected]> Run-TryBot: Johan Brandhorst-Satzkorn <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> Auto-Submit: Johan Brandhorst-Satzkorn <[email protected]>
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 <[email protected]> Run-TryBot: Damien Neil <[email protected]> TryBot-Result: Gopher Robot <[email protected]>
Change-Id: I6facfae14e850f6c9bf3bcb53489c8b475bbb860 Reviewed-on: https://go-review.googlesource.com/c/go/+/467297 TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Damien Neil <[email protected]> Run-TryBot: David Chase <[email protected]>
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 <[email protected]> Run-TryBot: Damien Neil <[email protected]> Reviewed-by: Bryan Mills <[email protected]> TryBot-Result: Gopher Robot <[email protected]>
Change-Id: I16ec916b47de2f417b681c8abff5a1375ddf491b Reviewed-on: https://go-review.googlesource.com/c/go/+/468055 Run-TryBot: Ian Lance Taylor <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Auto-Submit: Ian Lance Taylor <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]>
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 <[email protected]> TryBot-Result: Security TryBots <[email protected]> Reviewed-by: Roland Shoemaker <[email protected]> Run-TryBot: Damien Neil <[email protected]> Reviewed-on: https://go-review.googlesource.com/c/go/+/468124 Auto-Submit: Michael Pratt <[email protected]> Run-TryBot: Michael Pratt <[email protected]> Reviewed-by: Than McIntosh <[email protected]> TryBot-Result: Gopher Robot <[email protected]>
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 <[email protected]> Reviewed-by: Michael Pratt <[email protected]> Run-TryBot: Dmitri Shuralyov <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> Reviewed-by: Johan Brandhorst-Satzkorn <[email protected]>
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 <[email protected]> Run-TryBot: Damien Neil <[email protected]> Reviewed-by: Bryan Mills <[email protected]>
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 <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Filippo Valsorda <[email protected]> Reviewed-by: Than McIntosh <[email protected]>
…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 <[email protected]> Auto-Submit: Ian Lance Taylor <[email protected]> Run-TryBot: Andy Pan <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]>
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 <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> Run-TryBot: Ian Lance Taylor <[email protected]>
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 <[email protected]> Run-TryBot: Damien Neil <[email protected]> Reviewed-by: Roland Shoemaker <[email protected]>
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 <[email protected]> Reviewed-by: Damien Neil <[email protected]> Run-TryBot: Bryan Mills <[email protected]> TryBot-Result: Gopher Robot <[email protected]>
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 <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Auto-Submit: Damien Neil <[email protected]> Reviewed-by: Damien Neil <[email protected]> Run-TryBot: Damien Neil <[email protected]>
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 <[email protected]> Auto-Submit: Bryan Mills <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Damien Neil <[email protected]>
…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 <[email protected]> Run-TryBot: Bryan Mills <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Damien Neil <[email protected]>
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 <[email protected]> Auto-Submit: Damien Neil <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Damien Neil <[email protected]> Reviewed-by: Cherry Mui <[email protected]>
Change-Id: I5b3158ecd0eb20dc433a53a2b03eb4551cbb3f7d Reviewed-on: https://go-review.googlesource.com/c/go/+/477196 Auto-Submit: Bryan Mills <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Run-TryBot: Bryan Mills <[email protected]> Reviewed-by: Damien Neil <[email protected]>
…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 <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Run-TryBot: Bryan Mills <[email protected]> Auto-Submit: Bryan Mills <[email protected]>
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 <[email protected]> Reviewed-by: Damien Neil <[email protected]> Run-TryBot: Bryan Mills <[email protected]> TryBot-Result: Gopher Robot <[email protected]>
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 <[email protected]> Reviewed-by: Damien Neil <[email protected]> Reviewed-by: Cherry Mui <[email protected]> Run-TryBot: Dmitri Shuralyov <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Auto-Submit: Dmitri Shuralyov <[email protected]>
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 <[email protected]> Run-TryBot: Jorropo <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Matthew Dempsky <[email protected]> Auto-Submit: Dmitri Shuralyov <[email protected]>
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 <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> Auto-Submit: Dmitri Shuralyov <[email protected]> TryBot-Result: Gopher Robot <[email protected]>
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 <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Bryan Mills <[email protected]>
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 <[email protected]> Run-TryBot: shuang cui <[email protected]> Reviewed-by: Michael Pratt <[email protected]> Reviewed-by: Michael Knyszek <[email protected]> Run-TryBot: Michael Pratt <[email protected]> Auto-Submit: Michael Pratt <[email protected]>
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 <[email protected]> Auto-Submit: Dmitri Shuralyov <[email protected]> Reviewed-by: Johan Brandhorst-Satzkorn <[email protected]> Run-TryBot: Dmitri Shuralyov <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> Reviewed-by: Damien Neil <[email protected]>
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 <[email protected]> Reviewed-by: Johan Brandhorst-Satzkorn <[email protected]> Auto-Submit: Dmitri Shuralyov <[email protected]> Reviewed-by: Bryan Mills <[email protected]> Run-TryBot: Dmitri Shuralyov <[email protected]> TryBot-Result: Gopher Robot <[email protected]>
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 <[email protected]> Reviewed-by: Damien Neil <[email protected]> Run-TryBot: Damien Neil <[email protected]> Reviewed-by: Bryan Mills <[email protected]> TryBot-Result: Gopher Robot <[email protected]>
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 <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Run-TryBot: Damien Neil <[email protected]>
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 <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]> TryBot-Result: Gopher Robot <[email protected]>
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 <[email protected]> Reviewed-by: Jonathan Amsterdam <[email protected]> Reviewed-by: Alan Donovan <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Heschi Kreinick <[email protected]> Reviewed-by: Bryan Mills <[email protected]> Reviewed-by: Damien Neil <[email protected]>
Change-Id: I5f06a4ef1d827eb0fe32a8d98444142108b0d573 Reviewed-on: https://go-review.googlesource.com/c/go/+/508996 Run-TryBot: Ian Lance Taylor <[email protected]> Auto-Submit: Keith Randall <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Run-TryBot: Keith Randall <[email protected]> Reviewed-by: Keith Randall <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]> Auto-Submit: Ian Lance Taylor <[email protected]> Reviewed-by: Keith Randall <[email protected]>
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 <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Cherry Mui <[email protected]> Auto-Submit: Bryan Mills <[email protected]>
… 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 <[email protected]> Reviewed-by: Bryan Mills <[email protected]> TryBot-Result: Gopher Robot <[email protected]> (cherry picked from commit df0a1297899aff1c46b66523e75aa12b0ff5049f) Reviewed-on: https://go-review.googlesource.com/c/go/+/515795 Run-TryBot: Ian Lance Taylor <[email protected]> Reviewed-by: David Chase <[email protected]> Reviewed-by: Damien Neil <[email protected]>
…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 <[email protected]> Reviewed-by: Roland Shoemaker <[email protected]> Run-TryBot: Damien Neil <[email protected]> (cherry picked from commit b9153f6ef338baee5fe02a867c8fbc83a8b29dd1) Reviewed-on: https://go-review.googlesource.com/c/go/+/518856 Auto-Submit: Dmitri Shuralyov <[email protected]> Run-TryBot: Roland Shoemaker <[email protected]> Reviewed-by: Russ Cox <[email protected]>
…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 <[email protected]> Reviewed-by: Damien Neil <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Bryan Mills <[email protected]> Reviewed-by: Johan Brandhorst-Satzkorn <[email protected]> Reviewed-on: https://go-review.googlesource.com/c/go/+/524855 Run-TryBot: Dmitri Shuralyov <[email protected]> Commit-Queue: Dmitri Shuralyov <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> Auto-Submit: Dmitri Shuralyov <[email protected]>
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 <[email protected]> Run-TryBot: Damien Neil <[email protected]> Reviewed-by: Ian Cottrell <[email protected]> Reviewed-on: https://go-review.googlesource.com/c/go/+/534235 Auto-Submit: Dmitri Shuralyov <[email protected]> Reviewed-by: Michael Pratt <[email protected]> Reviewed-by: Damien Neil <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]>
…/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 <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> Reviewed-by: David Chase <[email protected]> Auto-Submit: Dmitri Shuralyov <[email protected]> TryBot-Result: Gopher Robot <[email protected]> (cherry picked from commit 0046c1414c4910dfe54abfcdbe18e565dd5a60f6) Reviewed-on: https://go-review.googlesource.com/c/go/+/537996 Reviewed-by: Cherry Mui <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]>
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 <[email protected]> Reviewed-by: Roland Shoemaker <[email protected]> (cherry picked from commit 3473ae72ee66c60744665a24b2fde143e8964d4f) Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/2095408 Run-TryBot: Roland Shoemaker <[email protected]> Reviewed-by: Damien Neil <[email protected]> Reviewed-on: https://go-review.googlesource.com/c/go/+/547356 Reviewed-by: Dmitri Shuralyov <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]>
… 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 <[email protected]> Reviewed-by: Roland Shoemaker <[email protected]> Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/2173775 Reviewed-by: Carlos Amedee <[email protected]> Reviewed-on: https://go-review.googlesource.com/c/go/+/569239 Reviewed-by: Carlos Amedee <[email protected]> Auto-Submit: Michael Knyszek <[email protected]> TryBot-Bypass: Michael Knyszek <[email protected]>
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.