#297: p1 7.2.4: retrying requests

On 25/06/2011, at 4:18 PM, Willy Tarreau wrote:

> 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.

They're SHOULD NOTs now, and I suspect that many implementations don't do it.


>> 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 :-/

Yes, but if it's problematic for interop we can change it. 

What do other folks think about this? Personally, I'm concerned about clients retrying POSTs; I think this will surprise many folks server-side, and can cause some problems. Semantically, POST (for example) is very clearly non-idempotent, and retrying under these circumstances opens a race condition.


> 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.


I think 504 is more appropriate for a proxy, and the ability to retry is implicit in its semantics (I don't know of any software that automatically retries based upon a Retry-After header). 

Effectively, this is what happens already (after all, you have to give up retrying *sometime*), but I don't see any harm in spelling that out.

I've created <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/297> to track this.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

Received on Sunday, 26 June 2011 06:49:34 UTC