You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This happens because after the timeout, TimeoutHandler.ServeHTTP doesn't wait for the inner handler to complete, and anything on panicChan is lost.
I understand that waiting for the inner handler would partly defeat the purpose of TimeoutHandler. If waiting is not acceptable, perhaps the docs should warn about dropped panics.
This happens because timeoutWriter.Push may call the underlying Push after or concurrently with the completion of TimeoutHandler.ServeHTTP (after which http2responseWriter.rws is set to nil).
Of course the panic is not logged for the reason already mentioned.
The text was updated successfully, but these errors were encountered:
A ResponseWriter may not be used after the Handler.ServeHTTP method has returned.
Any caller of ServeHTTP takes this rule for granted and may break in unexpected ways if it's not respected (for http2responseWriter, it leads to dereferencing a pointer that is concurrently set to nil).
Calling the Push overlay after timeout is nothing abnormal, in fact there's no way to make sure it won't happen.
It should be safe to use the overlay ResponseWriter for as long as the corresponding handler is running, OTOH the underlying one has a different lifespan and is TimeoutHandler's responsibility.
Concurrency aside, panic equals interrupted goroutine (I fail to see how it doesn't make a big difference in a non-fatal condition), but in this case it's worse because no clue is left behind! (No logs, see first part of the issue.)
There's also another concurrency issue: timeoutWriter.Push calls the underlying Push while the other goroutine calls the underlying Write/WriteHeader. Even if this is safe for http2responseWriter, it may break for a custom ResponseWriter (not required to be safe for concurrent use).