Re: Does idempotence include the response codes?

Le Mer 16 octobre 2013 06:00, Willy Tarreau a écrit :

> The main idea behind idempotence is to know whether or not a client can
> safely resend a request that failed because of network errors. For
> example,
> sending a request over an established connection may result in an error if
> the server decided to close at the same time. But the client has no way to
> know if the request was considered or not, so it must resend it. If the
> previous request was correctly processed, the second one may return an
> error, but it's the client's job to handle this. I can give you an example
> here with unix commands :

I'm not sure I agree with the example, I've seen cases where idempotence
is a much stronger property.

For example, since GET is idempotent, that means a malware checker service
can replay (before or after the browser) get requests to check if the
result is dangerous or not. And it does not affect the result the browser
will receive on its own GET.

If you say mv is an example of idempotence, that means all the broken
websites that transform GETs into implicit POSTs are right, since the
first GET destroys the result the following GET could expect.

IMHO idempotence means a replay of the same command will give the same
result, baring errors, website reorganisations, and data changes (when the
request exposes some dynamic data store)


Nicolas Mailhot

Received on Wednesday, 16 October 2013 09:47:59 UTC