[Ietf-caldav] Fwd: Summary of ETag related issues in RFC2518bis
helge.hess at opengroupware.org
Thu Dec 22 02:58:30 PST 2005
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
>> 2-by) 419 Conflict (etag changed, some other user/client/server
>> changed the
> > ...
> 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)
> 2-by) 304 Not Modified (etag did not change)
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.
More information about the Ietf-caldav