requests.Session doesn't properly handle closed keep-alive sessions

[JonathanLynch]

BPO	33620
Nosy	@serhiy-storchaka

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2018-05-23.17:41:25.907>
created_at = <Date 2018-05-23.16:46:21.440>
labels = ['type-bug', 'library']
title = "requests.Session doesn't properly handle closed keep-alive sessions"
updated_at = <Date 2018-05-23.17:41:25.906>
user = 'https://bugs.python.org/JonathanLynch'

bugs.python.org fields:

activity = <Date 2018-05-23.17:41:25.906>
actor = 'Jonathan Lynch'
assignee = 'none'
closed = True
closed_date = <Date 2018-05-23.17:41:25.907>
closer = 'Jonathan Lynch'
components = ['Library (Lib)']
creation = <Date 2018-05-23.16:46:21.440>
creator = 'Jonathan Lynch'
dependencies = []
files = []
hgrepos = []
issue_num = 33620
keywords = []
message_count = 3.0
messages = ['317425', '317427', '317432']
nosy_count = 2.0
nosy_names = ['serhiy.storchaka', 'Jonathan Lynch']
pr_nums = []
priority = 'normal'
resolution = 'third party'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue33620'
versions = ['Python 3.6']

[JonathanLynch]

When a server reaps a keep-alive session it sends a FIN packet to the client. Normally, requests handles this fine and rebuilds the session on the next request. However, there is an edge case involving network latency that is not properly handled:

If python sends a request at roughly the same time as the server closes the session, then the server will send a RST (as the session is closed). Python receives this RST on what it thought was a valid session and throws an error:

requests.exceptions.ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response',))

The reason I consider this a bug is because python received the FIN packet before it received the RST. As a result, it shouldn't be surprised when the connection is subsequently aborted. It is an edge case, but the client has enough information available to it that it could have handled it correctly.

The workaround is to set max_retries on the Session via an HTTPAdaptor, but I believe the correct behavior when the FIN is received is to rebuild the session and re-send any requests that were in-flight (rather than throwing an error). Requests correctly handles the FIN packet if there are no in-flight requests, but if there are in-flight requests it ignores it and instead throws an error.

[serhiy-storchaka]

requests is a third-party package. Can you reproduce your issue with the standard Python library?

[JonathanLynch]

Ah, I'm sorry! I'll open the report over there, closing this.