Skip to content
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

x/net/http2: http.Server.WriteTimeout does not fire if the http2 stream's window is out of space. [1.17 backport] #49921

Closed
gopherbot opened this issue Dec 2, 2021 · 4 comments
Labels
CherryPickApproved Used during the release process for point releases FrozenDueToAge
Milestone

Comments

@gopherbot
Copy link
Contributor

@mknyszek requested issue #49741 to be considered for backport to the next 1.17 minor release.

@davecheney The backport for 1.17 will go in sooner, and we'll file a separate issue for that. It'll definitely go into 1.18.1 when the milestone is opened, I just mean that the fix on tip will land in the 1.19 cycle (so when the tree opens in February).

@gopherbot Please open a backport issue for Go 1.17.

@gopherbot gopherbot added the CherryPickCandidate Used during the release process for point releases label Dec 2, 2021
@gopherbot gopherbot added this to the Go1.17.4 milestone Dec 2, 2021
@heschi heschi modified the milestones: Go1.17.4, Go1.17.5 Dec 2, 2021
@toothrot toothrot modified the milestones: Go1.17.5, Go1.17.6 Dec 9, 2021
@gopherbot
Copy link
Contributor Author

Change https://golang.org/cl/375719 mentions this issue: [internal-branch.go1.17-vendor] http2: prioritize RST_STREAM frames in random write scheduler

gopherbot pushed a commit to golang/net that referenced this issue Jan 6, 2022
…n random write scheduler

The http2 random write scheduler should not queue RST_STREAM
frames with the DATA frames, and instead treat them as control frames.

There can be deadlock situations if data frames block the queue,
because if the sender wants to close the stream it sends an RST frame,
but if the client is not draining the queue, the RST frame is stuck
and the sender is not able to finish.

For golang/go#49741
Updates golang/go#49921

Change-Id: I0940a76d1aad95f1c4d3856e4d79cf5ce2a78ff2
Reviewed-on: https://go-review.googlesource.com/c/net/+/367154
Trust: Dave Cheney <dave@cheney.net>
Reviewed-by: Damien Neil <dneil@google.com>
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit 04296fa)
Reviewed-on: https://go-review.googlesource.com/c/net/+/375719
Run-TryBot: Carlos Amedee <carlos@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
@gopherbot
Copy link
Contributor Author

Change https://golang.org/cl/375814 mentions this issue: [release-branch.go1.17] net/http: update bundled golang.org/x/net/http2

@cagedmantis
Copy link
Contributor

This backport has been approved as it is a serious issue without a workaround.

@cagedmantis cagedmantis added the CherryPickApproved Used during the release process for point releases label Jan 6, 2022
@gopherbot gopherbot removed the CherryPickCandidate Used during the release process for point releases label Jan 6, 2022
gopherbot pushed a commit that referenced this issue Jan 6, 2022
Pull in approved backports to golang.org/x/net/http2:

    21a9c9c http2: prioritize RST_STREAM frames in random write scheduler

By doing:

    $ go get -d golang.org/x/net@internal-branch.go1.17-vendor
    $ go mod tidy
    $ go mod vendor
    $ go generate -run=bundle std

Fixes #49921

Change-Id: I04739a30d84a8ae449374eca8bb11c7d2d215ad9
Reviewed-on: https://go-review.googlesource.com/c/go/+/375814
Run-TryBot: Carlos Amedee <carlos@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Carlos Amedee <carlos@golang.org>
@gopherbot
Copy link
Contributor Author

Closed by merging dbdf055 to release-branch.go1.17.

fedosgad pushed a commit to fedosgad/oohttp that referenced this issue Jun 22, 2022
…n random write scheduler

The http2 random write scheduler should not queue RST_STREAM
frames with the DATA frames, and instead treat them as control frames.

There can be deadlock situations if data frames block the queue,
because if the sender wants to close the stream it sends an RST frame,
but if the client is not draining the queue, the RST frame is stuck
and the sender is not able to finish.

For golang/go#49741
Updates golang/go#49921

Change-Id: I0940a76d1aad95f1c4d3856e4d79cf5ce2a78ff2
Reviewed-on: https://go-review.googlesource.com/c/net/+/367154
Trust: Dave Cheney <dave@cheney.net>
Reviewed-by: Damien Neil <dneil@google.com>
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit 04296fa82e83b85317bd93ad50dd00460d6d7940)
Reviewed-on: https://go-review.googlesource.com/c/net/+/375719
Run-TryBot: Carlos Amedee <carlos@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
@golang golang locked and limited conversation to collaborators Jan 6, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
CherryPickApproved Used during the release process for point releases FrozenDueToAge
Projects
None yet
Development

No branches or pull requests

4 participants