You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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.
Activity
sheshtawy commentedon Sep 30, 2019
I'd love to help with this if no one is
lovelydinosaur commentedon Dec 11, 2019
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.