[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