Re: p1 7.2.4: retrying requests

Hi Mark,

On Tue, Jun 07, 2011 at 05:02:45PM +1000, Mark Nottingham wrote:
> On 07/06/2011, at 4:39 PM, Willy Tarreau wrote:
> 
> > Because RFC2616 expects a client to retry a request over a keep-alive
> > connection that has just died, and my observations is that various browsers
> > get it right.
> 
> Are you referring to the requirement in p1 7.1.4, p1 7.2.4, or something else here?

In RFC2616 it was 8.1.4, but yes it's basically the same.

> > However, when it's the first request over this connection,
> > they know that the closed connection is not a keep-alive timeout and it
> > indicates a server error. As such, all browsers I have tested immediately
> > report a connection error if the connection is broken during the first
> > request.
> 
> I don't see a requirement to do that anywhere in the spec; if anything, 7.1.4 SHOULD-requires clients to retry in this circumstance, unless the request is non-idempotent.
> 
> Are you reading those requirements as only applying to the second or later request on a connection because 7.1.4 falls under a section called "Persistent Connections"? If so, I don't think that's an intentional constraint on those requirements, and I'd be interested to hear what others think.

I'm indeed reading it that way and the fact that browser's behaviours I've
observed seems to be similar makes me think I was not the only one. It's
very possible too that since handling retries is not the easiest thing to
do, most implementations only started to care about that with persistent
connections, and only implemented it in this case after reading section
8.1 of 2616 (persistent conns).

> > And the fact that I see this problem as complex while most people I talk
> > to just shake their shoulders saying things starting with "bah you just
> > have to ..." makes me think that it's not necessarily obvious to get the
> > various corner cases from a quick reading of the spec (or that I'm really
> > dumb, that's possible too).
> 
> OK. Can you suggest things to add to or take away from the spec as it sits?

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.

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

Cheers,
Willy

Received on Wednesday, 8 June 2011 18:06:07 UTC