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

Re: Does idempotence include the response codes?

From: cowwoc <cowwoc@bbs.darktech.org>
Date: Wed, 16 Oct 2013 01:53:32 -0400
Message-ID: <525E29DC.3070104@bbs.darktech.org>
To: Willy Tarreau <w@1wt.eu>
CC: 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>
On 16/10/2013 1:13 AM, Willy Tarreau wrote:
> 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
>

     That's very useful information. All too often I read sections in 
the spec that describe WHAT the implementation should do without an 
explanation of WHY. The why is important because without this context 
the developer can't decide what is reasonable behavior for their 
specific application. In the past I've always erred on the side of 
strictness (retaining idempotent information forever) for fear of doing 
the wrong thing. I don't know how/whether you can address this in the 
spec, but it would be nice if this bit of context was added ("you only 
need to keep idempotence information around long enough for your clients 
retry failed operations" as opposed to covering use-cases like permalinks).

     Anyway, thanks again. I've found this discussion very helpful for 
my own development.

Gili
Received on Wednesday, 16 October 2013 05:54:01 UTC

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