Try out our new RRULE tool for creating RRULE compatible strings.

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:20010712T182145Z-123401@example.com
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".

This document was automatically converted to XHTML using an RFC to HTML converter with the original text document at the Internet Engineering Task Force web site at ietf.org .  The original text document should be referred to if there are any errors or discrepancies found in this document.

Need to test your iCalendar feeds?

The iCalendar Validator provides developers and testers a method to validate their iCalendar feeds, which can take data from either a URL, file or text snippet and compare it against the RFC 5545 specification.  We believe we have one of the best iCalendar validation tools available on the internet. More information about the validator can be found here.