Skip to content

Handle 408-response connection closes. #146

Closed

Description

@lovelydinosaur

PR #145 ensures that we're checking for disconnections when we reacquire connections, by using the StreamReader.at_eof interface.

However @njsmith points out, that's not always quite sufficient. #143 (comment)

There's StreamReader.at_eof, but that will fail if the HTTP server is polite and sends a 408 Request Timeout before it closes the connection. I think the best you can do is:

def asyncio_stream_is_readable(stream):
     return stream._buffer or stream._eof

or else giving up on the Stream API and using protocols/transports directly.

Either of those would be do-able.

How common is 408 usage in the wild - are there example URLs we can confirm against?

Also worth noting that there's also always going to be a race network condition where we start getting a 408 response that was about to be sent, just as we're in the process of sending out a new request.

Activity

  1. sheshtawy commented on Sep 30, 2019

    @sheshtawy

    I'd love to help with this if no one is

  2. lovelydinosaur commented on Dec 11, 2019

    @lovelydinosaur
    MemberAuthor

    Closing this in favour of #34.

    For robustness we ought to be closing keep-alive connections after a timeout period.

    That doesn't prevent 408 cases from occuring entirely, but it would substantially mitigate against it, and is the sensible case for us to prioritize here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions