-
Notifications
You must be signed in to change notification settings - Fork 7
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
Improve http.Client connection handling #1581
base: main
Are you sure you want to change the base?
Changes from 3 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -513,6 +513,10 @@ actor Client(cap: net.TCPConnectCap, scheme: str, address: str, port: ?int, tls_ | |
if "connection" in r.headers and r.headers["connection"] == "close": | ||
# Is this really the right thing to do here? If the client | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Add a TODO entry here. We should inspect our queue, i.e. _on_response list to see if there is more stuff. I'm also thinking like we can maybe have some basic heuristics, like when we create a http.Client the first time we obviously connect directly then we expect to run at least one query. Maybe we should not reconnect after that (in case of HTTP / 1.0 or not having persistent in later HTTP versions) until there is a second query. Now if we see a second query we can assume "there are multiple requests" and thus reconnect directly after the 2nd and subsequent requests. WDYT? |
||
# does not make a new request we just reconnected for nothing! | ||
# TODO: inspect the _on_response queue to see if there are more requests | ||
# TODO: for HTTP/1.0 do not reconnect right after the first | ||
# request, wait until the 2nd query and then assume there | ||
# will be more. | ||
_log.debug("Closing TCP connection due to header: Connection: close", None) | ||
_conn_reconnect() | ||
if len(_on_response) == 0: | ||
|
@@ -553,13 +557,10 @@ actor Client(cap: net.TCPConnectCap, scheme: str, address: str, port: ?int, tls_ | |
await async tcp_conn.write(data) | ||
elif tls_conn is not None: | ||
await async tls_conn.write(data) | ||
except RuntimeError as exc: | ||
except ConnectionError as exc: | ||
# HTTP/1.0 servers close the connection after each request by default | ||
if "bad file descriptor" in str(exc) or "bad stream" in str(exc): | ||
_log.debug("TCP connection closed, reconnecting", {"error": str(exc)}) | ||
_conn_reconnect() | ||
else: | ||
_on_con_error(str(exc)) | ||
_log.debug("TCP connection closed, reconnecting", {"error": str(exc)}) | ||
_conn_reconnect() | ||
|
||
# HTTP methods | ||
def get(path: str, headers: dict[str, str], on_response: action(Client, Response) -> None): | ||
|
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 hadn't actually looked much at how Python does things beyond looking at OSError. I see now that it subclasses things quite nicely. Should we not just copy that whole thing verbatim? Like it feels like a better starting point than starting from scratch. In particular, in this case for the error you later raise, I think it's a BrokenPipeError.
We probably want to consider changing the
__init__
method of our OSError so we can take errno and stuff like that, again just like in Python. Without default args it'll be a little fiddly, but that's OK I guess.