Re: p1 7.2.4: retrying requests

On 07/06/2011, at 3:31 PM, Willy Tarreau wrote:
>> 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?
> I'm not sure what those sort of agreement means, and in fact I'm not even
> sure that we have solid ways to cover all situations. Still, some products
> already do that (possibly at some risks, I don't know). I regularly get
> strong requests from users to implement the same features in haproxy, and
> while I agree it makes sense to implement those, my reading of the spec
> does not make me 100% comfortable with it, because I think that at some
> times we have to ignore some important rules.

Well, a gateway / reverse proxy (like haproxy) is implicitly a device that has an agreement with the server; the protocol it speaks can be HTTP/1.1, but because it's a gateway, it can be something else too. We need to make this more apparent generally, I think.

> My real concern is to ensure that such an implementation does not lie to
> the user, and for instance that if such a gateway is installed in front
> of a server and it decides to automatically retry a request over a new
> connection, the visitor will not receive two products in his mail box
> and will not have is account debitted twice.

Right. If it's vanilla HTTP, and the request is a POST, it can't retry it. If it's not HTTP (or HTTP++), it has some other kind of agreement covering this situation.

> The only "reliable" solution I have against this is for the gateway to
> break the client connection if the server connection dies, and let the
> client retry. While this can work for the 2nd and subsequent requests
> from the client, if it does this for the first request of the client's
> connection, the client will display an error and will not retry. So as
> you see, a gray area remains (at least for me) here.

Why is it different for the first request?


Mark Nottingham

Received on Tuesday, 7 June 2011 06:09:20 UTC