Set Location Header in PUTs which move a resource (to a new relative URL)

[GoogleCodeExporter]

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

---snip---
> but I can't find anything in the CalDAV spec that forbids servers
> from relocating resources.

It is allowed but has major issues when the 'location' header is
unsupported (and 'location' in PUT responses has 'issues' too).
All WebDAV operations are transactionally safe when used with
proper If headers.

A common workaround is to search using a uid-match REPORT after the
PUT. BUT this isn't transactionally save anymore. The client can't
know whether the resource was modified in the meantime:

  Client A: PUT resource.ics[uid=123]
  Client B: PUT resource-moved.ics[uid=123]
  Client C: REPORT uid=123
  => Client A can't know the record was changed by Client B

That issue gets bigger the more clients work on the same collection,
race conditions are not that unusual as one might think.

Note: transactional safety with relocating servers can be
ensured by using 'location'.
---snap---

With Location+PUT its just one, single and transactionally safe operation:

  Client A: PUT resource.ics
  Server:   201 Created, Location: 28372-28372.ics

The client can update the location in its cache and direct subsequent
operations on the resource to the proper URL.

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

[GoogleCodeExporter]

Ah, forgot: as mentioned in Issue 12 it would be best if Google would work 
around the
whole issue by storing the URL choosen by the client in the event/contact 
record.
It needs to track an additional unique ID (in addition to the iCal UID), but it 
would
be much bette for WebDAV interoperability.

Original comment by helge.h...@googlemail.com on 11 Aug 2008 at 8:32

[GoogleCodeExporter]

Todays deployment returns a Location header with status 201 after a PUT.

So I suppose we can close this issue.

Original comment by helge.h...@googlemail.com on 5 Oct 2008 at 11:20

[GoogleCodeExporter]

And it's broken again. After recent update on Google's CalDAV side (I cannot 
think of any other change) the Location header is not returned, thus the client 
doesn't know where just added event came. This is a regression from previous 
behaviour and breaks 3rd party clients which depend on the Location header.

Could you refix this, please?

Original comment by milan.c...@gmail.com on 16 Apr 2012 at 5:50