Return an ETag identifying the client state on PUTs OR the rewritten content

Note: this is debatable, its not a strict request. Just for tracking of the
issue which was raised in Issue 12.

Related to Issue 18.

---snip---
> In fact, it is generally required for CalDAV servers to
> rewrite resources

Yes, that is a very similiar but slightly different issue. To
properly support rewriting in a safe way, the server would need
to return an ETag in the PUT response which identifies the
state of the resource submitted by the client. The client can
then perform a GET If-None-Match: PUT-ETag. If the server
returns a 304, it did NOT rewrite the content. If it returns a
2xx, it DID rewrite the content (and returns it PLUS the new
etag identifying the rewritting content).

But this raises discussions similiar to the Location ones. (Issue 18)

> I think you should reasonably expect server rewriting and
> relocating to continue, and periodically sync with the server
> (use PROPFIND depth=1) on all events in the collection.

This needs to be done _immediatly_ (either PROPFIND, GET and/or
REPORT-uid). Otherwise the client can't do subsequent writes
properly (the cache will point to a different URL, and then
potentially recreate the resource [yes, there is the UID
restriction which is partial protection]).
---snap---

I'm not sure whether its specified what the ETag in a PUT response
identifies. I think there is no agreement on it.

But the sequence would basically go like that:

  Client: PUT Content
  Server: 204 No Content, ETag: 12345

  Client: GET If-None-Match: 12345
  Server: 200 OK, Etag: 67890, Content (Server did rewrite 
                                   [or another user modified])
or
  Server: 304 Not Modified (Server did not rewrite)

And even better option would be to return 200 OK in the PUT and embed the
rewritten content in the PUT response (plus the ETag of the rewritten content).
I think this should be OK by the HTTP spec and is actually the perfect
setup. Fully safe from a transaction point of view, and requires no
additional HTTP requests.

Original issue reported on code.google.com by helge.h...@googlemail.com on 11 Aug 2008 at 8:40

medabdellahi / google-caldav-issues

Return an ETag identifying the client state on PUTs OR the rewritten content #19