- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 7 Feb 2017 14:35:32 +1100
- To: Alex Rousskov <rousskov@measurement-factory.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
> On 7 Feb 2017, at 8:04 am, Alex Rousskov <rousskov@measurement-factory.com> wrote: > > On 02/01/2017 01:26 AM, Mark Nottingham wrote: >> FYI; fairly minor update. Would love to hear what people think about the >> various suggested paths forward. > > FWIW, Squid mind-boggling algorithm for retries is partially summarized > at > http://wiki.squid-cache.org/SquidFaq/InnerWorkings?highlight=%28reforward%29#When_does_Squid_re-forward_a_client_request.3F > > Your draft already mentions a single Squid decision point, but the > actual logic is a lot more complex than the draft currently implies. > Some of that complexity is Squid's fault, as the source code comment you > quoted illustrates, but a lot of it is genuine. Ah, I should have remembered that one; thanks. I've added a link. > Recommending a unified (but necessarily parameterized) approach to > retries would be useful for future implementors, but I suspect that > doing so properly would take too much time while oversimplifying the > situation would not help much. Just cataloging various retry factors to > consider may be very helpful on its own, even if you then suggest > nothing more than "keep these factors in mind when implementing retries". That's a reasonable outcome. Some folks might want more, e.g., a recommended algorithm that itself isn't mandatory for all implementations (yet). Whether we go that far (and when) is still an open question, I think. Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Tuesday, 7 February 2017 03:36:04 UTC