[Ietf-caldav] Fwd: Summary of ETag related issues in RFC2518bis

[Helge Hess]

On 22. Dez 2005, at 06:58 Uhr, Julian Reschke wrote:
>> Basically the transaction looks like:
>> 1-a)  PUT /blah.ics
>> 1-b)  205, etag ABC
>> 2-a)  GET /blah.ics, if-match: etag=ABC
>> 2-bx) new content
>> or
>> 2-by) 419 Conflict (etag changed, some other user/client/server  
>> changed the
>>       item)
> > ...
>
> Me confused. Shouldn't that be...:
>
> 1-a)  PUT /blah.ics
> 1-b)  205, etag ABC
> 2-a)  GET /blah.ics, if-none-match: etag=ABC
> 2-bx) new content (200, etag did change)
> or
> 2-by) 304 Not Modified (etag did not change)
> ?

No! :-)

The 1-b 205 says that the server changed the content and the etag  
represents the state of this content which in turn is a result of 1- 
a. What 2-a does is (_reliably_) fetching the result of 1-a which is  
unknown to the client at this point.

If the if-match fails, the client knows that there is an actual  
conflict (someone else wrote to the same resource in the meantime).


Your sequence is the one to be used for refreshes if the server does  
not change the content, that is, if it returns a 201 or 200 in step 1-b.

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org