Re: Does idempotence include the response codes?

On Wed, Oct 16, 2013 at 11:47:28AM +0200, Nicolas Mailhot wrote:
> 
> 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.

GET can retrieve a lot of dynamic information, here it's not about
idempotence since we're suggesting the contents may vary over time. It's
more about cahceability here.

> 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)

But that does not last forever. This is the difference between theory and
reality. When you let your ___domain expire and it's acquired by a squatter,
your site will return something different whatever you decide. And the GET
you did when you owned the ___domain will definitely return something different
from what the squatter will return.

Regards,
Willy

Received on Wednesday, 16 October 2013 10:02:58 UTC