Re: Does idempotence include the response codes?

On 16/10/2013 12:00 AM, Willy Tarreau wrote:
> I've read your comment about renaming a company and the risk of reusing
> the same name for a new company later. I think you're having your mind
> confused because of the difference between "network time" and "human time".
>
> 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 :
>
>    $ mv a b
>    ... phone rings ...
>    ... Hmmm where was I. Ah, I was about to rename "a" to "b"
>    $ mv a b
>    mv: cannot stat `a': No such file or directory
>    ... Ah yes, I already did it, let's go on with next operation.
>
> In my opinion it is reasonable to think that during this short retransmit
> time, the company name "A" will not be reused to name a new company. And
> if it's not true (eg: an application that many people are using in parallel
> for a lot of administrative stuff), then it means that the company name is
> not a safe key to proceed with operations, so your application needs to use
> a permanent ID :
>
>     GET /id-by-name/A
>
>     { "owner" : "smith", "location" : "NY", "id" : "12345" }
>
>     PUT /rename-id/12345
>
>     { "name" : "B" }
>
> But as you can see, the protocol in its current state offers everything
> needed to handle this correctly. However it will not make an unsafe
> application suddenly safe. The application needs to be safe in its
> sequences and use the protocol correctly.
>
> Hoping this helps,
> Willy
>

     Good example. When you talk about "network time" versus "human 
time" are you implying that the server should return 410 GONE and 307 
Temporary Redirect for a short period of time (say 5 minutes) to enable 
clients to retry on delete/rename operations, but after 5 minutes it can 
begin returning 404 at the old address? That seems like a very 
reasonable compromise to me. I just wanted to make sure that it's what 
you meant.

Thanks,
Gili

Received on Wednesday, 16 October 2013 04:38:20 UTC