Re: p1 7.2.4: retrying requests

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. 

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


> So maybe we could move the "retry" text out of the "persistent" section,
> but we'll still have to ensure there is a working solution for today. If
> it's not that much complicated, we could suggest it as a hint, just as
> we have in 7.2.4 about the exponential backoff. After all, the more hints
> we give for complex situations, the more traps will be avoided and the
> less ugly workarounds will be deployed.

I think we're on the same page.


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

Cheers,


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

Received on Friday, 24 June 2011 06:25:49 UTC