I'm confused about the current state of server timeouts being exposed by go1.17 for HTTP2 connections.
With a TLS/HTTP2 server that is streaming responses to a client that has fetched and is in a readable stream loop, the stream stays up and the server sends data whenever it wants - for example once a second. My current tests are sending updates every second, like the http2 clockstream demo from years ago. But I also want to expose this server to the internet and enable the http.Server WriteTimeout property to guard against a client not consuming TCP data at normal pace. Right now it seems the http.Server WriteTimeout property is causing a timeout on the stream to expire, even though the client is consuming the TCP data with no delays. So the WriteTimeout property is acting as an HTTP2 stream timeout, having little to do with the actual write (and flush). Is there an established way of getting both? I have access to the underlying net.Conn. I've seen go1.18 will likely provide access to the underlying net.Conn and I've cherry picked that for my go1.17 build already. I guess I'm also confused by the rationale for the said timeout for HTTP2 connections. It doesn't seem like an underlying limitation of Linux that the timeout has to be applied to a request completing when some would just want individual writes or flushes to have timeouts. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/26a67d12-cd1c-4b30-85cb-fa39c0c2a0fcn%40googlegroups.com.
