Re: p1 7.2.4: retrying requests

On 04/06/2011, at 3:32 PM, Willy Tarreau wrote:

> If a connection dies during
> an idempotent request, it's easy to retry it. POSTs are also sent over those
> connections, at the risk of loosing them and having to retry them. In my
> opinion, adding an "Expect: 100-Continue" header to those requests is enough
> to ensure they are sent over a valid connection. But the issue remains when
> there is an empty body with the POST, because if we set the Expect header
> with the empty body, we'll cause a deadlock (or the server might notice it
> and proceed anyway).
> So for empty POST requests, we still have no means of testing the connection
> before reusing it. Or maybe by using chunked encoding and sending the 0<CRLF>
> after 100 is received, provided the server accepts chunked encoded requests ?
> In fact, connection pooling becomes so much common nowadays that I think we
> should ensure any implementation gets all corner cases right than just saying
> they can't replay a POST over a broken connection, because they'll do stupid
> or dangerous things to get it working anyway (and if you knew the number of
> people I encounter who are amazed that a POST must not be blindly replayed...).

I don't think we can generalise your pattern using Expect/continue, because clients can't always be sure that the next hop is 1.1.

However, we could make it clear that it's OK for clients to retry non-idempotent requests when they have some sort of agreement (in-band, e.g., a protocol extension like POE, or out-of-band).

Would that be workable for you?


Mark Nottingham

Received on Sunday, 5 June 2011 01:07:18 UTC