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

[Julian Reschke]

Helge Hess wrote:
> 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.

OK. If by "419 Conflict" you mean "412 Precondition Failed", then this 
may work :-)

Best regards, Julian