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