Bug#899406: requests.Session doesn't properly handle closed keep-alive sessions

2018-05-29 Thread Jonathan Lynch
Thank you for putting it in the right place Daniele. I added more detail on
github, as requested.

On Mon, May 28, 2018 at 9:16 PM, Daniele Tricoli  wrote:

> forwarded 899406 https://github.com/requests/requests/issues/4664
> thanks
>
> Hello Jonathan,
> thanks for your report!
>
> On Wednesday, May 23, 2018 10:16:57 PM CEST Jonathan Lynch wrote:
> > Package: python-requests
> > Version: 2.18.4
> [CUT detailed description]
>
> I forwarded the issue upstream since it's not Debian specific. Do you have
> a
> test that is able to reproduce systematically the issue? If yes can you
> attach
> on upstream bug tracker?
>
> Kind regards,
>
> --
>  Daniele Tricoli 'eriol'
>  https://mornie.org


Bug#899406: requests.Session doesn't properly handle closed keep-alive sessions

2018-05-28 Thread Daniele Tricoli
forwarded 899406 https://github.com/requests/requests/issues/4664
thanks

Hello Jonathan,
thanks for your report!

On Wednesday, May 23, 2018 10:16:57 PM CEST Jonathan Lynch wrote:
> Package: python-requests
> Version: 2.18.4
[CUT detailed description]

I forwarded the issue upstream since it's not Debian specific. Do you have a 
test that is able to reproduce systematically the issue? If yes can you attach 
on upstream bug tracker?

Kind regards,

-- 
 Daniele Tricoli 'eriol'
 https://mornie.org

signature.asc
Description: This is a digitally signed message part.


Bug#899406: requests.Session doesn't properly handle closed keep-alive sessions

2018-05-23 Thread Jonathan Lynch
Package: python-requests
Version: 2.18.4

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.