Re: Does idempotence include the response codes?

On 2013-10-16 11:52, Nicolas Mailhot wrote:
>
> Le Mer 16 octobre 2013 11:47, Nicolas Mailhot a écrit :
>>
>> 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)
>
> Or to put it more succinctly an idempotent method must not trigger by
> itself a state change server-side. Is that clear and short enough for
> everyone?

Clear, short, and incorrect.

You are confusing idempotency with safeness.

Best regards, Julian

Received on Wednesday, 16 October 2013 10:12:44 UTC