Re: p1 7.2.4: retrying requests

On Fri, Jun 24, 2011 at 04:25:10PM +1000, Mark Nottingham wrote:
> 
> On 09/06/2011, at 4:05 AM, Willy Tarreau wrote:
> 
> > I'm really embarrassed about how to proceed from now on. As a gateway
> > implementer, I expected to be able to impolitely shut the client-side
> > connection upon server-side errors and let the client decide whether
> > to retry or not. After all, unexpected server-side closures should not
> > be *that* common. But given that existing browsers will not retry, even
> > if we clarify the spec to ensure that new versions get this right in the
> > future, intermediaries will still have to support existing products.
> 
> I think we should figure out whether we need consistent behaviour regarding retries between products, or it's just something that we allow implementations to do, based on the known semantics of some request methods.
> 
> I tend to view it in the latter way; given that you can never guarantee that clients won't see failure, retries are just an optimisation, not something we need full interop on. 

Retries on persistent connections should remain mandatory, as there is
no way to know that the connection is closing while sending a request.

> This includes user agents as well as intermediaries, of course. In fact, I know of some UAs who definitely don't retry, and don't want to (because of the added complexity it, as well as the view that they're a "low-level" HTTP implementation).

There is still a minor difference between UAs and intermediaries : the UA
holds all the request if it wants to retry, while the intermediary will
always have size limitations preventing it from resending some reqeusts
(especially the ones with a body).

> > For instance, I've seen people
> > who were completely at ease with rewriting requests to replace POST with
> > GET to workaround nasty issues (!), I'd like to ensure nobody gets this
> > idea in order to force an intermediary to blindly retry non-idempotent
> > request when it prefers to close and rely on the client to retry !
> > 
> > I have not checked how various products handle the situation right now,
> > but I'm already afraid of what we could encounter :-/
> > 
> > I'm willing to propose something if it can be useful, but I'm not sure I'm
> > able to cover all corner cases, so I will need several iterations with
> > suggestions from more experienced people if we want to get something that
> > can be put in the draft.
> 
> My current thinking is to life the retry-specific text out of 7.1.4 into a new section, possibly adding advice (along the lines you mention). 
> 
> I'm inclined to propose removing section 7.2.4 altogether, because it's very specific to a certain kind of request (one with a body where the connection drops to a proxy or HTTP/1.0 server, when there isn't an Expect: 100-continue header), and doing so can result in the server seeing a non-idempotent request being repeated multiple times, which is bad.
> 
> I realise that's a fairly big change. Is anyone aware of any actual implementation of 7.2.4?

It is possible that some of them exist, it's been noted as 8.2.4 in RFC2616
for the last 12 years :-/

But I agree with you that it covers such a specific case that it could be
fold into a more general case.

Also I suddenly have an idea : why shouldn't we recommend that an
intermediary which must retry but can't would send a 5xx status
explicitly asking the client to retry ? It could be a lot cleaner
than closing and expecting the client to retry on a failed first
request, and even if the client does not handle this specific 5xx
status, at least it would get an indication about what went wrong.
Maybe it could be a 503 + Retry-After.

Regards,
Willy

Received on Saturday, 25 June 2011 06:19:10 UTC