Clients populate calendar collections with calendar object resources. The URL for each calendar object resource is entirely arbitrary and does not need to bear a specific relationship to the calendar object resource's iCalendar properties or other metadata. New calendar object resources MUST be created with a PUT request targeted at an unmapped URI. A PUT request targeted at a mapped URI updates an existing calendar object resource.
When servers create new resources, it's not hard for the server to choose an unmapped URI. It's slightly tougher for clients, because a client might not want to examine all resources in the collection and might not want to lock the entire collection to ensure that a new resource isn't created with a name collision. However, there is an HTTP feature to mitigate this. If the client intends to create a new non-collection resource, such as a new VEVENT, the client SHOULD use the HTTP request header "If-None-Match: *" on the PUT request. The Request-URI on the PUT request MUST include the target collection, where the resource is to be created, plus the name of the resource in the last path segment. The "If-None-Match: *" request header ensures that the client will not inadvertently overwrite an existing resource if the last path segment turned out to already be used.
>> Request <<
PUT /home/lisa/calendars/events/qwue23489.ics HTTP/1.1 If-None-Match: * Host: cal.example.com Content-Type: text/calendar Content-Length: xxxx
BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example Corp.//CalDAV Client//EN BEGIN:VEVENT UID:20010712T182145Zfirstname.lastname@example.org DTSTAMP:20060712T182145Z DTSTART:20060714T170000Z DTEND:20060715T040000Z SUMMARY:Bastille Day Party END:VEVENT END:VCALENDAR
>> Response <<
HTTP/1.1 201 Created Content-Length: 0 Date: Sat, 11 Nov 2006 09:32:12 GMT ETag: "123456789-000-111"
The request to change an existing event is the same, but with a specific ETag in the "If-Match" header, rather than the "If-None- Match" header.
As indicated in Section 3.10 of [RFC2445], the URL of calendar object resources containing (an arbitrary set of) calendaring and scheduling information may be suffixed by ".ics", and the URL of calendar object resources containing free or busy time information may be suffixed by ".ifb".