-
-
Notifications
You must be signed in to change notification settings - Fork 764
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
Ensure HTTP connections are closed in case of data-less TCP pings #1244
Conversation
Seems like there's more subtlety to it than I thought. |
@@ -137,6 +137,9 @@ def data_received(self, data): | |||
except httptools.HttpParserUpgrade: | |||
self.handle_upgrade() | |||
|
|||
if data == b"" and not self.transport.is_closing(): | |||
self.transport.close() | |||
|
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.
if data == b"": | |
self.on_response_complete() |
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.
seems like this pass tests and fix the issue if I'm correct
@@ -79,8 +79,7 @@ def retrieve_exception(task: asyncio.Task) -> None: | |||
# yet: all data that the client might have already sent since the connection has | |||
# been established is in the `_buffer`. | |||
data = reader._buffer # type: ignore | |||
if data: | |||
protocol.data_received(data) | |||
protocol.data_received(data) |
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.
protocol.data_received(data) | |
if isinstance(protocol, H11Protocol): | |
if data: | |
protocol.data_received(data) | |
elif isinstance(protocol, HttpToolsProtocol): | |
protocol.data_received(data) |
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.
I guess we should be moving that if data:
check to H11Protocol
instead, then.
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.
the thing is that this b""
case is already handled by h11 in it's receive_data
we use in our protocol's data_received
see https://gitlab.com/kalilinux/packages/python-h11/-/blob/kali/master/h11/_connection.py#L303-348
so I dont know
elif event_type is h11.ConnectionClosed: | ||
if not self.transport.is_closing(): | ||
self.transport.close() | ||
break |
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.
elif event_type is h11.ConnectionClosed: | |
if not self.transport.is_closing(): | |
self.transport.close() | |
break |
Replaced by #1332 |
Closes #1226
Completes #869 (released in 0.14.0) with a missing branch: it is possible that
data
beb""
, e.g. if the client is a health checker that uses empty TCP pings to verify a service is up. As shown in #1226, this may be the case in k8s environments for example. In that case, we should be mindful of closing thetransport
, i.e. closing the connection (hence the connection/memory leak reported in #1226).To reproduce before/after, consider this server:
And this "ping as fast as you can" client:
Before the change, the Python process memory would go up indefinitely, at a pace that varies from system to system. Eg I start from 16MB and get to >20MB and up in just a few seconds.
After the change, memory remains stable. Eg I see a stable 17.1 MB despite the client hitting the server with pings.