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

Re: Does idempotence include the response codes?

From: Willy Tarreau <w@1wt.eu>
Date: Wed, 16 Oct 2013 12:03:28 +0200
To: Nicolas Mailhot <nicolas.mailhot@laposte.net>
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>
Message-ID: <20131016100328.GD31029@1wt.eu>
On Wed, Oct 16, 2013 at 11:52:49AM +0200, 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?

Yes it can trigger a state change. But it will not trigger another state
change if done *again*.

Willy
Received on Wednesday, 16 October 2013 10:03:57 UTC

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