- From: Matt Menke <mmenke@google.com>
- Date: Wed, 1 Feb 2017 16:30:25 -0500
- To: Mark Nottingham <mnot@mnot.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAEK7mvq3T9euSgu7zvAirwwVye8De8FY9h2bhXWpebYwj=ff0w@mail.gmail.com>
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/ > >
Received on Wednesday, 1 February 2017 21:30:59 UTC