Re: New Version Notification for draft-nottingham-httpbis-retry-01.txt

[Willy Tarreau <[e-mail]>]

On Tue, Feb 07, 2017 at 02:35:32PM +1100, Mark Nottingham wrote:
> 
> > On 7 Feb 2017, at 8:04 am, Alex Rousskov <[e-mail]> 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.

I like a lot the way it's presented in Squid's doc above. It's indeed
much better to enumerate a number of conditions that should prevent a
retry than to suggest when it's possible. As seen above, that makes
the list much easier to understand (shorter and simpler conditions)
and easier to adapt to other products.

HAProxy currently doesn't implement retry if at least one byte was sent.
The main reason is that once forwarded, these bytes are lost, but I
contemplated the possibility to pin and rewind the buffer to deal with
failures on persistent shared connections (by default we don't share them).
I've come to a number of conditions (much less) and some are common with
Squid's, so it's encouraging to read this :-)

I tend to think that just like we audited many implementations when
trying to redefine the state of deployed stacks for RFC723x, by
enumerating what various implementations do combined with their successes
or failures, we may end up with MAY and SHOULD that can be considered as
safe guidelines for future implementations, just because existing code
has had to adapt to what these current implementations do as well.

Cheers,
Willy