net/http: the comment of Server.IdleTimeout doesn't describe its behavior correctly #32053
Comments
Thanks. That does look like a mistake. |
@bradfitz can I send a CL for this? |
@jamdagni86, sure? But I haven't looked at it yet. It might be a code change or a doc fix. I don't know. So you should investigate and your commit message should explain. |
@bradfitz the current documentation is slightly incorrect. The earlier comment was
This got changed to the current version in this CL as a fix for this. The correct sequence is this. At the end of the current request, it sets deadline for IdleTimeout or ReadTimeout, whichever is non zero. At the beginning of the next request, it sets deadline for ReadHeaderTimeout or ReadTimeout, whichever is non zero. The missing piece in the documentation is the last part where ReadTimeout is considered yet again. In case IdleTimeout and ReadHeaderTimeout are both zeros and ReadTimeout is non zero, it sets up two timeouts with ReadTimeout duration and if none of the former two are zeros, it would end up setting two timeouts - IdleTimeout & ReadHeaderTimeout. I'm not sure if this was the intended behaviour. And assuming that the code is working as intended, I guess it is enough if we revert the IdleTimeout documentation to the previous version and add a line in the ReadHeaderTimeout to mention that it falls back to ReadTimeout in case the former is zero. Please let me know if this sounds good; I will send a CL. |
> IdleTimeout is the maximum amount of time to wait for the > next request when keep-alives are enabled. If IdleTimeout > is zero, the value of ReadTimeout is used. If both are > zero, there is no timeout. This got changed to the current version in this CL - https://go-review.googlesource.com/46434 as a fix for golang#20383. The correct sequence is this. At the end of the current request, it sets a deadline for IdleTimeout or ReadTimeout, whichever is non zero. At the beginning of the next request, it sets a deadline for ReadHeaderTimeout or ReadTimeout, whichever is non zero. The missing piece in the documentation is the latter. Fixes golang#32053
Change https://golang.org/cl/178337 mentions this issue: |
Maybe we could simply merge the patch and close the issue? |
Thank you for filing this issue @spacewander and for working on the CL @jamdagni86, plus thanks for the tag @agnivade! So from my reading of the current situation, I agree with @spacewander's comments:
and if s.idleTimeout()'s result (either s.IdleTimeout or s.ReadTimeout) is non-zero, we'll set the ReadDeadline on the underlying s.c.rwc and then peek(4), thus wait a max deadline as per Lines 1913 to 1919 in 06e34e5 and at the end remove that deadline. If either of s.IdleTimeout and s.ReadTimeout are not set, there won't be a deadline as we see on line 1919 Line 1919 in 06e34e5
Thus this warrants just a documentation change the doc for Server.IdleTimeout from Lines 2525 to 2527 in 06e34e5 to // next request when keep-alives are enabled. If IdleTimeout
// is zero, the value of ReadTimeout is used. If both are
// zero, there is no timeout. as well as update the doc for ReadHeaderTimeout to include falling back to ReadTimeout as @jamdagni86 has presented in their CL. |
> IdleTimeout is the maximum amount of time to wait for the > next request when keep-alives are enabled. If IdleTimeout > is zero, the value of ReadTimeout is used. If both are > zero, there is no timeout. This got changed to the current version in this CL - https://go-review.googlesource.com/46434 as a fix for golang#20383. The correct sequence is this. At the end of the current request, it sets a deadline for IdleTimeout or ReadTimeout, whichever is non zero. At the beginning of the next request, it sets a deadline for ReadHeaderTimeout or ReadTimeout, whichever is non zero. The missing piece in the documentation is the latter. Fixes golang#32053
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you see instead?
The comment of
IdleTimeout
says:https://github.com/golang/go/blob/master/src/net/http/server.go#L2524
However, after reading:
https://github.com/golang/go/blob/master/src/net/http/server.go#L3008
https://github.com/golang/go/blob/master/src/net/http/server.go#L1913
It seems that
IdleTimeout
doesn't take account ofReadHeaderTimeout
. Maybe I have missed something?The text was updated successfully, but these errors were encountered: