-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[#9653] Make HTTP/2 server connections not timeout after a minute #1158
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for jumping on this! 💯 tests and comments.
I've left some comments, but given the severity of this bug, please don't let addressing them prevent you from merging this fix!
src/twisted/protocols/policies.py
Outdated
@@ -712,6 +712,22 @@ def resetTimeout(self): | |||
if self.__timeoutCall is not None and self.timeOut is not None: | |||
self.__timeoutCall.reset(self.timeOut) | |||
|
|||
|
|||
def cancelTimeout(self): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the one hand this is a new public API that isn't necessary; passing None
to setTimeout
will cancel the timeout.
On the other hand, setTimeout
's API is bad enough that a core committer with deep Twisted experience didn't see it, and I didn't either until I went hunting. Maybe if we'd had this method in the first place we wouldn't have had this bug!
So I think I'm +0.75 for adding this method.
Should we deprecate the cancellation feature of setTimeout
?
src/twisted/web/test/test_http.py
Outdated
cancelled. | ||
""" | ||
@attr.s | ||
class FakeDelayedCall(object): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not construct a real DelayedCall?
Also, it'd be nice if this implemented IDelayedCall
and there were a verifyObject
call somewhere.
@@ -2947,6 +2947,9 @@ def dataReceived(self, data): | |||
# itself if possible. | |||
self._channel._networkProducer.unregisterProducer() | |||
|
|||
# Cancel the old channel's timeout. | |||
self._channel.cancelTimeout() | |||
|
|||
transport = self._channel.transport |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about removing the transport from the original channel as well, for a bit of defensive programming?
Bumping this because as @markrwilliams said, it is indeed fairly severe... |
Ticket: https://twistedmatrix.com/trac/ticket/9653