W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: Does idempotence include the response codes?

From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
Date: Wed, 16 Oct 2013 11:47:28 +0200
Message-ID: <c99067224ea5cf499f5cb84488df3463.squirrel@arekh.dyndns.org>
To: "Willy Tarreau" <w@1wt.eu>
Cc: "cowwoc" <cowwoc@bbs.darktech.org>, "Martin Thomson" <martin.thomson@gmail.com>, "Mark Nottingham" <mnot@mnot.net>, "Julian Reschke" <julian.reschke@gmx.de>, "HTTP Working Group" <ietf-http-wg@w3.org>

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)

Regards,

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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:18 UTC