Re: p1 7.2.4: retrying requests

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?


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


> For this reason it makes it hard to multiplex incoming requests over
> existing connections, because in theory a POST will always need a fresh
> new connection to the server, or will have to silently retry (forbidden)
> or to make use of some Expect tricks as I described in the first mail.
> Maybe there are other cleaner ways but I haven't found them right now.

Agreed. 


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

Thanks,

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

Received on Tuesday, 7 June 2011 07:03:12 UTC