- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 3 Feb 2017 17:15:29 +1100
- To: Matt Menke <mmenke@google.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
Thanks for that. If you can, a pull request on the doc would be wonderful; you can capture the detail better than I. See: https://github.com/mnot/I-D/blob/gh-pages/httpbis-retry/draft.md Cheers, > On 2 Feb 2017, at 8:30 am, Matt Menke <mmenke@google.com> wrote: > > A bit more elaboration on Chrome's behavior: > > I didn't see it mentioned in the draft, but the reason we retry is that any time we reuse a socket, there's a race - servers timeout sockets after some period, and we don't know what that period is. So we could be retrying at the same time the server is closing the socket on us. > > We'll retry on a "stale" socket (one that was connected and then sat in a socket pool, with or without being used first). So if we fully preconnect to a server before there's a connection request, we consider the socket stale,if we've used a socket before, it's stale, or if we created a socket to service a request, but the request was cancelled, and then the socket connected and was returned to the socket pool, it's stale. > > We only retry if we've received no response from a server, or if we get a failure while still sending the request (i.e., if we're in the middle of sending the request on error, we'll retry, even if there's data on the socket from the server, since we don't bother to check for that). > > We also only retry on certain errors (reset, connection closed, connection aborted (Which is a weird error from the OS of some sort), H2 ping failure, H2 server refusing the stream, QUIC handshake error. This probably doesn't include all the errors that we could get racily while reusing a socket (TCP ping timeout, for instance?). > > > On Wed, Feb 1, 2017 at 3:26 AM, Mark Nottingham <mnot@mnot.net> wrote: > FYI; fairly minor update. Would love to hear what people think about the various suggested paths forward. > > Cheers, > > > >> Begin forwarded message: >> >> From: internet-drafts@ietf.org >> Subject: New Version Notification for draft-nottingham-httpbis-retry-01.txt >> Date: 1 February 2017 at 7:25:43 pm AEDT >> To: "Mark Nottingham" <mnot@mnot.net> >> >> >> A new version of I-D, draft-nottingham-httpbis-retry-01.txt >> has been successfully submitted by Mark Nottingham and posted to the >> IETF repository. >> >> Name: draft-nottingham-httpbis-retry >> Revision: 01 >> Title: Retrying HTTP Requests >> Document date: 2017-02-01 >> Group: Individual Submission >> Pages: 18 >> URL: https://www.ietf.org/internet-drafts/draft-nottingham-httpbis-retry-01.txt >> Status: https://datatracker.ietf.org/doc/draft-nottingham-httpbis-retry/ >> Htmlized: https://tools.ietf.org/html/draft-nottingham-httpbis-retry-01 >> Diff: https://www.ietf.org/rfcdiff?url2=draft-nottingham-httpbis-retry-01 >> >> Abstract: >> HTTP allows requests to be automatically retried under certain >> circumstances. This draft explores how this is implemented, >> requirements for similar functionality from other parts of the stack, >> and potential future improvements. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> > > -- > Mark Nottingham https://www.mnot.net/ > > -- Mark Nottingham https://www.mnot.net/
Received on Friday, 3 February 2017 06:16:01 UTC