On 2017-11-13 21:16, André Carvalho wrote: > I also ran into this issue recently. I think this is a dup > of https://github.com/golang/go/issues/21204. This issue can be > mitigated if you set some reasonable ReadTimeout on the http.Server, > which causes the http.StateNew connection to timeout (a connection stays > in this state until something is read from it).
But a globally reasonable ReadTimeout is not always possible. For some HTTP endpoints you might need to handle request which take a long time - longer than you are willing to wait for a clean shutdown. I have applications where I need to be able to handle req. taking over 1 minute to complete, but I need a shutdown timeout of 6s max. This problem also appears when TLS handshakes take too long to complete. AFAIK it's not possible to insert a server-side TLSHanshakeTimeout in a Go HTTP server without exploiting that connections register in ConnState StateNew before the TLS handshake and goes into StateActive after. I ended up solving the problem by making a Listener wrapper which returned connections with a possible time.After triggered callback. It's not pretty, ... it has to use unsafe to work around that calling close on a *tls.Conn will only close it when the TLSHandshake is done (but calling it on the underlying net.Conn will do what you want) and that you at this point cannot get to the underlying net.Conn from a *tls.Conn - but in lack of a server-side TLSHandshakeTimeout it works. https://github.com/One-com/gone/blob/master/netutil/reaper/conn.go#L42 /Peter -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
