x/net/http2: http.Server.WriteTimeout does not fire if the http2 stream's window is out of space. #49741

davecheney · 2021-11-23T02:06:44Z

What version of Go are you using (`go version`)?

$ go version 1.17.3

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (`go env`)?

What did you do?

package main

import (
	"io"
	"log"
	"net/http"
	"net/http/httptest"
	"strings"
	"time"
)

func handler(w http.ResponseWriter, r *http.Request) {
	data := strings.Repeat("x", 1<<16)
	tick := time.NewTicker(1 * time.Millisecond)
	defer tick.Stop()
	for {
		select {
		case <-tick.C:
			n, err := io.WriteString(w, data)
			log.Printf("wrote %d, err %v", n, err)
			if err != nil {
				return
			}
		case <-r.Context().Done():
			log.Printf("context cancelled")
			return
		}
	}
}

func main() {
	sv := httptest.NewUnstartedServer(http.HandlerFunc(handler))
	sv.EnableHTTP2 = true
	sv.Config.WriteTimeout = 1 * time.Second
	sv.StartTLS()

	resp, err := sv.Client().Get(sv.URL + "/")
	if err != nil {
		log.Fatal(err)
	}
	defer resp.Body.Close()

	select {} // block forever
}

This program creates a HTTP2 service which fills the HTTP/2 stream's response window by failing to consume any data from the response body. The write deadline should fire after 1 second and terminate the response. It does not.

What did you expect to see?

If the tick rate is increased to 100ms, the write timeout fires

(~/devel/http2bug) % go run .
2021/11/23 13:03:12 wrote 65536, err <nil>
2021/11/23 13:03:13 wrote 65536, err <nil>
2021/11/23 13:03:13 wrote 65536, err <nil>
2021/11/23 13:03:13 wrote 65536, err <nil>
2021/11/23 13:03:13 wrote 65536, err <nil>
2021/11/23 13:03:13 wrote 65536, err <nil>
2021/11/23 13:03:13 wrote 65536, err <nil>
2021/11/23 13:03:13 wrote 65536, err <nil>
2021/11/23 13:03:13 wrote 65536, err <nil>
2021/11/23 13:03:13 wrote 4096, err http2: stream closed

What did you see instead?

If tick is left at 1 ms, permitting it to fill the stream's response window, handler blocks, no timeout is reported on either the client or the server side.

(~/devel/http2bug) % go run .
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>
2021/11/23 13:03:56 wrote 65536, err <nil>

// output stops

/cc @neild @bradfitz

The text was updated successfully, but these errors were encountered:

aojea · 2021-11-24T14:43:59Z

If tick is left at 1 ms, permitting it to fill the stream's response window, handler blocks, no timeout is reported on either the client or the server side.

interestingly, you can increase the tick until 15ms, it always block when it writes 64 blocks. If I divide by 2 the data data := strings.Repeat("x", 1<<15) it blocks when it writes 128 blocks if I tick in less than 7 ms

It seems that something blocks when it has 64x65536 = 4MB, the bytes.Buffer?

go/src/bytes/buffer.go

Line 16 in 2ebe77a

const smallBufferSize = 64

davecheney · 2021-11-24T19:33:44Z

It seems that something blocks when it has 64x65536 = 4MB, the bytes.Buffer?

I believe that is the stream's window, as the client is not reading from the response stream it will not be triggering window updates to refill the window

aojea · 2021-11-25T19:03:12Z

@davecheney you are right, I've found the problem, is the stream window as you say

I'll send a patch so you can review

gopherbot · 2021-11-25T22:13:25Z

Change https://golang.org/cl/367154 mentions this issue: http2: RST_STREAM frames write priority

davecheney · 2021-12-01T22:31:43Z

@mknyszek I see you're landing a bunch of HTTP/2 fixes for 1.17.4. Could I ask you to consider this one for inclusion. Thank you.

mknyszek · 2021-12-01T22:40:55Z

@davecheney It might be a little late, we just met today to go over the backport issues to cherry-pick, and generally we only include those whose changes have already landed at tip. I think this should probably wait until the next minor release (that is in a month), but I'll see if @neild has any opinions on this. If it's severe enough it may warrant trying to get it in this one.

neild · 2021-12-01T22:55:08Z

Nice catch for a subtle bug. CL looks good to me, but as this fix is just landing and the bug is long-standing I think it's too late for 1.17.4.

davecheney · 2021-12-02T00:34:28Z

Thanks for considering it. I can stick with x/net/http2 til the next minor ships

mknyszek · 2021-12-02T04:53:52Z

(Moving to backlog as part of triage, just because this isn't a new issue in 1.18.)

mknyszek · 2021-12-02T04:57:03Z

(Er, actually it seems like y'all plan to fix this relatively soon, I'm gonna guess in 1.19? Moving to 1.19 milestone.)

davecheney · 2021-12-02T05:48:06Z

@mknyszek i'd prefer to not have to wait til 1.19 for this to be backported to net/http. Is it possible this could be included in the next x/net/http2 backport into 1.17.6, or at least 1.18.1?

I agree this this is an existing issue that has been broken for a long time, but equally, its been broken for a long time and has quite serious impacts for anyone attempting to expose a Go http/2 service on the open internet. We have pretty good control of the client side on copilot, and still see requests with a 10 second WriteTimeout hang for the better part of an hour because of this issue.

mknyszek · 2021-12-02T14:57:32Z

@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 · 2021-12-02T14:57:48Z

Backport issue(s) opened: #49921 (for 1.17), #49922 (for 1.18).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases.

toothrot · 2021-12-15T21:39:53Z

@neild @mknyszek @davecheney Because this issue was fixed before go1.18rc1, and we want it in the 1.18.1 release, we should actually just update the vendored x/net in the go repo for 1.18, and ensure this is part of the 1.18 release.

In that case, the steps would be:

backport to 1.16 (in addition to the 1.17 backport)
close x/net/http2: http.Server.WriteTimeout does not fire if the http2 stream's window is out of space. [1.18 backport] #49922
update the vendored x/net on go's master branch

cagedmantis · 2022-01-05T17:44:57Z

@gopherbot Please open a backport issue for Go 1.16.

cagedmantis · 2022-01-05T19:26:27Z

Backport issue(s) opened: #50449 (for 1.16)

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases.

gopherbot · 2022-01-05T23:25:53Z

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

gopherbot · 2022-01-05T23:27:31Z

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

…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#50449 Change-Id: I0940a76d1aad95f1c4d3856e4d79cf5ce2a78ff2 Reviewed-on: https://go-review.googlesource.com/c/net/+/367154 Trust: Dave Cheney <[email protected]> Reviewed-by: Damien Neil <[email protected]> Trust: Damien Neil <[email protected]> Run-TryBot: Damien Neil <[email protected]> TryBot-Result: Gopher Robot <[email protected]> (cherry picked from commit 04296fa) Reviewed-on: https://go-review.googlesource.com/c/net/+/375718 Run-TryBot: Carlos Amedee <[email protected]> Trust: Dmitri Shuralyov <[email protected]>

…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 <[email protected]> Reviewed-by: Damien Neil <[email protected]> Trust: Damien Neil <[email protected]> Run-TryBot: Damien Neil <[email protected]> TryBot-Result: Gopher Robot <[email protected]> (cherry picked from commit 04296fa) Reviewed-on: https://go-review.googlesource.com/c/net/+/375719 Run-TryBot: Carlos Amedee <[email protected]> Trust: Dmitri Shuralyov <[email protected]>

FrankReh · 2022-01-29T17:43:09Z

The original test case given above still does not timeout after a second when building with go1.17.6, even though the commit that fixed golang.org/x/net was cherry picked.

I've seen the failure with both Darwin and Linux builds.

I can get the test case to timeout correctly if I use the latest golang.org/x/net package and modify main with the ConfigureServer call:

package main

import (
	"io"
	"log"
	"net/http"
	"net/http/httptest"
	"strings"
	"time"

	"golang.org/x/net/http2"
)

func handler(w http.ResponseWriter, r *http.Request) {
	data := strings.Repeat("x", 1<<16)
	tick := time.NewTicker(1 * time.Millisecond)
	defer tick.Stop()
	for {
		select {
		case <-tick.C:
			n, err := io.WriteString(w, data)
			log.Printf("wrote %d, err %v", n, err)
			if err != nil {
				return
			}
		case <-r.Context().Done():
			log.Printf("context cancelled")
			return
		}
	}
}

func main() {
	sv := httptest.NewUnstartedServer(http.HandlerFunc(handler))
	err := http2.ConfigureServer(sv.Config, &http2.Server{})
	if err != nil {
		log.Fatal(err)
	}
	sv.EnableHTTP2 = true
	sv.Config.WriteTimeout = 1 * time.Second
	sv.StartTLS()

	resp, err := sv.Client().Get(sv.URL + "/")
	if err != nil {
		log.Fatal(err)
	}
	defer resp.Body.Close()

	select {} // block forever
}

The go.mod:

module main

go 1.17

require golang.org/x/net v0.0.0-20220127200216-cd36cc0744dd

require golang.org/x/text v0.3.7 // indirect

But what's interesting is I can also get the hung write to timeout correctly without the golang.org/x/net package, but I had
to modify the go net package source (~~and rebuild go~~ probably didn't have to rebuild go, the std packages aren't built into the binary) to export the http2ConfigureServer function. By calling that in place of the http2:ConfigureServer call above, that also causes the blocked write to timeout correctly.

ianlancetaylor · 2022-01-30T01:17:01Z

Reopening. CC @neild

aojea · 2022-01-30T19:11:35Z

I've found the problem, there is an inconsistency on the default writeScheduler chosen:

The fix for the WriteTimeout issue was in the RandomWriteScheduler, that is chosen if you use configureTransport directly

go/src/net/http/h2_bundle.go

Lines 4114 to 4118 in a5c0b19

    
           if s.NewWriteScheduler != nil { 
        
           	sc.writeSched = s.NewWriteScheduler() 
        
           } else { 
        
           	sc.writeSched = http2NewRandomWriteScheduler() 
        
           }

However, when http2 is configured automatically, it uses a different WriteScheduler, that may have the same issue than the other WriteScheduler

go/src/net/http/server.go

Lines 3296 to 3311 in a5c0b19

    
           // onceSetNextProtoDefaults configures HTTP/2, if the user hasn't 
        
           // configured otherwise. (by setting srv.TLSNextProto non-nil) 
        
           // It must only be called via srv.nextProtoOnce (use srv.setupHTTP2_*). 
        
           func (srv *Server) onceSetNextProtoDefaults() { 
        
           	if omitBundledHTTP2 || godebug.Get("http2server") == "0" { 
        
           		return 
        
           	} 
        
           	// Enable HTTP/2 by default if the user hasn't otherwise 
        
           	// configured their TLSNextProto map. 
        
           	if srv.TLSNextProto == nil { 
        
           		conf := &http2Server{ 
        
           			NewWriteScheduler: func() http2WriteScheduler { return http2NewPriorityWriteScheduler(nil) }, 
        
           		} 
        
           		srv.nextProtoErr = http2ConfigureServer(srv, conf) 
        
           	} 
        
           }

So, I think that there are 2 things to fix here:

a bug in NewPriorityWriteScheduler
consistency defaulting the WriteScheduler

@neild @ianlancetaylor I can take on this if you want.

gopherbot · 2022-01-30T20:11:13Z

Change https://golang.org/cl/382014 mentions this issue: http2: prioritize RST_STREAM frames in priority write scheduler

aojea · 2022-01-30T20:28:22Z

Submitted a patch for fixing the scheduler http2NewPriorityWriteScheduler bug.

What should be the default scheduler http2NewPriorityWriteScheduler() or http2NewRandomWriteScheduler()

EDIT

It seems it has to be the PriorityWriteScheduler based on #18318

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. Fixes golang/go#49741 Change-Id: I0940a76d1aad95f1c4d3856e4d79cf5ce2a78ff2 Reviewed-on: https://go-review.googlesource.com/c/net/+/367154 Trust: Dave Cheney <[email protected]> Reviewed-by: Damien Neil <[email protected]> Trust: Damien Neil <[email protected]> Run-TryBot: Damien Neil <[email protected]> TryBot-Result: Gopher Robot <[email protected]>

The http2 priority 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. Fixes golang/go#49741 Signed-off-by: Antonio Ojea <[email protected]> Change-Id: Ie4462603380039f7aba8f701fe810d1d84376efa Reviewed-on: https://go-review.googlesource.com/c/net/+/382014 Reviewed-by: Ian Lance Taylor <[email protected]> Reviewed-by: Damien Neil <[email protected]> Run-TryBot: Dave Cheney <[email protected]> TryBot-Result: Gopher Robot <[email protected]>

…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 <[email protected]> Reviewed-by: Damien Neil <[email protected]> Trust: Damien Neil <[email protected]> Run-TryBot: Damien Neil <[email protected]> TryBot-Result: Gopher Robot <[email protected]> (cherry picked from commit 04296fa82e83b85317bd93ad50dd00460d6d7940) Reviewed-on: https://go-review.googlesource.com/c/net/+/375719 Run-TryBot: Carlos Amedee <[email protected]> Trust: Dmitri Shuralyov <[email protected]>

…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#50449 Change-Id: I0940a76d1aad95f1c4d3856e4d79cf5ce2a78ff2 Reviewed-on: https://go-review.googlesource.com/c/net/+/367154 Trust: Dave Cheney <[email protected]> Reviewed-by: Damien Neil <[email protected]> Trust: Damien Neil <[email protected]> Run-TryBot: Damien Neil <[email protected]> TryBot-Result: Gopher Robot <[email protected]> (cherry picked from commit 04296fa) Reviewed-on: https://go-review.googlesource.com/c/net/+/375718 Run-TryBot: Carlos Amedee <[email protected]> Trust: Dmitri Shuralyov <[email protected]>

The http2 priority 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. Fixes golang/go#49741 Signed-off-by: Antonio Ojea <[email protected]> Change-Id: Ie4462603380039f7aba8f701fe810d1d84376efa Reviewed-on: https://go-review.googlesource.com/c/net/+/382014 Reviewed-by: Ian Lance Taylor <[email protected]> Reviewed-by: Damien Neil <[email protected]> Run-TryBot: Dave Cheney <[email protected]> TryBot-Result: Gopher Robot <[email protected]>

Rajalakshmi-Girish mentioned this issue Nov 24, 2021

[Flaky Test][sig-node] kubernetes-unit-test TestHTTP1DoNotReuseRequestAfterTimeout is being Flaky kubernetes/kubernetes#106569

Closed

davecheney added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Nov 24, 2021

davecheney added this to the Go1.18 milestone Nov 24, 2021

davecheney removed the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Dec 1, 2021

mknyszek added the NeedsFix The path to resolution is known, but the work has not been done. label Dec 2, 2021

mknyszek modified the milestones: Go1.18, Backlog Dec 2, 2021

mknyszek modified the milestones: Backlog, Go1.19 Dec 2, 2021

gopherbot mentioned this issue Dec 2, 2021

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 mentioned this issue Dec 2, 2021

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

Closed

gopherbot closed this as completed in golang/net@04296fa Dec 8, 2021

cagedmantis mentioned this issue Jan 5, 2022

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

Closed

dmitshur modified the milestones: Go1.19, Go1.18 Jan 5, 2022

ianlancetaylor reopened this Jan 30, 2022

heschi modified the milestones: Go1.18, Go1.19 Mar 15, 2022

gopherbot closed this as completed in golang/net@c186220 May 31, 2022

golang locked and limited conversation to collaborators May 31, 2023

gopherbot added the FrozenDueToAge label May 31, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

x/net/http2: http.Server.WriteTimeout does not fire if the http2 stream's window is out of space. #49741

x/net/http2: http.Server.WriteTimeout does not fire if the http2 stream's window is out of space. #49741

davecheney commented Nov 23, 2021 •

edited

Loading

aojea commented Nov 24, 2021 •

edited

Loading

davecheney commented Nov 24, 2021 •

edited

Loading

aojea commented Nov 25, 2021

gopherbot commented Nov 25, 2021

davecheney commented Dec 1, 2021

mknyszek commented Dec 1, 2021 •

edited

Loading

neild commented Dec 1, 2021

davecheney commented Dec 2, 2021

mknyszek commented Dec 2, 2021

mknyszek commented Dec 2, 2021 •

edited

Loading

davecheney commented Dec 2, 2021 •

edited

Loading

mknyszek commented Dec 2, 2021

gopherbot commented Dec 2, 2021

toothrot commented Dec 15, 2021

cagedmantis commented Jan 5, 2022

cagedmantis commented Jan 5, 2022

gopherbot commented Jan 5, 2022

gopherbot commented Jan 5, 2022

FrankReh commented Jan 29, 2022 •

edited

Loading

ianlancetaylor commented Jan 30, 2022

aojea commented Jan 30, 2022

gopherbot commented Jan 30, 2022

aojea commented Jan 30, 2022 •

edited

Loading

x/net/http2: http.Server.WriteTimeout does not fire if the http2 stream's window is out of space. #49741

x/net/http2: http.Server.WriteTimeout does not fire if the http2 stream's window is out of space. #49741

Comments

davecheney commented Nov 23, 2021 • edited Loading

What version of Go are you using (go version)?

Does this issue reproduce with the latest release?

What operating system and processor architecture are you using (go env)?

What did you do?

What did you expect to see?

What did you see instead?

aojea commented Nov 24, 2021 • edited Loading

davecheney commented Nov 24, 2021 • edited Loading

aojea commented Nov 25, 2021

gopherbot commented Nov 25, 2021

davecheney commented Dec 1, 2021

mknyszek commented Dec 1, 2021 • edited Loading

neild commented Dec 1, 2021

davecheney commented Dec 2, 2021

mknyszek commented Dec 2, 2021

mknyszek commented Dec 2, 2021 • edited Loading

davecheney commented Dec 2, 2021 • edited Loading

mknyszek commented Dec 2, 2021

gopherbot commented Dec 2, 2021

toothrot commented Dec 15, 2021

cagedmantis commented Jan 5, 2022

cagedmantis commented Jan 5, 2022

gopherbot commented Jan 5, 2022

gopherbot commented Jan 5, 2022

FrankReh commented Jan 29, 2022 • edited Loading

ianlancetaylor commented Jan 30, 2022

aojea commented Jan 30, 2022

gopherbot commented Jan 30, 2022

aojea commented Jan 30, 2022 • edited Loading

davecheney commented Nov 23, 2021 •

edited

Loading

What version of Go are you using (`go version`)?

What operating system and processor architecture are you using (`go env`)?

aojea commented Nov 24, 2021 •

edited

Loading

davecheney commented Nov 24, 2021 •

edited

Loading

mknyszek commented Dec 1, 2021 •

edited

Loading

mknyszek commented Dec 2, 2021 •

edited

Loading

davecheney commented Dec 2, 2021 •

edited

Loading

FrankReh commented Jan 29, 2022 •

edited

Loading

aojea commented Jan 30, 2022 •

edited

Loading