W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2011

Re: p1 7.2.4: retrying requests

From: Willy Tarreau <w@1wt.eu>
Date: Wed, 8 Jun 2011 20:05:37 +0200
To: Mark Nottingham <mnot@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20110608180537.GA20655@1wt.eu>
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.

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:52 UTC