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

Julian Reschke julian.reschke at gmx.de
Wed Dec 21 21:58:46 PST 2005


Helge Hess wrote:
> On 22. Dez 2005, at 00:51 Uhr, Mike Shaver wrote:
>> On 12/21/05, Helge Hess <helge.hess at opengroupware.org> wrote:
>>> Yes, definitely. Any server which modifies content will be required
>>> to respond with a 205 (with an etag?!).
>> I don't think they should be required to send an ETag.
> 
> The etag is a must-have for consistent updates. If the server doesn't 
> send an etag, the client can't know whether its a regular server side 
> update or a conflict on the subsequent GET (eg a recreation of the 
> resource under the same URL).
> 
> 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)

?



More information about the Ietf-caldav mailing list