Re: Does idempotence include the response codes?

On Wed, Oct 16, 2013 at 12:37:51AM -0400, cowwoc wrote:
> 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.

I'm not suggesting anything, it's to the application to decide this based
on what it's trying to achieve. I mean the idempotence is made to cover
the issues that require a retransmit. If your application requires slower
retransmits (eg: you pilot a robot on mars from the earth), then probably
5 minutes will not be enough.

Willy

Received on Wednesday, 16 October 2013 05:14:02 UTC