Open GitRowin opened 3 years ago
Hello. I don't understand your issue. I do, but I need more context. How do you set the ReadTimeout? In fasthttp or in the http2 library?
server := &fasthttp.Server{
ReadTimeout: 5 * time.Second,
Handler: ServeHTTP,
}
tlsConfig := &tls.Config{...}
http2.ConfigureServerAndConfig(server, tlsConfig)
listener, err := net.Listen("tcp4", "0.0.0.0:443")
if err != nil {
panic(err)
}
tlsListener := tls.NewListener(listener, tlsConfig)
err = server.Serve(tlsListener)
if err != nil {
panic(err)
}
Are you sure you are using http2? The library doesn't have any kind of read timeout. It doesn't care about timeouts really.
Yes, I'm sure.
Chrome:
Firefox:
Also, when I remove http2.ConfigureServerAndConfig(server, tlsConfig)
so it uses HTTP/1.1, it doesn't happen.
Here is the problem. Is not related to http2. Is an issue related to fasthttp.
I'll let the issue open here, and create a new one in fasthttp
@GitRowin can you check the version v0.2.4? Thanks
Connections are no longer being closed 5 seconds after connecting, but timeouts don't work at all now.
Maybe you're misunderstanding the problem.
ReadTimeout documentation:
ReadTimeout is the amount of time allowed to read
the full request including body. The connection's read
deadline is reset when the connection opens, or for
keep-alive connections after the first byte has been read.
Before v0.2.4, the read deadline was only reset when the connection opened, and now read and write timeouts are disabled completely. The expected behavior is the deadline resetting after the first byte of a HTTP request has been read.
What are you expecting then? After 5 seconds return an error to the client? Which kind of error? An http2 specific code or an HTTP status?
Try the version v0.2.5. I just send a cancel and remove the stream when the stream times out
The timeout is not working:
Server:
server := &fasthttp.Server{
ReadTimeout: 5 * time.Second,
Handler: ServeHTTP,
}
Also:
Servers are encouraged to maintain open connections for as long as possible but are permitted to terminate idle connections if necessary. When either endpoint chooses to close the transport-layer TCP connection, the terminating endpoint SHOULD first send a GOAWAY (Section 6.8) frame so that both endpoints can reliably determine whether previously sent frames have been processed and gracefully complete or terminate any necessary remaining tasks.
From: https://httpwg.org/specs/rfc7540.html#n-connection-management
Oke, makes sense. I'll take a look later
Hello,
After taking a look I still don't understand what's the issue. I don't know if you mean if a request needs to timeout or the connection needs to be closed after the ReadTimeout.
About the first one: I am working on an implementation for that (so same as fasthttp does Maximum duration for full response reading (including body).
)
About the second one: Connections are going to be active as long as they reply to ping messages from the server.
@GitRowin can you try version v0.3.1?
Keep-Alive connections get closed
ReadTimeout
seconds after connecting, even if they're actively being used to make HTTP requests:I'm using a
ReadTimeout
of 5 seconds. As you can see, 5 and 10 seconds after the initial request, the browser has to connect again.I believe this issue is basically the same as this one: https://github.com/golang/go/issues/16450