diff --git a/doc/dav_davfs2.md b/doc/dav_davfs2.md
deleted file mode 100644
index e4313e810..000000000
--- a/doc/dav_davfs2.md
+++ /dev/null
@@ -1,58 +0,0 @@
-**Installing The Cloud as a Filesystem on Linux**
-
-To install your cloud directory as a filesystem, you first need davfs2 installed. 99% of the time, this will be included in your distributions repositories. In Debian
-
-`apt-get install davfs2`
-
-If you want to let normal users mount the filesystem
-
-`dpkg-reconfigure davfs2`
-
-and select "yes" at the prompt.
-
-Now you need to add any user you want to be able to mount dav to the davfs2 group
-
-`usermod -aG davfs2 {{DesktopUser}}`
-
-Edit /etc/fstab
-
-`nano /etc/fstab`
-
-to include your cloud directory by adding
-
-`example.com/cloud/{{Username}} /mount/point davfs user,noauto,uid={{DesktopUser}},file_mode=600,dir_mode=700 0 1`
-
-Where {{Username}} is your username at your Red hub, example.com is the URL of your hub, /mount/point is the location you want to mount the cloud, and {{DesktopUser}} is the user you log in to one your computer. Note that if you are mounting as a normal user (not root) the mount point must be in your home directory.
-
-For example, if I wanted to mount my cloud to a directory called 'cloud' in my home directory, and my username was bob, my fstab would be
-
-`example.com/cloud/ /home/bob/cloud davfs user,noauto,uid=bob,file_mode=600,dir_mode=700 0 1`
-
-Now, create the mount point.
-
-`mkdir /home/bob/cloud`
-
-and also create a directory file to store your credentials
-
-`mkdir /home/bob/.davfs2`
-
-Create a file called 'secrets'
-
-`nano /home/bob/.davfs2/secrets`
-
-and add your cloud login credentials
-
-`example.com/cloud {{username}} {{password}}`
-
-
-Where {{username}} and {{password}} are the username and password for your hub.
-
-Don't let this file be writeable by anyone who doesn't need it with
-
-`chmod 600 /home/bob/.davfs2/secrets`
-
-Finally, mount the drive.
-
-`mount example.com/cloud/{{username}}`
-
-You can now find your cloud at /home/bob/cloud and use it as though it were part of your local filesystem - even if the applications you are using have no dav support themselves.
diff --git a/doc/dav_mount.bb b/doc/dav_mount.bb
index 85ca614f4..62edc09d0 100644
--- a/doc/dav_mount.bb
+++ b/doc/dav_mount.bb
@@ -25,14 +25,14 @@ Edit /etc/fstab
to include your cloud directory by adding
[code]
-example.com/cloud/ /mount/point davfs user,noauto,uid=<DesktopUser>,file_mode=600,dir_mode=700 0 1
+[baseurl]/cloud/ /mount/point davfs user,noauto,uid=<DesktopUser>,file_mode=600,dir_mode=700 0 1
[/code]
-Where example.com is the URL of your hub, /mount/point is the location you want to mount the cloud, and <DesktopUser> is the user you log in to one your computer. Note that if you are mounting as a normal user (not root) the mount point must be in your home directory.
+Where [baseurl] is the URL of your hub, /mount/point is the location you want to mount the cloud, and <DesktopUser> is the user you log in to one your computer. Note that if you are mounting as a normal user (not root) the mount point must be in your home directory.
For example, if I wanted to mount my cloud to a directory called 'cloud' in my home directory, and my username was bob, my fstab would be
-[code]example.com/cloud/ /home/bob/cloud davfs user,noauto,uid=bob,file_mode=600,dir_mode=700 0 1[/code]
+[code][baseurl]/cloud/ /home/bob/cloud davfs user,noauto,uid=bob,file_mode=600,dir_mode=700 0 1[/code]
Now, create the mount point.
@@ -49,7 +49,7 @@ Create a file called 'secrets'
and add your cloud login credentials
[code]
-example.com/cloud <username> <password>
+[baseurl]/cloud <username> <password>
[/code]
Where <username> and <password> are the username and password [i]for your hub[/i].
@@ -60,7 +60,7 @@ Don't let this file be writeable by anyone who doesn't need it with
Finally, mount the drive.
-[code]mount example.com/cloud[/code]
+[code]mount [baseurl]/cloud[/code]
You can now find your cloud at /home/bob/cloud and use it as though it were part of your local filesystem - even if the applications you are using have no dav support themselves.
diff --git a/doc/html/apw_2php_2style_8php.html b/doc/html/apw_2php_2style_8php.html
index d0a8f4f41..86e9a8376 100644
--- a/doc/html/apw_2php_2style_8php.html
+++ b/doc/html/apw_2php_2style_8php.html
@@ -260,7 +260,7 @@ Variables
'zid' string url - url to accept zid string zid - urlencoded zid string result - the return string we calculated, change it if you want to return something else
Those who require this feature will know what to do with it. Those who don't, won't. Eventually this functionality needs to be provided by a module such that permissions can be enforced. At the moment it's more of a proof of concept; but sufficient for our immediate needs.
diff --git a/include/conversation.php b/include/conversation.php
index d8d60ee10..b6db54943 100644
--- a/include/conversation.php
+++ b/include/conversation.php
@@ -1029,8 +1029,8 @@ function status_editor($a,$x,$popup=false) {
$plaintext = true;
- if(feature_enabled(local_user(),'richtext'))
- $plaintext = false;
+// if(feature_enabled(local_user(),'richtext'))
+// $plaintext = false;
$mimeselect = '';
if(array_key_exists('mimetype',$x) && $x['mimetype']) {
diff --git a/include/features.php b/include/features.php
index cc8d457bc..ef5923a01 100644
--- a/include/features.php
+++ b/include/features.php
@@ -38,7 +38,7 @@ function get_features() {
// Post composition
'composition' => array(
t('Post Composition Features'),
- array('richtext', t('Richtext Editor'), t('Enable richtext editor')),
+// array('richtext', t('Richtext Editor'), t('Enable richtext editor')),
array('preview', t('Post Preview'), t('Allow previewing posts and comments before publishing them')),
array('channel_sources', t('Channel Sources'), t('Automatically import channel content from other channels or feeds')),
array('content_encrypt', t('Even More Encryption'), t('Allow optional encryption of content end-to-end with a shared secret key')),
diff --git a/include/reddav.php b/include/reddav.php
index e03aa20ee..c9b238efb 100644
--- a/include/reddav.php
+++ b/include/reddav.php
@@ -1,281 +1,333 @@
-= 2.0
+ * requires PHP >= 5.4.
+ */
use Sabre\DAV;
require_once('vendor/autoload.php');
-
require_once('include/attach.php');
+
+/**
+ * @brief RedDirectory class.
+ *
+ * A class that represents a directory.
+ */
class RedDirectory extends DAV\Node implements DAV\ICollection, DAV\IQuota {
private $red_path;
private $folder_hash;
+ // @todo I think this is not used anywhere, we always strip '/cloud' and only use it in debug
private $ext_path;
private $root_dir = '';
private $auth;
private $os_path = '';
- function __construct($ext_path,&$auth_plugin) {
+ /**
+ * Sets up the directory node, expects a full path.
+ *
+ * @param string $ext_path a full path
+ * @param $auth_plugin
+ */
+ public function __construct($ext_path, &$auth_plugin) {
logger('RedDirectory::__construct() ' . $ext_path, LOGGER_DEBUG);
$this->ext_path = $ext_path;
- $this->red_path = ((strpos($ext_path,'/cloud') === 0) ? substr($ext_path,6) : $ext_path);
- if(! $this->red_path)
+ // remove "/cloud" from the beginning of the path
+ $this->red_path = ((strpos($ext_path, '/cloud') === 0) ? substr($ext_path, 6) : $ext_path);
+ if (! $this->red_path) {
$this->red_path = '/';
+ }
$this->auth = $auth_plugin;
$this->folder_hash = '';
-
$this->getDir();
- if($this->auth->browser)
+ if ($this->auth->browser) {
$this->auth->browser->set_writeable();
-
+ }
}
-
function log() {
logger('RedDirectory::log() ext_path ' . $this->ext_path, LOGGER_DATA);
logger('RedDirectory::log() os_path ' . $this->os_path, LOGGER_DATA);
logger('RedDirectory::log() red_path ' . $this->red_path, LOGGER_DATA);
}
- function getChildren() {
-
+ /**
+ * @brief Returns an array with all the child nodes.
+ *
+ * @throws DAV\Exception\Forbidden
+ * @return array DAV\INode[]
+ */
+ public function getChildren() {
logger('RedDirectory::getChildren() called for ' . $this->ext_path, LOGGER_DATA);
-
$this->log();
- if(get_config('system','block_public') && (! $this->auth->channel_id) && (! $this->auth->observer)) {
+ if (get_config('system', 'block_public') && (! $this->auth->channel_id) && (! $this->auth->observer)) {
throw new DAV\Exception\Forbidden('Permission denied.');
- return;
}
- if(($this->auth->owner_id) && (! perm_is_allowed($this->auth->owner_id,$this->auth->observer,'view_storage'))) {
+ if (($this->auth->owner_id) && (! perm_is_allowed($this->auth->owner_id, $this->auth->observer, 'view_storage'))) {
throw new DAV\Exception\Forbidden('Permission denied.');
- return;
}
- $contents = RedCollectionData($this->red_path,$this->auth);
+ $contents = RedCollectionData($this->red_path, $this->auth);
return $contents;
}
+ /**
+ * @brief Returns a child by name.
+ *
+ *
+ * @throw DAV\Exception\Forbidden
+ * @throw DAV\Exception\NotFound
+ * @param string $name
+ */
+ public function getChild($name) {
+ logger('RedDirectory::getChild(): ' . $name, LOGGER_DATA);
- function getChild($name) {
-
- logger('RedDirectory::getChild : ' . $name, LOGGER_DATA);
-
- if(get_config('system','block_public') && (! $this->auth->channel_id) && (! $this->auth->observer)) {
+ if (get_config('system', 'block_public') && (! $this->auth->channel_id) && (! $this->auth->observer)) {
throw new DAV\Exception\Forbidden('Permission denied.');
- return;
}
- if(($this->auth->owner_id) && (! perm_is_allowed($this->auth->owner_id,$this->auth->observer,'view_storage'))) {
+ if (($this->auth->owner_id) && (! perm_is_allowed($this->auth->owner_id, $this->auth->observer, 'view_storage'))) {
throw new DAV\Exception\Forbidden('Permission denied.');
- return;
}
- if($this->red_path === '/' && $name === 'cloud') {
+ if ($this->red_path === '/' && $name === 'cloud') {
return new RedDirectory('/cloud', $this->auth);
}
$x = RedFileData($this->ext_path . '/' . $name, $this->auth);
- if($x)
+ if ($x) {
return $x;
+ }
- throw new DAV\Exception\NotFound('The file with name: ' . $name . ' could not be found');
-
+ throw new DAV\Exception\NotFound('The file with name: ' . $name . ' could not be found.');
}
- function getName() {
+ public function getName() {
logger('RedDirectory::getName returns: ' . basename($this->red_path), LOGGER_DATA);
return (basename($this->red_path));
}
+ /**
+ * @brief Creates a new file in the directory.
+ *
+ * Data will either be supplied as a stream resource, or in certain cases
+ * as a string. Keep in mind that you may have to support either.
+ *
+ * After successful creation of the file, you may choose to return the ETag
+ * of the new file here.
+ *
+ * @throws DAV\Exception\Forbidden
+ * @param string $name Name of the file
+ * @param resource|string $data Initial payload
+ * @return null|string
+ */
+ public function createFile($name, $data = null) {
+ logger('RedDirectory::createFile(): ' . $name, LOGGER_DEBUG);
-
-
- function createFile($name,$data = null) {
- logger('RedDirectory::createFile : ' . $name, LOGGER_DEBUG);
-
- if(! $this->auth->owner_id) {
+ if (! $this->auth->owner_id) {
logger('createFile: permission denied');
throw new DAV\Exception\Forbidden('Permission denied.');
- return;
}
- if(! perm_is_allowed($this->auth->owner_id,$this->auth->observer,'write_storage')) {
+ if (! perm_is_allowed($this->auth->owner_id, $this->auth->observer, 'write_storage')) {
logger('createFile: permission denied');
throw new DAV\Exception\Forbidden('Permission denied.');
- return;
}
$mimetype = z_mime_content_type($name);
-
- $c = q("select * from channel where channel_id = %d and not (channel_pageflags & %d) limit 1",
+ $c = q("SELECT * FROM channel WHERE channel_id = %d AND NOT (channel_pageflags & %d) LIMIT 1",
intval($this->auth->owner_id),
intval(PAGE_REMOVED)
-
);
- if(! $c) {
- logger('createFile: no channel');
+ if (! $c) {
+ logger('RedDirectory::createFile(): no channel');
throw new DAV\Exception\Forbidden('Permission denied.');
- return;
}
-
$filesize = 0;
$hash = random_string();
- $r = q("INSERT INTO attach ( aid, uid, hash, creator, filename, folder, flags, filetype, filesize, revision, data, created, edited, allow_cid, allow_gid, deny_cid, deny_gid )
- VALUES ( %d, %d, '%s', '%s', '%s', '%s', '%s', '%s', %d, %d, '%s', '%s', '%s', '%s', '%s', '%s', '%s' ) ",
- intval($c[0]['channel_account_id']),
- intval($c[0]['channel_id']),
- dbesc($hash),
+ $r = q("INSERT INTO attach ( aid, uid, hash, creator, filename, folder, flags, filetype, filesize, revision, data, created, edited, allow_cid, allow_gid, deny_cid, deny_gid )
+ VALUES ( %d, %d, '%s', '%s', '%s', '%s', '%s', '%s', %d, %d, '%s', '%s', '%s', '%s', '%s', '%s', '%s' ) ",
+ intval($c[0]['channel_account_id']),
+ intval($c[0]['channel_id']),
+ dbesc($hash),
dbesc($this->auth->observer),
- dbesc($name),
+ dbesc($name),
dbesc($this->folder_hash),
dbesc(ATTACH_FLAG_OS),
- dbesc($mimetype),
- intval($filesize),
- intval(0),
- dbesc($this->os_path . '/' . $hash),
- dbesc(datetime_convert()),
- dbesc(datetime_convert()),
+ dbesc($mimetype),
+ intval($filesize),
+ intval(0),
+ dbesc($this->os_path . '/' . $hash),
+ dbesc(datetime_convert()),
+ dbesc(datetime_convert()),
dbesc($c[0]['channel_allow_cid']),
dbesc($c[0]['channel_allow_gid']),
dbesc($c[0]['channel_deny_cid']),
dbesc($c[0]['channel_deny_gid'])
-
-
);
$f = 'store/' . $this->auth->owner_nick . '/' . (($this->os_path) ? $this->os_path . '/' : '') . $hash;
- file_put_contents($f, $data);
- $size = filesize($f);
+ // returns the number of bytes that were written to the file, or FALSE on failure
+ $size = file_put_contents($f, $data);
+ // delete attach entry if file_put_contents() failed
+ if ($size === false) {
+ logger('RedDirectory::createFile(): file_put_contents() failed for ' . $name, LOGGER_DEBUG);
+ attach_delete($c[0]['channel_id'], $hash);
+ return;
+ }
+ // returns now
$edited = datetime_convert();
- $d = q("update attach set filesize = '%s', edited = '%s' where hash = '%s' and uid = %d limit 1",
+ // updates entry with filesize and timestamp
+ $d = q("UPDATE attach SET filesize = '%s', edited = '%s' WHERE hash = '%s' AND uid = %d LIMIT 1",
dbesc($size),
dbesc($edited),
dbesc($hash),
intval($c[0]['channel_id'])
);
- $e = q("update attach set edited = '%s' where folder = '%s' and uid = %d limit 1",
+ // update the folder's lastmodified timestamp
+ $e = q("UPDATE attach SET edited = '%s' WHERE folder = '%s' AND uid = %d LIMIT 1",
dbesc($edited),
dbesc($this->folder_hash),
intval($c[0]['channel_id'])
- );
+ );
- $maxfilesize = get_config('system','maxfilesize');
-
- if(($maxfilesize) && ($size > $maxfilesize)) {
- attach_delete($c[0]['channel_id'],$hash);
+ $maxfilesize = get_config('system', 'maxfilesize');
+ if (($maxfilesize) && ($size > $maxfilesize)) {
+ attach_delete($c[0]['channel_id'], $hash);
return;
}
- $limit = service_class_fetch($c[0]['channel_id'],'attach_upload_limit');
- if($limit !== false) {
- $x = q("select sum(filesize) as total from attach where aid = %d ",
+ // check against service class quota
+ $limit = service_class_fetch($c[0]['channel_id'], 'attach_upload_limit');
+ if ($limit !== false) {
+ $x = q("SELECT SUM(filesize) AS total FROM attach WHERE aid = %d ",
intval($c[0]['channel_account_id'])
);
- if(($x) && ($x[0]['total'] + $size > $limit)) {
+ if (($x) && ($x[0]['total'] + $size > $limit)) {
logger('reddav: service class limit exceeded for ' . $c[0]['channel_name'] . ' total usage is ' . $x[0]['total'] . ' limit is ' . $limit);
- attach_delete($c[0]['channel_id'],$hash);
+ attach_delete($c[0]['channel_id'], $hash);
return;
}
}
}
+ /**
+ * @brief Creates a new subdirectory.
+ *
+ * @param string $name the directory to create
+ * @return void
+ */
+ public function createDirectory($name) {
+ logger('RedDirectory::createDirectory(): ' . $name, LOGGER_DEBUG);
- function createDirectory($name) {
-
- logger('RedDirectory::createDirectory: ' . $name, LOGGER_DEBUG);
-
- if((! $this->auth->owner_id) || (! perm_is_allowed($this->auth->owner_id,$this->auth->observer,'write_storage'))) {
+ if ((! $this->auth->owner_id) || (! perm_is_allowed($this->auth->owner_id, $this->auth->observer, 'write_storage'))) {
throw new DAV\Exception\Forbidden('Permission denied.');
- return;
}
- $r = q("select * from channel where channel_id = %d and not (channel_pageflags & %d) limit 1",
+ $r = q("SELECT * FROM channel WHERE channel_id = %d AND NOT (channel_pageflags & %d) LIMIT 1",
intval($this->auth->owner_id),
intval(PAGE_REMOVED)
);
- if($r) {
- $result = attach_mkdir($r[0],$this->auth->observer,array('filename' => $name,'folder' => $this->folder_hash));
- if(! $result['success'])
- logger('RedDirectory::createDirectory: ' . print_r($result,true), LOGGER_DEBUG);
+ if ($r) {
+ $result = attach_mkdir($r[0], $this->auth->observer, array('filename' => $name, 'folder' => $this->folder_hash));
+ if (! $result['success'])
+ logger('RedDirectory::createDirectory(): ' . print_r($result, true), LOGGER_DEBUG);
}
}
-
- function childExists($name) {
-
- if($this->red_path === '/' && $name === 'cloud') {
- logger('RedDirectory::childExists /cloud: true', LOGGER_DATA);
+ /**
+ * @brief Checks if a child exists.
+ *
+ * @param string $name
+ * @return boolean
+ */
+ public function childExists($name) {
+ // On /cloud we show a list of available channels.
+ // @todo what happens if no channels are available?
+ if ($this->red_path === '/' && $name === 'cloud') {
+ logger('RedDirectory::childExists() /cloud: true', LOGGER_DATA);
return true;
}
- $x = RedFileData($this->ext_path . '/' . $name, $this->auth,true);
- logger('RedFileData returns: ' . print_r($x,true), LOGGER_DATA);
- if($x)
+ $x = RedFileData($this->ext_path . '/' . $name, $this->auth, true);
+ logger('RedFileData returns: ' . print_r($x, true), LOGGER_DATA);
+ if ($x)
return true;
return false;
}
+ /**
+ * @todo add description of what this function does.
+ *
+ * @throw DAV\Exception\NotFound
+ * @return void
+ */
function getDir() {
- logger('getDir: ' . $this->ext_path, LOGGER_DEBUG);
+ logger('RedDirectory::getDir(): ' . $this->ext_path, LOGGER_DEBUG);
$this->auth->log();
$file = $this->ext_path;
- $x = strpos($file,'/cloud');
- if($x === false)
+ $x = strpos($file, '/cloud');
+ if ($x === false)
return;
- if($x === 0) {
- $file = substr($file,6);
+ if ($x === 0) {
+ $file = substr($file, 6);
}
- if((! $file) || ($file === '/')) {
+ if ((! $file) || ($file === '/')) {
return;
}
- $file = trim($file,'/');
+ $file = trim($file, '/');
$path_arr = explode('/', $file);
-
- if(! $path_arr)
+
+ if (! $path_arr)
return;
-
- logger('getDir(): path: ' . print_r($path_arr,true), LOGGER_DEBUG);
+ logger('RedDirectory::getDir(): path: ' . print_r($path_arr, true), LOGGER_DEBUG);
$channel_name = $path_arr[0];
-
- $r = q("select channel_id from channel where channel_address = '%s' and not ( channel_pageflags & %d ) limit 1",
+ $r = q("SELECT channel_id FROM channel WHERE channel_address = '%s' AND NOT ( channel_pageflags & %d ) LIMIT 1",
dbesc($channel_name),
intval(PAGE_REMOVED)
);
- if(! $r) {
+ if (! $r) {
throw new DAV\Exception\NotFound('The file with name: ' . $channel_name . ' could not be found');
-
return;
}
+
$channel_id = $r[0]['channel_id'];
$this->auth->owner_id = $channel_id;
$this->auth->owner_nick = $channel_name;
$path = '/' . $channel_name;
-
$folder = '';
$os_path = '';
- for($x = 1; $x < count($path_arr); $x ++) {
-
+ for ($x = 1; $x < count($path_arr); $x++) {
$r = q("select id, hash, filename, flags from attach where folder = '%s' and filename = '%s' and uid = %d and (flags & %d)",
dbesc($folder),
dbesc($path_arr[$x]),
@@ -283,49 +335,58 @@ class RedDirectory extends DAV\Node implements DAV\ICollection, DAV\IQuota {
intval(ATTACH_FLAG_DIR)
);
- if($r && ( $r[0]['flags'] & ATTACH_FLAG_DIR)) {
+ if ($r && ( $r[0]['flags'] & ATTACH_FLAG_DIR)) {
$folder = $r[0]['hash'];
- if(strlen($os_path))
+ if (strlen($os_path))
$os_path .= '/';
$os_path .= $folder;
$path = $path . '/' . $r[0]['filename'];
- }
+ }
}
$this->folder_hash = $folder;
$this->os_path = $os_path;
return;
}
-
- function getLastModified() {
- $r = q("select edited from attach where folder = '%s' and uid = %d order by edited desc limit 1",
+ /**
+ * @brief Returns the last modification time for the directory, as a unix
+ * timestamp.
+ *
+ * @return int last modification time in UNIX timestamp
+ */
+ public function getLastModified() {
+ $r = q("SELECT edited FROM attach WHERE folder = '%s' AND uid = %d ORDER BY edited DESC LIMIT 1",
dbesc($this->folder_hash),
- intval($this->auth->owner_id)
+ intval($this->auth->owner_id)
);
- if($r)
- return datetime_convert('UTC','UTC', $r[0]['edited'],'U');
+ if ($r)
+ return datetime_convert('UTC', 'UTC', $r[0]['edited'], 'U');
return '';
}
-
+ /**
+ * @brief Return quota usage.
+ *
+ * Do guests relly see the used/free values from filesystem of the complete store directory?
+ *
+ * @return array with used and free values in bytes.
+ */
public function getQuotaInfo() {
-
+ // values from the filesystem of the complete store/ directory
$limit = disk_total_space('store');
$free = disk_free_space('store');
- if($this->auth->owner_id) {
-
+ if ($this->auth->owner_id) {
$c = q("select * from channel where channel_id = %d and not (channel_pageflags & %d) limit 1",
intval($this->auth->owner_id),
intval(PAGE_REMOVED)
-
);
- $ulimit = service_class_fetch($c[0]['channel_id'],'attach_upload_limit');
+ $ulimit = service_class_fetch($c[0]['channel_id'], 'attach_upload_limit');
$limit = (($ulimit) ? $ulimit : $limit);
- $x = q("select sum(filesize) as total from attach where aid = %d ",
+ $x = q("select sum(filesize) as total from attach where aid = %d",
intval($c[0]['channel_account_id'])
);
$free = (($x) ? $limit - $x[0]['total'] : 0);
@@ -335,237 +396,322 @@ class RedDirectory extends DAV\Node implements DAV\ICollection, DAV\IQuota {
$limit - $free,
$free
);
-
}
-
-}
+} // class RedDirectory
+
+/**
+ * RedFile class.
+ *
+ */
class RedFile extends DAV\Node implements DAV\IFile {
private $data;
private $auth;
private $name;
- function __construct($name, $data, &$auth) {
+ /**
+ * Sets up the node, expects a full path name.
+ *
+ * @param string $name
+ * @param array $data from attach table
+ * @param &$auth
+ */
+ public function __construct($name, $data, &$auth) {
$this->name = $name;
$this->data = $data;
$this->auth = $auth;
- logger('RedFile::_construct: ' . print_r($this->data,true), LOGGER_DATA);
+ logger('RedFile::__construct(): ' . print_r($this->data, true), LOGGER_DATA);
}
-
- function getName() {
- logger('RedFile::getName: ' . basename($this->name), LOGGER_DEBUG);
+ /**
+ * @brief Returns the name of the file.
+ *
+ * @return string
+ */
+ public function getName() {
+ logger('RedFile::getName(): ' . basename($this->name), LOGGER_DEBUG);
return basename($this->name);
-
}
+ /**
+ * @brief Renames the file.
+ *
+ * @throw DAV\Exception\Forbidden
+ * @param string $name The new name of the file.
+ * @return void
+ */
+ public function setName($newName) {
+ logger('RedFile::setName(): ' . basename($this->name) . ' -> ' . $newName, LOGGER_DEBUG);
- function setName($newName) {
- logger('RedFile::setName: ' . basename($this->name) . ' -> ' . $newName, LOGGER_DEBUG);
-
- if((! $newName) || (! $this->auth->owner_id) || (! perm_is_allowed($this->auth->owner_id,$this->auth->observer,'write_storage'))) {
+ if ((! $newName) || (! $this->auth->owner_id) || (! perm_is_allowed($this->auth->owner_id, $this->auth->observer, 'write_storage'))) {
throw new DAV\Exception\Forbidden('Permission denied.');
- return;
}
- $newName = str_replace('/','%2F',$newName);
+ $newName = str_replace('/', '%2F', $newName);
- $r = q("update attach set filename = '%s' where hash = '%s' and id = %d limit 1",
+ $r = q("UPDATE attach SET filename = '%s' WHERE hash = '%s' AND id = %d LIMIT 1",
dbesc($this->data['filename']),
intval($this->data['id'])
);
-
}
+ /**
+ * @brief Updates the data of the file.
+ *
+ * @param resource $data
+ * @return void
+ */
+ public function put($data) {
+ logger('RedFile::put(): ' . basename($this->name), LOGGER_DEBUG);
+ $size = 0;
- function put($data) {
- logger('RedFile::put: ' . basename($this->name), LOGGER_DEBUG);
-
- $c = q("select * from channel where channel_id = %d and not (channel_pageflags & %d) limit 1",
+ // @todo only 3 values are needed
+ $c = q("SELECT * FROM channel WHERE channel_id = %d AND NOT (channel_pageflags & %d) LIMIT 1",
intval(PAGE_REMOVED),
intval($this->auth->owner_id)
);
- $r = q("select flags, folder, data from attach where hash = '%s' and uid = %d limit 1",
+ $r = q("SELECT flags, folder, data FROM attach WHERE hash = '%s' AND uid = %d LIMIT 1",
dbesc($this->data['hash']),
intval($c[0]['channel_id'])
);
- if($r) {
- if($r[0]['flags'] & ATTACH_FLAG_OS) {
+ if ($r) {
+ if ($r[0]['flags'] & ATTACH_FLAG_OS) {
$f = 'store/' . $this->auth->owner_nick . '/' . (($r[0]['data']) ? $r[0]['data'] : '');
+ // @todo check return value and set $size directly
@file_put_contents($f, $data);
$size = @filesize($f);
- logger('reddav: put() filename: ' . $f . ' size: ' . $size, LOGGER_DEBUG);
- }
- else {
- $r = q("update attach set data = '%s' where hash = '%s' and uid = %d limit 1",
+ logger('RedFile::put(): filename: ' . $f . ' size: ' . $size, LOGGER_DEBUG);
+ } else {
+ $r = q("UPDATE attach SET data = '%s' WHERE hash = '%s' AND uid = %d LIMIT 1",
dbesc(stream_get_contents($data)),
dbesc($this->data['hash']),
intval($this->data['uid'])
);
- $r = q("select length(data) as fsize from attach where hash = '%s' and uid = %d limit 1",
+ $r = q("SELECT length(data) AS fsize FROM attach WHERE hash = '%s' AND uid = %d LIMIT 1",
dbesc($this->data['hash']),
intval($this->data['uid'])
);
- if($r)
+ if ($r) {
$size = $r[0]['fsize'];
+ }
}
-
}
+ // returns now()
$edited = datetime_convert();
- $d = q("update attach set filesize = '%s', edited = '%s' where hash = '%s' and uid = %d limit 1",
+ $d = q("UPDATE attach SET filesize = '%s', edited = '%s' WHERE hash = '%s' AND uid = %d LIMIT 1",
dbesc($size),
dbesc($edited),
dbesc($this->data['hash']),
intval($c[0]['channel_id'])
);
- $e = q("update attach set edited = '%s' where folder = '%s' and uid = %d limit 1",
+ // update the folder's lastmodified timestamp
+ $e = q("UPDATE attach SET edited = '%s' WHERE folder = '%s' AND uid = %d LIMIT 1",
dbesc($edited),
dbesc($r[0]['folder']),
intval($c[0]['channel_id'])
- );
+ );
- $maxfilesize = get_config('system','maxfilesize');
+ // @todo do we really want to remove the whole file if an update fails because of maxfilesize or quota?
- if(($maxfilesize) && ($size > $maxfilesize)) {
- attach_delete($c[0]['channel_id'],$this->data['hash']);
+ $maxfilesize = get_config('system', 'maxfilesize');
+ if (($maxfilesize) && ($size > $maxfilesize)) {
+ attach_delete($c[0]['channel_id'], $this->data['hash']);
return;
}
- $limit = service_class_fetch($c[0]['channel_id'],'attach_upload_limit');
- if($limit !== false) {
+ $limit = service_class_fetch($c[0]['channel_id'], 'attach_upload_limit');
+ if ($limit !== false) {
$x = q("select sum(filesize) as total from attach where aid = %d ",
intval($c[0]['channel_account_id'])
);
- if(($x) && ($x[0]['total'] + $size > $limit)) {
- logger('reddav: service class limit exceeded for ' . $c[0]['channel_name'] . ' total usage is ' . $x[0]['total'] . ' limit is ' . $limit);
- attach_delete($c[0]['channel_id'],$this->data['hash']);
+ if (($x) && ($x[0]['total'] + $size > $limit)) {
+ logger('RedFile::put(): service class limit exceeded for ' . $c[0]['channel_name'] . ' total usage is ' . $x[0]['total'] . ' limit is ' . $limit);
+ attach_delete($c[0]['channel_id'], $this->data['hash']);
return;
}
}
}
-
- function get() {
- logger('RedFile::get: ' . basename($this->name), LOGGER_DEBUG);
+ /**
+ * @brief Returns the raw data.
+ *
+ * @return string
+ */
+ public function get() {
+ logger('RedFile::get(): ' . basename($this->name), LOGGER_DEBUG);
$r = q("select data, flags, filename, filetype from attach where hash = '%s' and uid = %d limit 1",
dbesc($this->data['hash']),
intval($this->data['uid'])
);
- if($r) {
- $unsafe_types = array('text/html','text/css','application/javascript');
+ if ($r) {
+ // @todo this should be a global definition
+ $unsafe_types = array('text/html', 'text/css', 'application/javascript');
- if(in_array($r[0]['filetype'],$unsafe_types)) {
+ if (in_array($r[0]['filetype'], $unsafe_types)) {
header('Content-disposition: attachment; filename="' . $r[0]['filename'] . '"');
header('Content-type: text/plain');
}
- if($r[0]['flags'] & ATTACH_FLAG_OS ) {
+ if ($r[0]['flags'] & ATTACH_FLAG_OS ) {
$f = 'store/' . $this->auth->owner_nick . '/' . (($this->os_path) ? $this->os_path . '/' : '') . $r[0]['data'];
- return fopen($f,'rb');
+ return fopen($f, 'rb');
}
return $r[0]['data'];
}
-
}
- function getETag() {
- return $this->data['hash'];
+ /**
+ * @brief Returns the ETag for a file.
+ *
+ * An ETag is a unique identifier representing the current version of the file. If the file changes, the ETag MUST change.
+ * The ETag is an arbitrary string, but MUST be surrounded by double-quotes.
+ *
+ * Return null if the ETag can not effectively be determined.
+ *
+ * @return mixed
+ */
+ public function getETag() {
+ $ret = null;
+ if ($this->data['hash']) {
+ $ret = '"' . $this->data['hash'] . '"';
+ }
+ return $ret;
}
-
- function getContentType() {
- $unsafe_types = array('text/html','text/css','application/javascript');
- if(in_array($this->data['filetype'],$unsafe_types)) {
+ /**
+ * @brief Returns the mime-type for a file.
+ *
+ * If null is returned, we'll assume application/octet-stream
+ *
+ * @return mixed
+ */
+ public function getContentType() {
+ // @todo this should be a global definition.
+ $unsafe_types = array('text/html', 'text/css', 'application/javascript');
+ if (in_array($this->data['filetype'], $unsafe_types)) {
return 'text/plain';
}
return $this->data['filetype'];
}
-
- function getSize() {
+ /**
+ * @brief Returns the size of the node, in bytes.
+ *
+ * @return int
+ */
+ public function getSize() {
return $this->data['filesize'];
}
-
- function getLastModified() {
- return datetime_convert('UTC','UTC',$this->data['edited'],'U');
+ /**
+ * @brief Returns the last modification time for the file, as a unix
+ * timestamp.
+ *
+ * @return int last modification time in UNIX timestamp
+ */
+ public function getLastModified() {
+ return datetime_convert('UTC', 'UTC', $this->data['edited'], 'U');
}
-
- function delete() {
- if((! $this->auth->owner_id) || (! perm_is_allowed($this->auth->owner_id,$this->auth->observer,'write_storage'))) {
+ /**
+ * @brief Delete the current file.
+ *
+ * @throw DAV\Exception\Forbidden
+ * @return void
+ */
+ public function delete() {
+ if ((! $this->auth->owner_id) || (! perm_is_allowed($this->auth->owner_id, $this->auth->observer, 'write_storage'))) {
throw new DAV\Exception\Forbidden('Permission denied.');
- return;
}
- if($this->auth->owner_id !== $this->auth->channel_id) {
- if(($this->auth->observer !== $this->data['creator']) || ($this->data['flags'] & ATTACH_FLAG_DIR)) {
+ if ($this->auth->owner_id !== $this->auth->channel_id) {
+ if (($this->auth->observer !== $this->data['creator']) || ($this->data['flags'] & ATTACH_FLAG_DIR)) {
throw new DAV\Exception\Forbidden('Permission denied.');
- return;
}
}
- attach_delete($this->auth->owner_id,$this->data['hash']);
+ attach_delete($this->auth->owner_id, $this->data['hash']);
}
+} // class RedFile
-}
+/**
+ * @brief Returns an array with viewable channels.
+ *
+ * Get a list of RedDirectory objects with all the channels where the visitor
+ * has view_storage perms.
+ *
+ * @todo Is there any reason why this is not inside RedDirectory class?
+ *
+ * @param $auth
+ * @return array containing RedDirectory objects
+ */
function RedChannelList(&$auth) {
-
$ret = array();
- $r = q("select channel_id, channel_address from channel where not (channel_pageflags & %d) and not (channel_pageflags & %d) ",
+ $r = q("SELECT channel_id, channel_address FROM channel WHERE NOT (channel_pageflags & %d) AND NOT (channel_pageflags & %d)",
intval(PAGE_REMOVED),
intval(PAGE_HIDDEN)
);
- if($r) {
- foreach($r as $rr) {
- if(perm_is_allowed($rr['channel_id'],$auth->observer,'view_storage')) {
+ if ($r) {
+ foreach ($r as $rr) {
+ if (perm_is_allowed($rr['channel_id'], $auth->observer, 'view_storage')) {
logger('RedChannelList: ' . '/cloud/' . $rr['channel_address'], LOGGER_DATA);
- $ret[] = new RedDirectory('/cloud/' . $rr['channel_address'],$auth);
+ // @todo can't we drop '/cloud'? It gets stripped off anyway in RedDirectory
+ $ret[] = new RedDirectory('/cloud/' . $rr['channel_address'], $auth);
}
}
}
return $ret;
-
}
-function RedCollectionData($file,&$auth) {
-
+/**
+ * @brief TODO what exactly does this function?
+ *
+ * Array with all RedDirectory and RedFile DAV\Node items for the given path.
+ *
+ * @todo Is there any reason why this is not inside RedDirectory class? Seems only to be used there and we could simplify it a bit there.
+ *
+ * @param string $file path to a directory
+ * @param &$auth
+ * @returns array DAV\INode[]
+ */
+function RedCollectionData($file, &$auth) {
$ret = array();
- $x = strpos($file,'/cloud');
- if($x === 0) {
- $file = substr($file,6);
+ $x = strpos($file, '/cloud');
+ if ($x === 0) {
+ $file = substr($file, 6);
}
- if((! $file) || ($file === '/')) {
+ // return a list of channel if we are not inside a channel
+ if ((! $file) || ($file === '/')) {
return RedChannelList($auth);
}
- $file = trim($file,'/');
+ $file = trim($file, '/');
$path_arr = explode('/', $file);
- if(! $path_arr)
+ if (! $path_arr)
return null;
$channel_name = $path_arr[0];
- $r = q("select channel_id from channel where channel_address = '%s' limit 1",
+ $r = q("SELECT channel_id FROM channel WHERE channel_address = '%s' LIMIT 1",
dbesc($channel_name)
);
- if(! $r)
+ if (! $r)
return null;
$channel_id = $r[0]['channel_id'];
@@ -579,15 +725,14 @@ function RedCollectionData($file,&$auth) {
$errors = false;
$permission_error = false;
- for($x = 1; $x < count($path_arr); $x ++) {
-
+ for ($x = 1; $x < count($path_arr); $x++) {
$r = q("select id, hash, filename, flags from attach where folder = '%s' and filename = '%s' and uid = %d and (flags & %d) $perms limit 1",
dbesc($folder),
dbesc($path_arr[$x]),
intval($channel_id),
intval(ATTACH_FLAG_DIR)
);
- if(! $r) {
+ if (! $r) {
// path wasn't found. Try without permissions to see if it was the result of permissions.
$errors = true;
$r = q("select id, hash, filename, flags from attach where folder = '%s' and filename = '%s' and uid = %d and (flags & %d) limit 1",
@@ -596,87 +741,85 @@ function RedCollectionData($file,&$auth) {
intval($channel_id),
intval(ATTACH_FLAG_DIR)
);
- if($r) {
+ if ($r) {
$permission_error = true;
}
break;
}
- if($r && ( $r[0]['flags'] & ATTACH_FLAG_DIR)) {
+ if ($r && ($r[0]['flags'] & ATTACH_FLAG_DIR)) {
$folder = $r[0]['hash'];
$path = $path . '/' . $r[0]['filename'];
- }
+ }
}
- if($errors) {
- if($permission_error) {
+ if ($errors) {
+ if ($permission_error) {
throw new DAV\Exception\Forbidden('Permission denied.');
- return;
- }
- else {
- throw new DAV\Exception\NotFound('A component of the request file path could not be found');
- return;
+ } else {
+ throw new DAV\Exception\NotFound('A component of the request file path could not be found.');
}
}
// This should no longer be needed since we just returned errors for paths not found
-
- if($path !== '/' . $file) {
+ if ($path !== '/' . $file) {
logger("RedCollectionData: Path mismatch: $path !== /$file");
return NULL;
}
- $ret = array();
-
$r = q("select id, uid, hash, filename, filetype, filesize, revision, folder, flags, created, edited from attach where folder = '%s' and uid = %d $perms group by filename",
dbesc($folder),
intval($channel_id)
);
- foreach($r as $rr) {
+ foreach ($r as $rr) {
logger('RedCollectionData: filename: ' . $rr['filename'], LOGGER_DATA);
- if($rr['flags'] & ATTACH_FLAG_DIR)
- $ret[] = new RedDirectory('/cloud' . $path . '/' . $rr['filename'],$auth);
- else
- $ret[] = new RedFile('/cloud' . $path . '/' . $rr['filename'],$rr,$auth);
+ if ($rr['flags'] & ATTACH_FLAG_DIR) {
+ // @todo can't we drop '/cloud'? it gets stripped off anyway in RedDirectory
+ $ret[] = new RedDirectory('/cloud' . $path . '/' . $rr['filename'], $auth);
+ } else {
+ $ret[] = new RedFile('/cloud' . $path . '/' . $rr['filename'], $rr, $auth);
+ }
}
return $ret;
-
}
-function RedFileData($file, &$auth,$test = false) {
+/**
+ * @brief TODO What exactly is this function for?
+ *
+ * @param string $file
+ * @param &$auth
+ * @param boolean $test (optional) enable test mode
+ */
+function RedFileData($file, &$auth, $test = false) {
logger('RedFileData:' . $file . (($test) ? ' (test mode) ' : ''), LOGGER_DEBUG);
-
- $x = strpos($file,'/cloud');
- if($x === 0) {
- $file = substr($file,6);
+ $x = strpos($file, '/cloud');
+ if ($x === 0) {
+ $file = substr($file, 6);
}
- if((! $file) || ($file === '/')) {
- return new RedDirectory('/',$auth);
-
+ if ((! $file) || ($file === '/')) {
+ return new RedDirectory('/', $auth);
}
- $file = trim($file,'/');
+ $file = trim($file, '/');
$path_arr = explode('/', $file);
- if(! $path_arr)
+ if (! $path_arr)
return null;
-
$channel_name = $path_arr[0];
-
$r = q("select channel_id from channel where channel_address = '%s' limit 1",
dbesc($channel_name)
);
- if(! $r)
+ if (! $r)
return null;
$channel_id = $r[0]['channel_id'];
@@ -694,7 +837,7 @@ function RedFileData($file, &$auth,$test = false) {
$errors = false;
- for($x = 1; $x < count($path_arr); $x ++) {
+ for ($x = 1; $x < count($path_arr); $x++) {
$r = q("select id, hash, filename, flags from attach where folder = '%s' and filename = '%s' and uid = %d and (flags & %d) $perms",
dbesc($folder),
dbesc($path_arr[$x]),
@@ -702,21 +845,19 @@ function RedFileData($file, &$auth,$test = false) {
intval(ATTACH_FLAG_DIR)
);
- if($r && ( $r[0]['flags'] & ATTACH_FLAG_DIR)) {
+ if ($r && ( $r[0]['flags'] & ATTACH_FLAG_DIR)) {
$folder = $r[0]['hash'];
$path = $path . '/' . $r[0]['filename'];
}
- if(! $r) {
+ if (! $r) {
$r = q("select id, uid, hash, filename, filetype, filesize, revision, folder, flags, created, edited from attach
where folder = '%s' and filename = '%s' and uid = %d $perms group by filename limit 1",
dbesc($folder),
dbesc(basename($file)),
intval($channel_id)
-
);
}
- if(! $r) {
-
+ if (! $r) {
$errors = true;
$r = q("select id, uid, hash, filename, filetype, filesize, revision, folder, flags, created, edited from attach
where folder = '%s' and filename = '%s' and uid = %d group by filename limit 1",
@@ -724,71 +865,88 @@ function RedFileData($file, &$auth,$test = false) {
dbesc(basename($file)),
intval($channel_id)
);
- if($r)
+ if ($r)
$permission_error = true;
-
}
-
}
- if($path === '/' . $file) {
- if($test)
+ if ($path === '/' . $file) {
+ if ($test)
return true;
// final component was a directory.
- return new RedDirectory('/cloud/' . $file,$auth);
+ return new RedDirectory('/cloud/' . $file, $auth);
}
- if($errors) {
+ if ($errors) {
logger('RedFileData: not found');
- if($test)
+ if ($test)
return false;
- if($permission_error) {
+ if ($permission_error) {
logger('RedFileData: permission error');
throw new DAV\Exception\Forbidden('Permission denied.');
}
return;
}
- if($r) {
- if($test)
+ if ($r) {
+ if ($test)
return true;
- if($r[0]['flags'] & ATTACH_FLAG_DIR)
- return new RedDirectory('/cloud' . $path . '/' . $r[0]['filename'],$auth);
- else
- return new RedFile('/cloud' . $path . '/' . $r[0]['filename'],$r[0],$auth);
+ if ($r[0]['flags'] & ATTACH_FLAG_DIR) {
+ // @todo can't we drop '/cloud'? it gets stripped off anyway in RedDirectory
+ return new RedDirectory('/cloud' . $path . '/' . $r[0]['filename'], $auth);
+ } else {
+ return new RedFile('/cloud' . $path . '/' . $r[0]['filename'], $r[0], $auth);
+ }
}
return false;
}
-class RedBasicAuth extends Sabre\DAV\Auth\Backend\AbstractBasic {
+/**
+ * RedBasicAuth class.
+ *
+ */
+class RedBasicAuth extends DAV\Auth\Backend\AbstractBasic {
+
+ // @fixme mod/cloud.php:61
public $channel_name = '';
+ // @fixme mod/cloud.php:62
public $channel_id = 0;
+ // @fixme mod/cloud.php:63
public $channel_hash = '';
+ // @fixme mod/cloud.php:68
public $observer = '';
+ // @fixme include/reddav.php:51
public $browser;
+ // @fixme include/reddav.php:92
public $owner_id;
+ // @fixme include/reddav.php:283
public $owner_nick = '';
+ // @fixme mod/cloud.php:66
public $timezone;
- protected function validateUserPass($username, $password) {
+ /**
+ *
+ * @param string $username
+ * @param string $password
+ */
+ protected function validateUserPass($username, $password) {
-
- if(trim($password) === '+++') {
+ if (trim($password) === '+++') {
logger('reddav: validateUserPass: guest ' . $username);
return true;
}
require_once('include/auth.php');
- $record = account_verify_password($username,$password);
- if($record && $record['account_default_channel']) {
+ $record = account_verify_password($username, $password);
+ if ($record && $record['account_default_channel']) {
$r = q("select * from channel where channel_account_id = %d and channel_id = %d limit 1",
intval($record['account_id']),
intval($record['account_default_channel'])
);
- if($r) {
+ if ($r) {
$this->currentUser = $r[0]['channel_address'];
$this->channel_name = $r[0]['channel_address'];
$this->channel_id = $r[0]['channel_id'];
@@ -802,15 +960,15 @@ class RedBasicAuth extends Sabre\DAV\Auth\Backend\AbstractBasic {
$r = q("select * from channel where channel_address = '%s' limit 1",
dbesc($username)
);
- if($r) {
+ if ($r) {
$x = q("select * from account where account_id = %d limit 1",
intval($r[0]['channel_account_id'])
);
- if($x) {
- foreach($x as $record) {
- if(($record['account_flags'] == ACCOUNT_OK) || ($record['account_flags'] == ACCOUNT_UNVERIFIED)
- && (hash('whirlpool',$record['account_salt'] . $password) === $record['account_password'])) {
- logger('(DAV) RedBasicAuth: password verified for ' . $username);
+ if ($x) {
+ foreach ($x as $record) {
+ if (($record['account_flags'] == ACCOUNT_OK) || ($record['account_flags'] == ACCOUNT_UNVERIFIED)
+ && (hash('whirlpool', $record['account_salt'] . $password) === $record['account_password'])) {
+ logger('(DAV) RedBasicAuth: password verified for ' . $username);
$this->currentUser = $r[0]['channel_address'];
$this->channel_name = $r[0]['channel_address'];
$this->channel_id = $r[0]['channel_id'];
@@ -818,24 +976,24 @@ class RedBasicAuth extends Sabre\DAV\Auth\Backend\AbstractBasic {
$_SESSION['uid'] = $r[0]['channel_id'];
$_SESSION['account_id'] = $r[0]['channel_account_id'];
$_SESSION['authenticated'] = true;
- return true;
- }
- }
+ return true;
+ }
+ }
}
}
- logger('(DAV) RedBasicAuth: password failed for ' . $username);
- return false;
+ logger('(DAV) RedBasicAuth: password failed for ' . $username);
+ return false;
}
- function setCurrentUser($name) {
+ public function setCurrentUser($name) {
$this->currentUser = $name;
}
function setBrowserPlugin($browser) {
$this->browser = $browser;
}
-
+ // internal? loggin function
function log() {
logger('dav: auth: channel_name ' . $this->channel_name, LOGGER_DATA);
logger('dav: auth: channel_id ' . $this->channel_id, LOGGER_DATA);
@@ -845,64 +1003,66 @@ class RedBasicAuth extends Sabre\DAV\Auth\Backend\AbstractBasic {
logger('dav: auth: owner_nick ' . $this->owner_nick, LOGGER_DATA);
}
-
-}
+} // class RedBasicAuth
+
+/**
+ * RedBrowser class.
+ *
+ */
class RedBrowser extends DAV\Browser\Plugin {
private $auth;
function __construct(&$auth) {
-
$this->auth = $auth;
$this->enableAssets = false;
-
}
// The DAV browser is instantiated after the auth module and directory classes but before we know the current
// directory and who the owner and observer are. So we add a pointer to the browser into the auth module and vice
// versa. Then when we've figured out what directory is actually being accessed, we call the following function
// to decide whether or not to show web elements which include writeable objects.
-
-
function set_writeable() {
-
- if(! $this->auth->owner_id)
+ if (! $this->auth->owner_id) {
$this->enablePost = false;
+ }
- if(! perm_is_allowed($this->auth->owner_id, get_observer_hash(), 'write_storage'))
+ if (! perm_is_allowed($this->auth->owner_id, get_observer_hash(), 'write_storage')) {
$this->enablePost = false;
- else
+ } else {
$this->enablePost = true;
-
+ }
}
/**
* Creates the directory listing for the given path.
*
- * @param String $path
+ * @todo Why not use RedDirectory for this?
+ *
+ * @param string $path which should be displayed
*/
public function generateDirectoryIndex($path) {
-
+ // (owner_id = channel_id) is visitor owner of this directory?
$is_owner = ((local_user() && $this->auth->owner_id == local_user()) ? true : false);
if ($this->auth->timezone)
date_default_timezone_set($this->auth->timezone);
- $version = '';
require_once('include/conversation.php');
- if ($this->auth->owner_nick)
- $html = profile_tabs(get_app(),(($is_owner) ? true : false),$this->auth->owner_nick);
+ if ($this->auth->owner_nick) {
+ $html = profile_tabs(get_app(), (($is_owner) ? true : false), $this->auth->owner_nick);
+ }
- $files = $this->server->getPropertiesForPath($path,array(
+ $files = $this->server->getPropertiesForPath($path, array(
'{DAV:}displayname',
'{DAV:}resourcetype',
'{DAV:}getcontenttype',
'{DAV:}getcontentlength',
'{DAV:}getlastmodified',
- ),1);
+ ), 1);
$parent = $this->server->tree->getNodeForPath($path);
@@ -912,21 +1072,20 @@ class RedBrowser extends DAV\Browser\Plugin {
list($parentUri) = DAV\URLUtil::splitPath($path);
$fullPath = DAV\URLUtil::encodePath($this->server->getBaseUri() . $parentUri);
- $parentpath['icon'] = $this->enableAssets?'':'';
+ $parentpath['icon'] = $this->enableAssets ? '' : '';
$parentpath['path'] = $fullPath;
- }
+ }
$f = array();
foreach ($files as $file) {
$ft = array();
+ $type = null;
// This is the current directory, we can skip it
if (rtrim($file['href'],'/')==$path) continue;
list(, $name) = DAV\URLUtil::splitPath($file['href']);
- $type = null;
-
if (isset($file[200]['{DAV:}resourcetype'])) {
$type = $file[200]['{DAV:}resourcetype']->getValue();
@@ -935,31 +1094,31 @@ class RedBrowser extends DAV\Browser\Plugin {
foreach ($type as $k=>$v) {
// Some name mapping is preferred
- switch($v) {
- case '{DAV:}collection' :
- $type[$k] = t('Collection');
- break;
- case '{DAV:}principal' :
- $type[$k] = t('Principal');
- break;
- case '{urn:ietf:params:xml:ns:carddav}addressbook' :
- $type[$k] = t('Addressbook');
- break;
- case '{urn:ietf:params:xml:ns:caldav}calendar' :
- $type[$k] = t('Calendar');
- break;
- case '{urn:ietf:params:xml:ns:caldav}schedule-inbox' :
- $type[$k] = t('Schedule Inbox');
- break;
- case '{urn:ietf:params:xml:ns:caldav}schedule-outbox' :
- $type[$k] = t('Schedule Outbox');
- break;
- case '{http://calendarserver.org/ns/}calendar-proxy-read' :
- $type[$k] = 'Proxy-Read';
- break;
- case '{http://calendarserver.org/ns/}calendar-proxy-write' :
- $type[$k] = 'Proxy-Write';
- break;
+ switch ($v) {
+ case '{DAV:}collection' :
+ $type[$k] = t('Collection');
+ break;
+ case '{DAV:}principal' :
+ $type[$k] = t('Principal');
+ break;
+ case '{urn:ietf:params:xml:ns:carddav}addressbook' :
+ $type[$k] = t('Addressbook');
+ break;
+ case '{urn:ietf:params:xml:ns:caldav}calendar' :
+ $type[$k] = t('Calendar');
+ break;
+ case '{urn:ietf:params:xml:ns:caldav}schedule-inbox' :
+ $type[$k] = t('Schedule Inbox');
+ break;
+ case '{urn:ietf:params:xml:ns:caldav}schedule-outbox' :
+ $type[$k] = t('Schedule Outbox');
+ break;
+ case '{http://calendarserver.org/ns/}calendar-proxy-read' :
+ $type[$k] = 'Proxy-Read';
+ break;
+ case '{http://calendarserver.org/ns/}calendar-proxy-write' :
+ $type[$k] = 'Proxy-Write';
+ break;
}
}
$type = implode(', ', $type);
@@ -970,21 +1129,21 @@ class RedBrowser extends DAV\Browser\Plugin {
if (!$type && isset($file[200]['{DAV:}getcontenttype'])) {
$type = $file[200]['{DAV:}getcontenttype'];
}
- if (!$type) $type = 'Unknown';
+ if (!$type) $type = t('Unknown');
- $size = isset($file[200]['{DAV:}getcontentlength'])?(int)$file[200]['{DAV:}getcontentlength']:'';
- $lastmodified = ((isset($file[200]['{DAV:}getlastmodified']))? $file[200]['{DAV:}getlastmodified']->getTime()->format('Y-m-d H:i:s') :'');
+ $size = isset($file[200]['{DAV:}getcontentlength']) ? (int)$file[200]['{DAV:}getcontentlength'] : '';
+ $lastmodified = ((isset($file[200]['{DAV:}getlastmodified'])) ? $file[200]['{DAV:}getlastmodified']->getTime()->format('Y-m-d H:i:s') : '');
- $fullPath = DAV\URLUtil::encodePath('/' . trim($this->server->getBaseUri() . ($path?$path . '/':'') . $name,'/'));
+ $fullPath = DAV\URLUtil::encodePath('/' . trim($this->server->getBaseUri() . ($path ? $path . '/' : '') . $name, '/'));
- $displayName = isset($file[200]['{DAV:}displayname'])?$file[200]['{DAV:}displayname']:$name;
+ $displayName = isset($file[200]['{DAV:}displayname']) ? $file[200]['{DAV:}displayname'] : $name;
$displayName = $this->escapeHTML($displayName);
$type = $this->escapeHTML($type);
$icon = '';
if ($this->enableAssets) {
- $node = $this->server->tree->getNodeForPath(($path?$path.'/':'') . $name);
+ $node = $this->server->tree->getNodeForPath(($path ? $path . '/' : '') . $name);
foreach (array_reverse($this->iconMap) as $class=>$iconName) {
if ($node instanceof $class) {
$icon = '';
@@ -993,13 +1152,13 @@ class RedBrowser extends DAV\Browser\Plugin {
}
}
- $parentHash="";
- $owner=$this->auth->owner_id;
- $splitPath = split("/",$fullPath);
+ $parentHash = "";
+ $owner = $this->auth->owner_id;
+ $splitPath = split("/", $fullPath);
if (count($splitPath) > 3) {
- for ($i=3; $ifindAttachHash($owner,$parentHash,$attachName);
+ $attachHash = $this->findAttachHash($owner, $parentHash, $attachName);
$parentHash = $attachHash;
}
}
@@ -1008,10 +1167,10 @@ class RedBrowser extends DAV\Browser\Plugin {
// put the array for this file together
$ft['attachId'] = $this->findAttachIdByHash($attachHash);
- $ft['fileStorageUrl'] = substr($fullPath, 0, strpos($fullPath,"cloud/")) ."filestorage/".$this->auth->channel_name;
+ $ft['fileStorageUrl'] = substr($fullPath, 0, strpos($fullPath, "cloud/")) . "filestorage/" . $this->auth->channel_name;
$ft['icon'] = $icon;
$ft['attachIcon'] = (($size) ? $attachIcon : '');
- // is global or per item?
+ // @todo Should this be an item value, not a global one?
$ft['is_owner'] = $is_owner;
$ft['fullPath'] = $fullPath;
$ft['displayName'] = $displayName;
@@ -1023,9 +1182,9 @@ class RedBrowser extends DAV\Browser\Plugin {
$f[] = $ft;
}
- // Storage and Quota
+ // Storage and quota for the account (all channels of the owner of this directory)!
$limit = service_class_fetch($owner, 'attach_upload_limit');
- $r = q("select sum(filesize) as total from attach where aid = %d ",
+ $r = q("SELECT SUM(filesize) AS total FROM attach WHERE aid = %d",
intval($this->auth->channel_account_id)
);
$used = $r[0]['total'];
@@ -1042,45 +1201,50 @@ class RedBrowser extends DAV\Browser\Plugin {
round($used / $limit, 1));
}
- // quota for template
+ // prepare quota for template
$quota['used'] = $used;
$quota['limit'] = $limit;
$quota['desc'] = $quotaDesc;
$html .= replace_macros(get_markup_template('cloud_directory.tpl'), array(
- '$header' => t('Files').": ".$this->escapeHTML($path) . "/",
- '$parentpath' => $parentpath,
- '$entries' => $f,
- '$quota' => $quota
- ));
+ '$header' => t('Files') . ": " . $this->escapeHTML($path) . "/",
+ '$parentpath' => $parentpath,
+ '$entries' => $f,
+ '$quota' => $quota
+ ));
$output = '';
if ($this->enablePost) {
- $this->server->broadcastEvent('onHTMLActionsPanel',array($parent, &$output));
+ $this->server->broadcastEvent('onHTMLActionsPanel', array($parent, &$output));
}
- $html.=$output;
+ $html .= $output;
get_app()->page['content'] = $html;
construct_page(get_app());
}
- function userReadableSize($size){
+ function userReadableSize($size) {
+ $ret = "";
if (is_numeric($size)) {
$incr = 0;
$k = 1024;
- $unit = array('bytes','KB','MB','GB','TB','PB');
- while(($size / $k) >= 1){
+ $unit = array('bytes', 'KB', 'MB', 'GB', 'TB', 'PB');
+ while (($size / $k) >= 1){
$incr++;
$size = round($size / $k, 2);
}
- return $size." ".$unit[$incr];
- } else {
- return "";
+ $ret = $size . " " . $unit[$incr];
}
+ return $ret;
}
- public function htmlActionsPanel(DAV\INode $node, &$output) {
-
+ /**
+ * Creates a form to add new folders and upload files.
+ *
+ * @param DAV\INode $node
+ * @param string &$output
+ */
+ public function htmlActionsPanel(DAV\INode $node, &$output) {
//Removed link to filestorage page
//if($this->auth->owner_id && $this->auth->owner_id == $this->auth->channel_id) {
@@ -1090,70 +1254,59 @@ class RedBrowser extends DAV\Browser\Plugin {
// }
//}
- if (!$node instanceof DAV\ICollection)
- return;
+ if (! $node instanceof DAV\ICollection)
+ return;
- // We also know fairly certain that if an object is a non-extended
- // SimpleCollection, we won't need to show the panel either.
+ // We also know fairly certain that if an object is a non-extended
+ // SimpleCollection, we won't need to show the panel either.
+ if (get_class($node) === 'Sabre\\DAV\\SimpleCollection')
+ return;
- if (get_class($node)==='Sabre\\DAV\\SimpleCollection')
- return;
-
- $output.= '
-
-
'.t('Create new folder').'
-
-
-
'.t('Upload file').'
-
-
-
';
-
- }
-
- /**
- * This method takes a path/name of an asset and turns it into url
- * suiteable for http access.
- *
- * @param string $assetName
- * @return string
- */
- protected function getAssetUrl($assetName) {
- return z_root() .'/cloud/?sabreAction=asset&assetName=' . urlencode($assetName);
- }
-
- protected function findAttachHash($owner, $parentHash, $attachName) {
- $r = q("select * from attach where uid = %d and folder = '%s' and filename = '%s' order by edited desc limit 1",
- intval($owner), dbesc($parentHash), dbesc($attachName)
- );
- $hash = "";
- if($r) {
- foreach($r as $rr) {
- $hash = $rr['hash'];
- }
+ $output .= replace_macros(get_markup_template('cloud_actionspanel.tpl'), array(
+ '$folder_header' => t('Create new folder'),
+ '$folder_submit' => t('Create'),
+ '$upload_header' => t('Upload file'),
+ '$upload_submit' => t('Upload')
+ ));
}
- return $hash;
- }
-
- protected function findAttachIdByHash($attachHash) {
- $r = q("select * from attach where hash = '%s' order by edited desc limit 1",
- dbesc($attachHash)
- );
- $id = "";
- if($r) {
- foreach($r as $rr) {
- $id = $rr['id'];
- }
+
+ /**
+ * This method takes a path/name of an asset and turns it into url
+ * suiteable for http access.
+ *
+ * @param string $assetName
+ * @return string
+ */
+ protected function getAssetUrl($assetName) {
+ return z_root() . '/cloud/?sabreAction=asset&assetName=' . urlencode($assetName);
}
- return $id;
- }
-}
+
+ protected function findAttachHash($owner, $parentHash, $attachName) {
+ $r = q("SELECT * FROM attach WHERE uid = %d AND folder = '%s' AND filename = '%s' ORDER BY edited desc LIMIT 1",
+ intval($owner),
+ dbesc($parentHash),
+ dbesc($attachName)
+ );
+ $hash = "";
+ if ($r) {
+ foreach ($r as $rr) {
+ $hash = $rr['hash'];
+ }
+ }
+ return $hash;
+ }
+
+ protected function findAttachIdByHash($attachHash) {
+ $r = q("SELECT * FROM attach WHERE hash = '%s' ORDER BY edited DESC LIMIT 1",
+ dbesc($attachHash)
+ );
+ $id = "";
+ if ($r) {
+ foreach ($r as $rr) {
+ $id = $rr['id'];
+ }
+ }
+ return $id;
+ }
+
+} // class RedBrowser
diff --git a/mod/editblock.php b/mod/editblock.php
index 507050eb0..536ddd7d2 100644
--- a/mod/editblock.php
+++ b/mod/editblock.php
@@ -58,8 +58,8 @@ function editblock_content(&$a) {
$plaintext = true;
// You may or may not be a local user.
- if(local_user() && feature_enabled(local_user(),'richtext'))
- $plaintext = false;
+// if(local_user() && feature_enabled(local_user(),'richtext'))
+// $plaintext = false;
$mimeselect = '';
$mimetype = $itm[0]['mimetype'];
diff --git a/mod/editlayout.php b/mod/editlayout.php
index da681cf34..1e8a6e990 100644
--- a/mod/editlayout.php
+++ b/mod/editlayout.php
@@ -65,8 +65,8 @@ function editlayout_content(&$a) {
$plaintext = true;
// You may or may not be a local user. This won't work,
- if(feature_enabled(local_user(),'richtext'))
- $plaintext = false;
+// if(feature_enabled(local_user(),'richtext'))
+// $plaintext = false;
$o .= replace_macros(get_markup_template('edpost_head.tpl'), array(
'$title' => t('Edit Layout')
diff --git a/mod/editwebpage.php b/mod/editwebpage.php
index b8b7a465c..9fe76ba98 100644
--- a/mod/editwebpage.php
+++ b/mod/editwebpage.php
@@ -73,8 +73,8 @@ function editwebpage_content(&$a) {
$plaintext = true;
- if(feature_enabled($itm[0]['uid'],'richtext'))
- $plaintext = false;
+// if(feature_enabled($itm[0]['uid'],'richtext'))
+// $plaintext = false;
$mimetype = $itm[0]['mimetype'];
diff --git a/mod/events.php b/mod/events.php
index 911b6c891..7c4d6c191 100755
--- a/mod/events.php
+++ b/mod/events.php
@@ -161,8 +161,8 @@ function events_content(&$a) {
$plaintext = true;
- if(feature_enabled(local_user(),'richtext'))
- $plaintext = false;
+// if(feature_enabled(local_user(),'richtext'))
+// $plaintext = false;
diff --git a/mod/item.php b/mod/item.php
index 693c64eca..c9ec56eeb 100644
--- a/mod/item.php
+++ b/mod/item.php
@@ -430,10 +430,14 @@ function item_post(&$a) {
// First figure out if it's a status post that would've been
// created using tinymce. Otherwise leave it alone.
- $plaintext = ((feature_enabled($profile_uid,'richtext')) ? false : true);
- if((! $parent) && (! $api_source) && (! $plaintext)) {
- $body = fix_mce_lf($body);
- }
+ $plaintext = true;
+
+// $plaintext = ((feature_enabled($profile_uid,'richtext')) ? false : true);
+// if((! $parent) && (! $api_source) && (! $plaintext)) {
+// $body = fix_mce_lf($body);
+// }
+
+
// If we're sending a private top-level message with a single @-taggable channel as a recipient, @-tag it, if our pconfig is set.
diff --git a/mod/mail.php b/mod/mail.php
index 9c84872ef..c3ce47b5a 100644
--- a/mod/mail.php
+++ b/mod/mail.php
@@ -76,9 +76,9 @@ function mail_post(&$a) {
}
}
- if(feature_enabled(local_user(),'richtext')) {
- $body = fix_mce_lf($body);
- }
+// if(feature_enabled(local_user(),'richtext')) {
+// $body = fix_mce_lf($body);
+// }
if(! $recipient) {
notice('No recipient found.');
@@ -156,11 +156,7 @@ function mail_content(&$a) {
$o .= $header;
- $plaintext = false;
- if(intval(get_pconfig(local_user(),'system','plaintext')))
- $plaintext = true;
- if(! feature_enabled(local_user(),'richtext'))
- $plaintext = true;
+ $plaintext = true;
$tpl = get_markup_template('msg-header.tpl');
@@ -240,8 +236,9 @@ function mail_content(&$a) {
$o .= $header;
$plaintext = true;
- if( local_user() && feature_enabled(local_user(),'richtext') )
- $plaintext = false;
+
+// if( local_user() && feature_enabled(local_user(),'richtext') )
+// $plaintext = false;
$messages = private_messages_fetch_conversation(local_user(), argv(1), true);
diff --git a/mod/profiles.php b/mod/profiles.php
index 2e91db600..f6392d4ab 100644
--- a/mod/profiles.php
+++ b/mod/profiles.php
@@ -477,8 +477,8 @@ function profiles_content(&$a) {
$editselect = 'none';
- if(feature_enabled(local_user(),'richtext'))
- $editselect = 'textareas';
+// if(feature_enabled(local_user(),'richtext'))
+// $editselect = 'textareas';
$a->page['htmlhead'] .= replace_macros(get_markup_template('profed_head.tpl'), array(
'$baseurl' => $a->get_baseurl(true),
diff --git a/mod/rpost.php b/mod/rpost.php
index 309208870..80406ebef 100644
--- a/mod/rpost.php
+++ b/mod/rpost.php
@@ -83,8 +83,8 @@ function rpost_content(&$a) {
}
$plaintext = true;
- if(feature_enabled(local_user(),'richtext'))
- $plaintext = false;
+// if(feature_enabled(local_user(),'richtext'))
+// $plaintext = false;
if(array_key_exists('type', $_REQUEST) && $_REQUEST['type'] === 'html') {
require_once('include/html2bbcode.php');
diff --git a/util/messages.po b/util/messages.po
index 7e314e083..d63bcc5ab 100644
--- a/util/messages.po
+++ b/util/messages.po
@@ -6,9 +6,9 @@
#, fuzzy
msgid ""
msgstr ""
-"Project-Id-Version: 2014-06-20.712\n"
+"Project-Id-Version: 2014-06-27.719\n"
"Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2014-06-20 00:03-0700\n"
+"POT-Creation-Date: 2014-06-27 00:02-0700\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME \n"
"Language-Team: LANGUAGE \n"
@@ -77,504 +77,506 @@ msgstr ""
msgid "commented on %s's post"
msgstr ""
-#: ../../include/conversation.php:117 ../../include/text.php:1705
+#: ../../include/conversation.php:120 ../../include/text.php:1705
#: ../../mod/subthread.php:72 ../../mod/subthread.php:174
-#: ../../mod/tagger.php:45 ../../mod/like.php:111
+#: ../../mod/tagger.php:45 ../../mod/like.php:254
msgid "photo"
msgstr ""
-#: ../../include/conversation.php:120 ../../include/text.php:1708
+#: ../../include/conversation.php:123 ../../include/text.php:1708
#: ../../mod/tagger.php:49
msgid "event"
msgstr ""
-#: ../../include/conversation.php:123
+#: ../../include/conversation.php:126 ../../mod/like.php:72
msgid "channel"
msgstr ""
-#: ../../include/conversation.php:145 ../../include/text.php:1711
+#: ../../include/conversation.php:148 ../../include/text.php:1711
#: ../../mod/subthread.php:72 ../../mod/subthread.php:174
-#: ../../mod/tagger.php:53 ../../mod/like.php:111
+#: ../../mod/tagger.php:53 ../../mod/like.php:254
msgid "status"
msgstr ""
-#: ../../include/conversation.php:147 ../../include/text.php:1713
+#: ../../include/conversation.php:150 ../../include/text.php:1713
#: ../../mod/tagger.php:55
msgid "comment"
msgstr ""
-#: ../../include/conversation.php:161 ../../mod/like.php:142
+#: ../../include/conversation.php:164 ../../mod/like.php:291
#, php-format
msgid "%1$s likes %2$s's %3$s"
msgstr ""
-#: ../../include/conversation.php:164 ../../mod/like.php:144
+#: ../../include/conversation.php:167 ../../mod/like.php:293
#, php-format
msgid "%1$s doesn't like %2$s's %3$s"
msgstr ""
-#: ../../include/conversation.php:201
+#: ../../include/conversation.php:204
#, php-format
msgid "%1$s is now connected with %2$s"
msgstr ""
-#: ../../include/conversation.php:236
+#: ../../include/conversation.php:239
#, php-format
msgid "%1$s poked %2$s"
msgstr ""
-#: ../../include/conversation.php:240 ../../include/text.php:895
+#: ../../include/conversation.php:243 ../../include/text.php:895
msgid "poked"
msgstr ""
-#: ../../include/conversation.php:258 ../../mod/mood.php:63
+#: ../../include/conversation.php:261 ../../mod/mood.php:63
#, php-format
msgctxt "mood"
msgid "%1$s is %2$s"
msgstr ""
-#: ../../include/conversation.php:631 ../../include/ItemObject.php:114
+#: ../../include/conversation.php:634 ../../include/ItemObject.php:114
msgid "Select"
msgstr ""
-#: ../../include/conversation.php:632 ../../include/apps.php:232
+#: ../../include/conversation.php:635 ../../include/apps.php:232
#: ../../include/ItemObject.php:108 ../../mod/settings.php:578
-#: ../../mod/connedit.php:398 ../../mod/filestorage.php:175
-#: ../../mod/group.php:176 ../../mod/admin.php:758 ../../mod/admin.php:887
-#: ../../mod/thing.php:236 ../../mod/photos.php:1041
+#: ../../mod/connedit.php:398 ../../mod/photos.php:1046
+#: ../../mod/group.php:176 ../../mod/admin.php:758 ../../mod/admin.php:888
+#: ../../mod/thing.php:236
+#: ../../view/tpl/smarty3/compiled/de0b699d2fc212753c3f166003476a343ca00174.file.cloud_directory.tpl.php:84
msgid "Delete"
msgstr ""
-#: ../../include/conversation.php:639 ../../include/ItemObject.php:89
+#: ../../include/conversation.php:642 ../../include/ItemObject.php:89
#: ../../mod/photos.php:844
msgid "Private Message"
msgstr ""
-#: ../../include/conversation.php:646 ../../include/ItemObject.php:182
+#: ../../include/conversation.php:649 ../../include/ItemObject.php:182
msgid "Message is verified"
msgstr ""
-#: ../../include/conversation.php:666
+#: ../../include/conversation.php:669
#, php-format
msgid "View %s's profile @ %s"
msgstr ""
-#: ../../include/conversation.php:680
+#: ../../include/conversation.php:683
msgid "Categories:"
msgstr ""
-#: ../../include/conversation.php:681
+#: ../../include/conversation.php:684
msgid "Filed under:"
msgstr ""
-#: ../../include/conversation.php:690 ../../include/ItemObject.php:250
+#: ../../include/conversation.php:693 ../../include/ItemObject.php:250
#, php-format
msgid " from %s"
msgstr ""
-#: ../../include/conversation.php:693 ../../include/ItemObject.php:253
+#: ../../include/conversation.php:696 ../../include/ItemObject.php:253
#, php-format
msgid "last edited: %s"
msgstr ""
-#: ../../include/conversation.php:694 ../../include/ItemObject.php:254
+#: ../../include/conversation.php:697 ../../include/ItemObject.php:254
#, php-format
msgid "Expires: %s"
msgstr ""
-#: ../../include/conversation.php:709
+#: ../../include/conversation.php:712
msgid "View in context"
msgstr ""
-#: ../../include/conversation.php:711 ../../include/conversation.php:1127
+#: ../../include/conversation.php:714 ../../include/conversation.php:1130
#: ../../include/ItemObject.php:294 ../../mod/editblock.php:120
#: ../../mod/editlayout.php:115 ../../mod/editpost.php:121
-#: ../../mod/editwebpage.php:152 ../../mod/mail.php:222 ../../mod/mail.php:336
-#: ../../mod/photos.php:972
+#: ../../mod/editwebpage.php:152 ../../mod/photos.php:977
+#: ../../mod/mail.php:222 ../../mod/mail.php:336
msgid "Please wait"
msgstr ""
-#: ../../include/conversation.php:838
+#: ../../include/conversation.php:841
msgid "remove"
msgstr ""
-#: ../../include/conversation.php:842
+#: ../../include/conversation.php:845
msgid "Loading..."
msgstr ""
-#: ../../include/conversation.php:843
+#: ../../include/conversation.php:846
msgid "Delete Selected Items"
msgstr ""
-#: ../../include/conversation.php:934
+#: ../../include/conversation.php:937
msgid "View Source"
msgstr ""
-#: ../../include/conversation.php:935
+#: ../../include/conversation.php:938
msgid "Follow Thread"
msgstr ""
-#: ../../include/conversation.php:936
+#: ../../include/conversation.php:939
msgid "View Status"
msgstr ""
-#: ../../include/conversation.php:937 ../../include/nav.php:81
+#: ../../include/conversation.php:940 ../../include/nav.php:81
#: ../../mod/connedit.php:351 ../../mod/connedit.php:465
msgid "View Profile"
msgstr ""
-#: ../../include/conversation.php:938
+#: ../../include/conversation.php:941
msgid "View Photos"
msgstr ""
-#: ../../include/conversation.php:939
+#: ../../include/conversation.php:942
msgid "Matrix Activity"
msgstr ""
-#: ../../include/conversation.php:940
+#: ../../include/conversation.php:943
msgid "Edit Contact"
msgstr ""
-#: ../../include/conversation.php:941
+#: ../../include/conversation.php:944
msgid "Send PM"
msgstr ""
-#: ../../include/conversation.php:942 ../../include/apps.php:135
+#: ../../include/conversation.php:945 ../../include/apps.php:135
msgid "Poke"
msgstr ""
-#: ../../include/conversation.php:998
+#: ../../include/conversation.php:1001
#, php-format
msgid "%s likes this."
msgstr ""
-#: ../../include/conversation.php:998
+#: ../../include/conversation.php:1001
#, php-format
msgid "%s doesn't like this."
msgstr ""
-#: ../../include/conversation.php:1002
+#: ../../include/conversation.php:1005
#, php-format
msgid "%2$d people like this."
msgid_plural "%2$d people like this."
msgstr[0] ""
msgstr[1] ""
-#: ../../include/conversation.php:1004
+#: ../../include/conversation.php:1007
#, php-format
msgid "%2$d people don't like this."
msgid_plural "%2$d people don't like this."
msgstr[0] ""
msgstr[1] ""
-#: ../../include/conversation.php:1010
+#: ../../include/conversation.php:1013
msgid "and"
msgstr ""
-#: ../../include/conversation.php:1013
+#: ../../include/conversation.php:1016
#, php-format
msgid ", and %d other people"
msgid_plural ", and %d other people"
msgstr[0] ""
msgstr[1] ""
-#: ../../include/conversation.php:1014
+#: ../../include/conversation.php:1017
#, php-format
msgid "%s like this."
msgstr ""
-#: ../../include/conversation.php:1014
+#: ../../include/conversation.php:1017
#, php-format
msgid "%s don't like this."
msgstr ""
-#: ../../include/conversation.php:1071
+#: ../../include/conversation.php:1074
msgid "Visible to everybody"
msgstr ""
-#: ../../include/conversation.php:1072 ../../mod/mail.php:171
+#: ../../include/conversation.php:1075 ../../mod/mail.php:171
#: ../../mod/mail.php:269
msgid "Please enter a link URL:"
msgstr ""
-#: ../../include/conversation.php:1073
+#: ../../include/conversation.php:1076
msgid "Please enter a video link/URL:"
msgstr ""
-#: ../../include/conversation.php:1074
+#: ../../include/conversation.php:1077
msgid "Please enter an audio link/URL:"
msgstr ""
-#: ../../include/conversation.php:1075
+#: ../../include/conversation.php:1078
msgid "Tag term:"
msgstr ""
-#: ../../include/conversation.php:1076 ../../mod/filer.php:49
+#: ../../include/conversation.php:1079 ../../mod/filer.php:49
msgid "Save to Folder:"
msgstr ""
-#: ../../include/conversation.php:1077
+#: ../../include/conversation.php:1080
msgid "Where are you right now?"
msgstr ""
-#: ../../include/conversation.php:1078 ../../mod/editpost.php:52
+#: ../../include/conversation.php:1081 ../../mod/editpost.php:52
#: ../../mod/mail.php:172 ../../mod/mail.php:270
msgid "Expires YYYY-MM-DD HH:MM"
msgstr ""
-#: ../../include/conversation.php:1088 ../../include/page_widgets.php:40
+#: ../../include/conversation.php:1091 ../../include/page_widgets.php:40
#: ../../include/ItemObject.php:592 ../../mod/editblock.php:141
#: ../../mod/editlayout.php:135 ../../mod/editpost.php:140
-#: ../../mod/editwebpage.php:174 ../../mod/webpages.php:124
-#: ../../mod/photos.php:992
+#: ../../mod/editwebpage.php:174 ../../mod/photos.php:997
+#: ../../mod/webpages.php:124
msgid "Preview"
msgstr ""
-#: ../../include/conversation.php:1102 ../../mod/layouts.php:113
-#: ../../mod/photos.php:971
+#: ../../include/conversation.php:1105 ../../mod/photos.php:976
+#: ../../mod/layouts.php:113
msgid "Share"
msgstr ""
-#: ../../include/conversation.php:1104 ../../mod/editwebpage.php:139
+#: ../../include/conversation.php:1107 ../../mod/editwebpage.php:139
msgid "Page link title"
msgstr ""
-#: ../../include/conversation.php:1107
+#: ../../include/conversation.php:1110
msgid "Post as"
msgstr ""
-#: ../../include/conversation.php:1108 ../../mod/editblock.php:112
+#: ../../include/conversation.php:1111 ../../mod/editblock.php:112
#: ../../mod/editlayout.php:107 ../../mod/editpost.php:113
#: ../../mod/editwebpage.php:144 ../../mod/mail.php:219 ../../mod/mail.php:332
msgid "Upload photo"
msgstr ""
-#: ../../include/conversation.php:1109
+#: ../../include/conversation.php:1112
msgid "upload photo"
msgstr ""
-#: ../../include/conversation.php:1110 ../../mod/editblock.php:113
+#: ../../include/conversation.php:1113 ../../mod/editblock.php:113
#: ../../mod/editlayout.php:108 ../../mod/editpost.php:114
#: ../../mod/editwebpage.php:145 ../../mod/mail.php:220 ../../mod/mail.php:333
msgid "Attach file"
msgstr ""
-#: ../../include/conversation.php:1111
+#: ../../include/conversation.php:1114
msgid "attach file"
msgstr ""
-#: ../../include/conversation.php:1112 ../../mod/editblock.php:114
+#: ../../include/conversation.php:1115 ../../mod/editblock.php:114
#: ../../mod/editlayout.php:109 ../../mod/editpost.php:115
#: ../../mod/editwebpage.php:146 ../../mod/mail.php:221 ../../mod/mail.php:334
msgid "Insert web link"
msgstr ""
-#: ../../include/conversation.php:1113
+#: ../../include/conversation.php:1116
msgid "web link"
msgstr ""
-#: ../../include/conversation.php:1114
+#: ../../include/conversation.php:1117
msgid "Insert video link"
msgstr ""
-#: ../../include/conversation.php:1115
+#: ../../include/conversation.php:1118
msgid "video link"
msgstr ""
-#: ../../include/conversation.php:1116
+#: ../../include/conversation.php:1119
msgid "Insert audio link"
msgstr ""
-#: ../../include/conversation.php:1117
+#: ../../include/conversation.php:1120
msgid "audio link"
msgstr ""
-#: ../../include/conversation.php:1118 ../../mod/editblock.php:118
+#: ../../include/conversation.php:1121 ../../mod/editblock.php:118
#: ../../mod/editlayout.php:113 ../../mod/editpost.php:119
#: ../../mod/editwebpage.php:150
msgid "Set your location"
msgstr ""
-#: ../../include/conversation.php:1119
+#: ../../include/conversation.php:1122
msgid "set location"
msgstr ""
-#: ../../include/conversation.php:1120 ../../mod/editblock.php:119
+#: ../../include/conversation.php:1123 ../../mod/editblock.php:119
#: ../../mod/editlayout.php:114 ../../mod/editpost.php:120
#: ../../mod/editwebpage.php:151
msgid "Clear browser location"
msgstr ""
-#: ../../include/conversation.php:1121
+#: ../../include/conversation.php:1124
msgid "clear location"
msgstr ""
-#: ../../include/conversation.php:1123 ../../mod/editblock.php:132
+#: ../../include/conversation.php:1126 ../../mod/editblock.php:132
#: ../../mod/editlayout.php:126 ../../mod/editpost.php:132
#: ../../mod/editwebpage.php:167
msgid "Set title"
msgstr ""
-#: ../../include/conversation.php:1126 ../../mod/editblock.php:135
+#: ../../include/conversation.php:1129 ../../mod/editblock.php:135
#: ../../mod/editlayout.php:129 ../../mod/editpost.php:134
#: ../../mod/editwebpage.php:169
msgid "Categories (comma-separated list)"
msgstr ""
-#: ../../include/conversation.php:1128 ../../mod/editblock.php:121
+#: ../../include/conversation.php:1131 ../../mod/editblock.php:121
#: ../../mod/editlayout.php:116 ../../mod/editpost.php:122
#: ../../mod/editwebpage.php:153
msgid "Permission settings"
msgstr ""
-#: ../../include/conversation.php:1129
+#: ../../include/conversation.php:1132
msgid "permissions"
msgstr ""
-#: ../../include/conversation.php:1136 ../../mod/editblock.php:129
+#: ../../include/conversation.php:1139 ../../mod/editblock.php:129
#: ../../mod/editlayout.php:123 ../../mod/editpost.php:129
#: ../../mod/editwebpage.php:162
msgid "Public post"
msgstr ""
-#: ../../include/conversation.php:1138 ../../mod/editblock.php:136
+#: ../../include/conversation.php:1141 ../../mod/editblock.php:136
#: ../../mod/editlayout.php:130 ../../mod/editpost.php:135
#: ../../mod/editwebpage.php:170
msgid "Example: bob@example.com, mary@example.com"
msgstr ""
-#: ../../include/conversation.php:1151 ../../mod/editblock.php:146
+#: ../../include/conversation.php:1154 ../../mod/editblock.php:146
#: ../../mod/editlayout.php:140 ../../mod/editpost.php:146
#: ../../mod/editwebpage.php:179 ../../mod/mail.php:226 ../../mod/mail.php:339
msgid "Set expiration date"
msgstr ""
-#: ../../include/conversation.php:1153 ../../include/ItemObject.php:595
+#: ../../include/conversation.php:1156 ../../include/ItemObject.php:595
#: ../../mod/editpost.php:148 ../../mod/mail.php:228 ../../mod/mail.php:341
msgid "Encrypt text"
msgstr ""
-#: ../../include/conversation.php:1155 ../../mod/editpost.php:150
+#: ../../include/conversation.php:1158 ../../mod/editpost.php:150
msgid "OK"
msgstr ""
-#: ../../include/conversation.php:1156 ../../mod/settings.php:516
+#: ../../include/conversation.php:1159 ../../mod/settings.php:516
#: ../../mod/settings.php:542 ../../mod/editpost.php:151
#: ../../mod/fbrowser.php:82 ../../mod/fbrowser.php:117 ../../mod/tagrm.php:11
#: ../../mod/tagrm.php:94
msgid "Cancel"
msgstr ""
-#: ../../include/conversation.php:1398
+#: ../../include/conversation.php:1401
msgid "Discover"
msgstr ""
-#: ../../include/conversation.php:1401
+#: ../../include/conversation.php:1404
msgid "Imported public streams"
msgstr ""
-#: ../../include/conversation.php:1406
+#: ../../include/conversation.php:1409
msgid "Commented Order"
msgstr ""
-#: ../../include/conversation.php:1409
+#: ../../include/conversation.php:1412
msgid "Sort by Comment Date"
msgstr ""
-#: ../../include/conversation.php:1413
+#: ../../include/conversation.php:1416
msgid "Posted Order"
msgstr ""
-#: ../../include/conversation.php:1416
+#: ../../include/conversation.php:1419
msgid "Sort by Post Date"
msgstr ""
-#: ../../include/conversation.php:1421 ../../include/widgets.php:82
+#: ../../include/conversation.php:1424 ../../include/widgets.php:82
msgid "Personal"
msgstr ""
-#: ../../include/conversation.php:1424
+#: ../../include/conversation.php:1427
msgid "Posts that mention or involve you"
msgstr ""
-#: ../../include/conversation.php:1430 ../../mod/connections.php:211
+#: ../../include/conversation.php:1433 ../../mod/connections.php:211
#: ../../mod/connections.php:224 ../../mod/menu.php:61
msgid "New"
msgstr ""
-#: ../../include/conversation.php:1433
+#: ../../include/conversation.php:1436
msgid "Activity Stream - by date"
msgstr ""
-#: ../../include/conversation.php:1439
+#: ../../include/conversation.php:1442
msgid "Starred"
msgstr ""
-#: ../../include/conversation.php:1442
+#: ../../include/conversation.php:1445
msgid "Favourite Posts"
msgstr ""
-#: ../../include/conversation.php:1449
+#: ../../include/conversation.php:1452
msgid "Spam"
msgstr ""
-#: ../../include/conversation.php:1452
+#: ../../include/conversation.php:1455
msgid "Posts flagged as SPAM"
msgstr ""
-#: ../../include/conversation.php:1486 ../../mod/admin.php:891
+#: ../../include/conversation.php:1488 ../../mod/admin.php:892
msgid "Channel"
msgstr ""
-#: ../../include/conversation.php:1489
+#: ../../include/conversation.php:1491
msgid "Status Messages and Posts"
msgstr ""
-#: ../../include/conversation.php:1498
+#: ../../include/conversation.php:1500
msgid "About"
msgstr ""
-#: ../../include/conversation.php:1501
+#: ../../include/conversation.php:1503
msgid "Profile Details"
msgstr ""
-#: ../../include/conversation.php:1507 ../../include/nav.php:84
+#: ../../include/conversation.php:1509 ../../include/nav.php:84
#: ../../include/apps.php:129 ../../mod/fbrowser.php:25
msgid "Photos"
msgstr ""
-#: ../../include/conversation.php:1510 ../../include/photos.php:313
+#: ../../include/conversation.php:1512 ../../include/photos.php:313
msgid "Photo Albums"
msgstr ""
-#: ../../include/conversation.php:1516 ../../include/nav.php:85
-#: ../../include/apps.php:125 ../../mod/fbrowser.php:114
+#: ../../include/conversation.php:1518 ../../include/nav.php:85
+#: ../../include/reddav.php:1051 ../../include/apps.php:125
+#: ../../mod/fbrowser.php:114
msgid "Files"
msgstr ""
-#: ../../include/conversation.php:1519
+#: ../../include/conversation.php:1521
msgid "Files and Storage"
msgstr ""
-#: ../../include/conversation.php:1528 ../../include/conversation.php:1531
+#: ../../include/conversation.php:1530 ../../include/conversation.php:1533
msgid "Chatrooms"
msgstr ""
-#: ../../include/conversation.php:1538 ../../include/nav.php:93
+#: ../../include/conversation.php:1540 ../../include/nav.php:93
#: ../../include/apps.php:119
msgid "Bookmarks"
msgstr ""
-#: ../../include/conversation.php:1541
+#: ../../include/conversation.php:1543
msgid "Saved Bookmarks"
msgstr ""
-#: ../../include/conversation.php:1549 ../../include/nav.php:95
+#: ../../include/conversation.php:1551 ../../include/nav.php:95
#: ../../include/apps.php:126 ../../mod/webpages.php:79
msgid "Webpages"
msgstr ""
-#: ../../include/conversation.php:1552
+#: ../../include/conversation.php:1554
msgid "Manage Webpages"
msgstr ""
@@ -588,8 +590,9 @@ msgstr ""
#: ../../mod/blocks.php:94 ../../mod/connections.php:393
#: ../../mod/editblock.php:111 ../../mod/editlayout.php:106
#: ../../mod/editpost.php:112 ../../mod/editwebpage.php:143
-#: ../../mod/filestorage.php:174 ../../mod/thing.php:235
-#: ../../mod/layouts.php:112 ../../mod/menu.php:59 ../../mod/webpages.php:120
+#: ../../mod/thing.php:235 ../../mod/layouts.php:112 ../../mod/menu.php:59
+#: ../../mod/webpages.php:120
+#: ../../view/tpl/smarty3/compiled/de0b699d2fc212753c3f166003476a343ca00174.file.cloud_directory.tpl.php:80
msgid "Edit"
msgstr ""
@@ -685,7 +688,7 @@ msgstr ""
#: ../../include/attach.php:243 ../../include/attach.php:283
#: ../../include/attach.php:297 ../../include/attach.php:322
#: ../../include/attach.php:513 ../../include/attach.php:585
-#: ../../include/chat.php:116 ../../include/items.php:3679
+#: ../../include/chat.php:116 ../../include/items.php:3680
#: ../../mod/mood.php:112 ../../mod/mitem.php:73 ../../mod/achievements.php:27
#: ../../mod/settings.php:492 ../../mod/poke.php:128 ../../mod/api.php:26
#: ../../mod/api.php:31 ../../mod/authtest.php:13 ../../mod/profile.php:64
@@ -701,19 +704,19 @@ msgstr ""
#: ../../mod/page.php:80 ../../mod/setup.php:203 ../../mod/editblock.php:34
#: ../../mod/pdledit.php:21 ../../mod/editlayout.php:48
#: ../../mod/editpost.php:13 ../../mod/editwebpage.php:44
-#: ../../mod/editwebpage.php:83 ../../mod/sources.php:66
-#: ../../mod/events.php:141 ../../mod/filestorage.php:10
-#: ../../mod/filestorage.php:59 ../../mod/filestorage.php:75
-#: ../../mod/filestorage.php:98 ../../mod/fsuggest.php:78
-#: ../../mod/suggest.php:26 ../../mod/group.php:9 ../../mod/thing.php:247
-#: ../../mod/thing.php:263 ../../mod/thing.php:298 ../../mod/invite.php:13
-#: ../../mod/invite.php:104 ../../mod/item.php:179 ../../mod/item.php:187
-#: ../../mod/item.php:894 ../../mod/layouts.php:27 ../../mod/layouts.php:39
-#: ../../mod/viewconnections.php:22 ../../mod/viewconnections.php:27
-#: ../../mod/viewsrc.php:12 ../../mod/mail.php:108 ../../mod/manage.php:6
-#: ../../mod/menu.php:44 ../../mod/webpages.php:40 ../../mod/message.php:16
+#: ../../mod/editwebpage.php:83 ../../mod/photos.php:68
+#: ../../mod/photos.php:526 ../../mod/sources.php:66 ../../mod/events.php:141
+#: ../../mod/filestorage.php:10 ../../mod/filestorage.php:59
+#: ../../mod/filestorage.php:75 ../../mod/filestorage.php:98
+#: ../../mod/fsuggest.php:78 ../../mod/suggest.php:26 ../../mod/group.php:9
+#: ../../mod/thing.php:249 ../../mod/thing.php:266 ../../mod/thing.php:301
+#: ../../mod/invite.php:13 ../../mod/invite.php:104 ../../mod/item.php:179
+#: ../../mod/item.php:187 ../../mod/item.php:898 ../../mod/layouts.php:27
+#: ../../mod/layouts.php:39 ../../mod/viewconnections.php:22
+#: ../../mod/viewconnections.php:27 ../../mod/viewsrc.php:12
+#: ../../mod/mail.php:108 ../../mod/manage.php:6 ../../mod/menu.php:44
+#: ../../mod/webpages.php:40 ../../mod/message.php:16
#: ../../mod/new_channel.php:66 ../../mod/new_channel.php:97
-#: ../../mod/photos.php:68 ../../mod/photos.php:526
#: ../../mod/notifications.php:66 ../../mod/appman.php:66 ../../index.php:186
#: ../../index.php:361
msgid "Permission denied."
@@ -737,7 +740,7 @@ msgid "Photo storage failed."
msgstr ""
#: ../../include/photos.php:317 ../../mod/photos.php:691
-#: ../../mod/photos.php:1188
+#: ../../mod/photos.php:1193
msgid "Upload New Photos"
msgstr ""
@@ -754,8 +757,8 @@ msgid "Don't show"
msgstr ""
#: ../../include/acl_selectors.php:248 ../../mod/chat.php:209
-#: ../../mod/filestorage.php:126 ../../mod/photos.php:604
-#: ../../mod/photos.php:947
+#: ../../mod/photos.php:604 ../../mod/photos.php:952
+#: ../../mod/filestorage.php:128
msgid "Permissions"
msgstr ""
@@ -866,7 +869,7 @@ msgstr ""
msgid "Location:"
msgstr ""
-#: ../../include/nav.php:77 ../../include/nav.php:101 ../../boot.php:1456
+#: ../../include/nav.php:77 ../../include/nav.php:101 ../../boot.php:1464
msgid "Logout"
msgstr ""
@@ -918,7 +921,7 @@ msgstr ""
msgid "Your webpages"
msgstr ""
-#: ../../include/nav.php:99 ../../include/apps.php:121 ../../boot.php:1457
+#: ../../include/nav.php:99 ../../include/apps.php:121 ../../boot.php:1465
msgid "Login"
msgstr ""
@@ -939,7 +942,7 @@ msgstr ""
msgid "Home Page"
msgstr ""
-#: ../../include/nav.php:139 ../../mod/register.php:206 ../../boot.php:1433
+#: ../../include/nav.php:139 ../../mod/register.php:206 ../../boot.php:1441
msgid "Register"
msgstr ""
@@ -1082,8 +1085,8 @@ msgid "Manage Your Channels"
msgstr ""
#: ../../include/nav.php:191 ../../include/apps.php:124
-#: ../../include/widgets.php:514 ../../mod/admin.php:977
-#: ../../mod/admin.php:1182
+#: ../../include/widgets.php:514 ../../mod/admin.php:978
+#: ../../mod/admin.php:1183
msgid "Settings"
msgstr ""
@@ -1172,6 +1175,14 @@ msgstr ""
msgid "dislikes"
msgstr ""
+#: ../../include/taxonomy.php:338 ../../include/identity.php:968
+#: ../../include/ItemObject.php:134
+msgctxt "noun"
+msgid "Like"
+msgid_plural "Likes"
+msgstr[0] ""
+msgstr[1] ""
+
#: ../../include/comanche.php:35 ../../view/theme/apw/php/config.php:185
#: ../../view/theme/redbasic/php/config.php:84
msgid "Default"
@@ -1238,7 +1249,7 @@ msgid "RSS/Atom"
msgstr ""
#: ../../include/contact_selectors.php:77 ../../mod/admin.php:754
-#: ../../mod/admin.php:763 ../../boot.php:1459
+#: ../../mod/admin.php:763 ../../boot.php:1467
msgid "Email"
msgstr ""
@@ -1347,10 +1358,6 @@ msgstr ""
msgid "This event has been added to your calendar."
msgstr ""
-#: ../../include/reddav.php:1045
-msgid "Edit File properties"
-msgstr ""
-
#: ../../include/datetime.php:43 ../../include/datetime.php:45
msgid "Miscellaneous"
msgstr ""
@@ -1653,6 +1660,63 @@ msgstr ""
msgid "Please visit %s to approve or reject the suggestion."
msgstr ""
+#: ../../include/reddav.php:915
+#: ../../view/tpl/smarty3/compiled/de0b699d2fc212753c3f166003476a343ca00174.file.cloud_directory.tpl.php:52
+#: ../../view/tpl/smarty3/compiled/de0b699d2fc212753c3f166003476a343ca00174.file.cloud_directory.tpl.php:55
+msgid "parent"
+msgstr ""
+
+#: ../../include/reddav.php:940
+msgid "Collection"
+msgstr ""
+
+#: ../../include/reddav.php:943
+msgid "Principal"
+msgstr ""
+
+#: ../../include/reddav.php:946
+msgid "Addressbook"
+msgstr ""
+
+#: ../../include/reddav.php:949
+msgid "Calendar"
+msgstr ""
+
+#: ../../include/reddav.php:952
+msgid "Schedule Inbox"
+msgstr ""
+
+#: ../../include/reddav.php:955
+msgid "Schedule Outbox"
+msgstr ""
+
+#: ../../include/reddav.php:1033
+#, php-format
+msgid "%1$s used"
+msgstr ""
+
+#: ../../include/reddav.php:1038
+#, php-format
+msgid "%1$s used of %2$s (%3$s%)"
+msgstr ""
+
+#: ../../include/reddav.php:1104
+msgid "Create new folder"
+msgstr ""
+
+#: ../../include/reddav.php:1107 ../../mod/mitem.php:142 ../../mod/menu.php:84
+#: ../../mod/new_channel.php:117
+msgid "Create"
+msgstr ""
+
+#: ../../include/reddav.php:1111
+msgid "Upload file"
+msgstr ""
+
+#: ../../include/reddav.php:1114 ../../mod/profile_photo.php:361
+msgid "Upload"
+msgstr ""
+
#: ../../include/features.php:23
msgid "General Features"
msgstr ""
@@ -1938,7 +2002,7 @@ msgstr ""
msgid "add"
msgstr ""
-#: ../../include/identity.php:30 ../../mod/item.php:1266
+#: ../../include/identity.php:30 ../../mod/item.php:1270
msgid "Unable to obtain identity information from database"
msgstr ""
@@ -2035,12 +2099,12 @@ msgstr ""
msgid "Gender:"
msgstr ""
-#: ../../include/identity.php:729 ../../include/identity.php:977
+#: ../../include/identity.php:729 ../../include/identity.php:996
#: ../../mod/directory.php:160
msgid "Status:"
msgstr ""
-#: ../../include/identity.php:730 ../../include/identity.php:988
+#: ../../include/identity.php:730 ../../include/identity.php:1007
#: ../../mod/directory.php:162
msgid "Homepage:"
msgstr ""
@@ -2083,7 +2147,7 @@ msgstr ""
msgid "Events this week:"
msgstr ""
-#: ../../include/identity.php:942 ../../include/identity.php:1031
+#: ../../include/identity.php:942 ../../include/identity.php:1050
#: ../../include/apps.php:128 ../../mod/profperm.php:112
msgid "Profile"
msgstr ""
@@ -2092,99 +2156,107 @@ msgstr ""
msgid "Full Name:"
msgstr ""
-#: ../../include/identity.php:962
+#: ../../include/identity.php:957
+msgid "Like this channel"
+msgstr ""
+
+#: ../../include/identity.php:981
msgid "j F, Y"
msgstr ""
-#: ../../include/identity.php:963
+#: ../../include/identity.php:982
msgid "j F"
msgstr ""
-#: ../../include/identity.php:970
+#: ../../include/identity.php:989
msgid "Birthday:"
msgstr ""
-#: ../../include/identity.php:974
+#: ../../include/identity.php:993
msgid "Age:"
msgstr ""
-#: ../../include/identity.php:983
+#: ../../include/identity.php:1002
#, php-format
msgid "for %1$d %2$s"
msgstr ""
-#: ../../include/identity.php:986 ../../mod/profiles.php:535
+#: ../../include/identity.php:1005 ../../mod/profiles.php:535
msgid "Sexual Preference:"
msgstr ""
-#: ../../include/identity.php:990 ../../mod/profiles.php:537
+#: ../../include/identity.php:1009 ../../mod/profiles.php:537
msgid "Hometown:"
msgstr ""
-#: ../../include/identity.php:992
+#: ../../include/identity.php:1011
msgid "Tags:"
msgstr ""
-#: ../../include/identity.php:994 ../../mod/profiles.php:538
+#: ../../include/identity.php:1013 ../../mod/profiles.php:538
msgid "Political Views:"
msgstr ""
-#: ../../include/identity.php:996
+#: ../../include/identity.php:1015
msgid "Religion:"
msgstr ""
-#: ../../include/identity.php:998 ../../mod/directory.php:164
+#: ../../include/identity.php:1017 ../../mod/directory.php:164
msgid "About:"
msgstr ""
-#: ../../include/identity.php:1000
+#: ../../include/identity.php:1019
msgid "Hobbies/Interests:"
msgstr ""
-#: ../../include/identity.php:1002 ../../mod/profiles.php:541
+#: ../../include/identity.php:1021 ../../mod/profiles.php:541
msgid "Likes:"
msgstr ""
-#: ../../include/identity.php:1004 ../../mod/profiles.php:542
+#: ../../include/identity.php:1023 ../../mod/profiles.php:542
msgid "Dislikes:"
msgstr ""
-#: ../../include/identity.php:1007
+#: ../../include/identity.php:1026
msgid "Contact information and Social Networks:"
msgstr ""
-#: ../../include/identity.php:1009
+#: ../../include/identity.php:1028
msgid "My other channels:"
msgstr ""
-#: ../../include/identity.php:1011
+#: ../../include/identity.php:1030
msgid "Musical interests:"
msgstr ""
-#: ../../include/identity.php:1013
+#: ../../include/identity.php:1032
msgid "Books, literature:"
msgstr ""
-#: ../../include/identity.php:1015
+#: ../../include/identity.php:1034
msgid "Television:"
msgstr ""
-#: ../../include/identity.php:1017
+#: ../../include/identity.php:1036
msgid "Film/dance/culture/entertainment:"
msgstr ""
-#: ../../include/identity.php:1019
+#: ../../include/identity.php:1038
msgid "Love/Romance:"
msgstr ""
-#: ../../include/identity.php:1021
+#: ../../include/identity.php:1040
msgid "Work/employment:"
msgstr ""
-#: ../../include/identity.php:1023
+#: ../../include/identity.php:1042
msgid "School/education:"
msgstr ""
+#: ../../include/identity.php:1052
+msgid "Like this thing"
+msgstr ""
+
#: ../../include/network.php:652
msgid "view full size"
msgstr ""
@@ -2722,13 +2794,6 @@ msgstr ""
msgid "View all"
msgstr ""
-#: ../../include/ItemObject.php:134
-msgctxt "noun"
-msgid "Like"
-msgid_plural "Likes"
-msgstr[0] ""
-msgstr[1] ""
-
#: ../../include/ItemObject.php:139
msgctxt "noun"
msgid "Dislike"
@@ -2756,11 +2821,11 @@ msgstr ""
msgid "Add Tag"
msgstr ""
-#: ../../include/ItemObject.php:208 ../../mod/photos.php:969
+#: ../../include/ItemObject.php:208 ../../mod/photos.php:974
msgid "I like this (toggle)"
msgstr ""
-#: ../../include/ItemObject.php:209 ../../mod/photos.php:970
+#: ../../include/ItemObject.php:209 ../../mod/photos.php:975
msgid "I don't like this (toggle)"
msgstr ""
@@ -2822,13 +2887,13 @@ msgstr[1] ""
msgid "[+] show all"
msgstr ""
-#: ../../include/ItemObject.php:580 ../../mod/photos.php:988
-#: ../../mod/photos.php:1075
+#: ../../include/ItemObject.php:580 ../../mod/photos.php:993
+#: ../../mod/photos.php:1080
msgid "This is you"
msgstr ""
#: ../../include/ItemObject.php:582 ../../include/js_strings.php:6
-#: ../../mod/photos.php:990 ../../mod/photos.php:1077
+#: ../../mod/photos.php:995 ../../mod/photos.php:1082
msgid "Comment"
msgstr ""
@@ -2839,15 +2904,15 @@ msgstr ""
#: ../../mod/poke.php:166 ../../mod/profiles.php:515 ../../mod/chat.php:177
#: ../../mod/chat.php:211 ../../mod/connect.php:92 ../../mod/connedit.php:476
#: ../../mod/setup.php:307 ../../mod/setup.php:350 ../../mod/pdledit.php:58
+#: ../../mod/photos.php:563 ../../mod/photos.php:668 ../../mod/photos.php:956
+#: ../../mod/photos.php:996 ../../mod/photos.php:1083
#: ../../mod/sources.php:104 ../../mod/sources.php:138
-#: ../../mod/events.php:492 ../../mod/filestorage.php:135
+#: ../../mod/events.php:492 ../../mod/filestorage.php:137
#: ../../mod/fsuggest.php:108 ../../mod/group.php:81 ../../mod/admin.php:442
-#: ../../mod/admin.php:751 ../../mod/admin.php:885 ../../mod/admin.php:1018
-#: ../../mod/admin.php:1217 ../../mod/admin.php:1304 ../../mod/thing.php:283
-#: ../../mod/thing.php:326 ../../mod/import.php:393 ../../mod/invite.php:156
-#: ../../mod/mail.php:223 ../../mod/mail.php:335 ../../mod/photos.php:563
-#: ../../mod/photos.php:668 ../../mod/photos.php:951 ../../mod/photos.php:991
-#: ../../mod/photos.php:1078 ../../mod/appman.php:99
+#: ../../mod/admin.php:751 ../../mod/admin.php:886 ../../mod/admin.php:1019
+#: ../../mod/admin.php:1218 ../../mod/admin.php:1305 ../../mod/thing.php:286
+#: ../../mod/thing.php:329 ../../mod/import.php:393 ../../mod/invite.php:156
+#: ../../mod/mail.php:223 ../../mod/mail.php:335 ../../mod/appman.php:99
#: ../../view/theme/apw/php/config.php:256
#: ../../view/theme/blogga/php/config.php:67
#: ../../view/theme/blogga/view/theme/blog/config.php:67
@@ -3253,7 +3318,7 @@ msgid "Login failed."
msgstr ""
#: ../../include/items.php:306 ../../mod/profperm.php:23
-#: ../../mod/subthread.php:49 ../../mod/group.php:68 ../../mod/like.php:63
+#: ../../mod/subthread.php:49 ../../mod/group.php:68 ../../mod/like.php:202
#: ../../index.php:360
msgid "Permission denied"
msgstr ""
@@ -3262,32 +3327,32 @@ msgstr ""
msgid "(Unknown)"
msgstr ""
-#: ../../include/items.php:3617 ../../mod/display.php:32
-#: ../../mod/filestorage.php:18 ../../mod/home.php:65 ../../mod/admin.php:159
-#: ../../mod/admin.php:922 ../../mod/admin.php:1125 ../../mod/thing.php:78
+#: ../../include/items.php:3618 ../../mod/home.php:67 ../../mod/display.php:32
+#: ../../mod/filestorage.php:18 ../../mod/admin.php:159
+#: ../../mod/admin.php:923 ../../mod/admin.php:1126 ../../mod/thing.php:78
#: ../../mod/viewsrc.php:18
msgid "Item not found."
msgstr ""
-#: ../../include/items.php:4041 ../../mod/group.php:38 ../../mod/group.php:140
+#: ../../include/items.php:4051 ../../mod/group.php:38 ../../mod/group.php:140
msgid "Collection not found."
msgstr ""
-#: ../../include/items.php:4056
+#: ../../include/items.php:4066
msgid "Collection is empty."
msgstr ""
-#: ../../include/items.php:4063
+#: ../../include/items.php:4073
#, php-format
msgid "Collection: %s"
msgstr ""
-#: ../../include/items.php:4074
+#: ../../include/items.php:4084
#, php-format
msgid "Connection: %s"
msgstr ""
-#: ../../include/items.php:4077
+#: ../../include/items.php:4087
msgid "Connection not found."
msgstr ""
@@ -3472,10 +3537,6 @@ msgstr ""
msgid "Higher numbers will sink to bottom of listing"
msgstr ""
-#: ../../mod/mitem.php:142 ../../mod/menu.php:84 ../../mod/new_channel.php:117
-msgid "Create"
-msgstr ""
-
#: ../../mod/mitem.php:154
msgid "Menu item not found."
msgstr ""
@@ -3558,7 +3619,8 @@ msgid "Add application"
msgstr ""
#: ../../mod/settings.php:517 ../../mod/settings.php:543
-#: ../../mod/admin.php:892
+#: ../../mod/admin.php:893
+#: ../../view/tpl/smarty3/compiled/de0b699d2fc212753c3f166003476a343ca00174.file.cloud_directory.tpl.php:35
msgid "Name"
msgstr ""
@@ -4027,7 +4089,7 @@ msgid "Invalid item."
msgstr ""
#: ../../mod/block.php:39 ../../mod/chanview.php:77 ../../mod/page.php:47
-#: ../../mod/home.php:52 ../../mod/wall_upload.php:28
+#: ../../mod/home.php:54 ../../mod/wall_upload.php:28
msgid "Channel not found."
msgstr ""
@@ -4075,10 +4137,6 @@ msgstr ""
msgid "Upload Profile Photo"
msgstr ""
-#: ../../mod/profile_photo.php:361
-msgid "Upload"
-msgstr ""
-
#: ../../mod/profile_photo.php:365
msgid "skip this step"
msgstr ""
@@ -4185,7 +4243,7 @@ msgstr ""
msgid "Interests"
msgstr ""
-#: ../../mod/profiles.php:337 ../../mod/admin.php:892
+#: ../../mod/profiles.php:337 ../../mod/admin.php:893
msgid "Address"
msgstr ""
@@ -4581,7 +4639,7 @@ msgstr ""
msgid "Please login."
msgstr ""
-#: ../../mod/cloud.php:112
+#: ../../mod/cloud.php:113
msgid "Red Matrix - Guests: Username: {your email address}, Password: +++"
msgstr ""
@@ -5158,7 +5216,7 @@ msgstr ""
msgid "Potential Delegates"
msgstr ""
-#: ../../mod/delegate.php:130 ../../mod/tagrm.php:93 ../../mod/photos.php:906
+#: ../../mod/delegate.php:130 ../../mod/photos.php:906 ../../mod/tagrm.php:93
msgid "Remove"
msgstr ""
@@ -5171,8 +5229,8 @@ msgid "No entries."
msgstr ""
#: ../../mod/search.php:13 ../../mod/directory.php:15
-#: ../../mod/dirprofile.php:9 ../../mod/display.php:9
-#: ../../mod/viewconnections.php:17 ../../mod/photos.php:443
+#: ../../mod/dirprofile.php:9 ../../mod/display.php:9 ../../mod/photos.php:443
+#: ../../mod/viewconnections.php:17
msgid "Public access denied."
msgstr ""
@@ -5224,6 +5282,15 @@ msgstr ""
msgid "This site is not a directory server"
msgstr ""
+#: ../../mod/home.php:81
+msgid "Red Matrix - "The Network""
+msgstr ""
+
+#: ../../mod/home.php:94
+#, php-format
+msgid "Welcome to %s"
+msgstr ""
+
#: ../../mod/setup.php:162
msgid "Red Matrix Server - Setup"
msgstr ""
@@ -5734,6 +5801,133 @@ msgstr ""
msgid "Site Administrators"
msgstr ""
+#: ../../mod/photos.php:77
+msgid "Page owner information could not be retrieved."
+msgstr ""
+
+#: ../../mod/photos.php:97
+msgid "Album not found."
+msgstr ""
+
+#: ../../mod/photos.php:119 ../../mod/photos.php:669
+msgid "Delete Album"
+msgstr ""
+
+#: ../../mod/photos.php:159 ../../mod/photos.php:957
+msgid "Delete Photo"
+msgstr ""
+
+#: ../../mod/photos.php:453
+msgid "No photos selected"
+msgstr ""
+
+#: ../../mod/photos.php:500
+msgid "Access to this item is restricted."
+msgstr ""
+
+#: ../../mod/photos.php:574
+#, php-format
+msgid "You have used %1$.2f Mbytes of %2$.2f Mbytes photo storage."
+msgstr ""
+
+#: ../../mod/photos.php:577
+#, php-format
+msgid "You have used %1$.2f Mbytes of photo storage."
+msgstr ""
+
+#: ../../mod/photos.php:596
+msgid "Upload Photos"
+msgstr ""
+
+#: ../../mod/photos.php:600 ../../mod/photos.php:664
+msgid "New album name: "
+msgstr ""
+
+#: ../../mod/photos.php:601
+msgid "or existing album name: "
+msgstr ""
+
+#: ../../mod/photos.php:602
+msgid "Do not show a status post for this upload"
+msgstr ""
+
+#: ../../mod/photos.php:653 ../../mod/photos.php:675 ../../mod/photos.php:1129
+#: ../../mod/photos.php:1144
+msgid "Contact Photos"
+msgstr ""
+
+#: ../../mod/photos.php:679
+msgid "Edit Album"
+msgstr ""
+
+#: ../../mod/photos.php:685
+msgid "Show Newest First"
+msgstr ""
+
+#: ../../mod/photos.php:687
+msgid "Show Oldest First"
+msgstr ""
+
+#: ../../mod/photos.php:730 ../../mod/photos.php:1176
+msgid "View Photo"
+msgstr ""
+
+#: ../../mod/photos.php:776
+msgid "Permission denied. Access to this item may be restricted."
+msgstr ""
+
+#: ../../mod/photos.php:778
+msgid "Photo not available"
+msgstr ""
+
+#: ../../mod/photos.php:838
+msgid "Use as profile photo"
+msgstr ""
+
+#: ../../mod/photos.php:862
+msgid "View Full Size"
+msgstr ""
+
+#: ../../mod/photos.php:940
+msgid "Edit photo"
+msgstr ""
+
+#: ../../mod/photos.php:942
+msgid "Rotate CW (right)"
+msgstr ""
+
+#: ../../mod/photos.php:943
+msgid "Rotate CCW (left)"
+msgstr ""
+
+#: ../../mod/photos.php:946
+msgid "New album name"
+msgstr ""
+
+#: ../../mod/photos.php:949
+msgid "Caption"
+msgstr ""
+
+#: ../../mod/photos.php:951
+msgid "Add a Tag"
+msgstr ""
+
+#: ../../mod/photos.php:954
+msgid "Example: @bob, @Barbara_Jensen, @jim@example.com, #California, #camping"
+msgstr ""
+
+#: ../../mod/photos.php:1107
+msgid "In This Photo:"
+msgstr ""
+
+#: ../../mod/photos.php:1182
+msgid "View Album"
+msgstr ""
+
+#: ../../mod/photos.php:1191
+msgid "Recent Photos"
+msgstr ""
+
#: ../../mod/sources.php:32
msgid "Failed to create source. No channel selected."
msgstr ""
@@ -5875,46 +6069,30 @@ msgstr ""
msgid "File not found."
msgstr ""
-#: ../../mod/filestorage.php:121
+#: ../../mod/filestorage.php:122
msgid "Edit file permissions"
msgstr ""
-#: ../../mod/filestorage.php:129
+#: ../../mod/filestorage.php:131
msgid "Set/edit permissions"
msgstr ""
-#: ../../mod/filestorage.php:130
+#: ../../mod/filestorage.php:132
msgid "Include all files and sub folders"
msgstr ""
-#: ../../mod/filestorage.php:131
+#: ../../mod/filestorage.php:133
msgid "Return to file list"
msgstr ""
-#: ../../mod/filestorage.php:133
+#: ../../mod/filestorage.php:135
msgid "Copy/paste this code to attach file to a post"
msgstr ""
-#: ../../mod/filestorage.php:134
+#: ../../mod/filestorage.php:136
msgid "Copy/paste this URL to link file from a web page"
msgstr ""
-#: ../../mod/filestorage.php:171
-msgid "Download"
-msgstr ""
-
-#: ../../mod/filestorage.php:177
-msgid "Used: "
-msgstr ""
-
-#: ../../mod/filestorage.php:178
-msgid "[directory]"
-msgstr ""
-
-#: ../../mod/filestorage.php:180
-msgid "Limit: "
-msgstr ""
-
#: ../../mod/follow.php:25
msgid "Channel added."
msgstr ""
@@ -6020,15 +6198,6 @@ msgstr ""
msgid "Select a tag to remove: "
msgstr ""
-#: ../../mod/home.php:79
-msgid "Red Matrix - "The Network""
-msgstr ""
-
-#: ../../mod/home.php:92
-#, php-format
-msgid "Welcome to %s"
-msgstr ""
-
#: ../../mod/admin.php:52
msgid "Theme settings updated."
msgstr ""
@@ -6041,15 +6210,15 @@ msgstr ""
msgid "Accounts"
msgstr ""
-#: ../../mod/admin.php:94 ../../mod/admin.php:884
+#: ../../mod/admin.php:94 ../../mod/admin.php:885
msgid "Channels"
msgstr ""
-#: ../../mod/admin.php:95 ../../mod/admin.php:975 ../../mod/admin.php:1017
+#: ../../mod/admin.php:95 ../../mod/admin.php:976 ../../mod/admin.php:1018
msgid "Plugins"
msgstr ""
-#: ../../mod/admin.php:96 ../../mod/admin.php:1180 ../../mod/admin.php:1216
+#: ../../mod/admin.php:96 ../../mod/admin.php:1181 ../../mod/admin.php:1217
msgid "Themes"
msgstr ""
@@ -6061,7 +6230,7 @@ msgstr ""
msgid "DB updates"
msgstr ""
-#: ../../mod/admin.php:112 ../../mod/admin.php:119 ../../mod/admin.php:1303
+#: ../../mod/admin.php:112 ../../mod/admin.php:119 ../../mod/admin.php:1304
msgid "Logs"
msgstr ""
@@ -6078,9 +6247,9 @@ msgid "Message queues"
msgstr ""
#: ../../mod/admin.php:202 ../../mod/admin.php:440 ../../mod/admin.php:540
-#: ../../mod/admin.php:749 ../../mod/admin.php:883 ../../mod/admin.php:974
-#: ../../mod/admin.php:1016 ../../mod/admin.php:1179 ../../mod/admin.php:1215
-#: ../../mod/admin.php:1302
+#: ../../mod/admin.php:749 ../../mod/admin.php:884 ../../mod/admin.php:975
+#: ../../mod/admin.php:1017 ../../mod/admin.php:1180 ../../mod/admin.php:1216
+#: ../../mod/admin.php:1303
msgid "Administration"
msgstr ""
@@ -6437,7 +6606,7 @@ msgstr ""
msgid "Users"
msgstr ""
-#: ../../mod/admin.php:752 ../../mod/admin.php:886
+#: ../../mod/admin.php:752 ../../mod/admin.php:887
msgid "select all"
msgstr ""
@@ -6489,131 +6658,131 @@ msgid ""
"site will be permanently deleted!\\n\\nAre you sure?"
msgstr ""
-#: ../../mod/admin.php:798
+#: ../../mod/admin.php:799
#, php-format
msgid "%s channel censored/uncensored"
msgid_plural "%s channelss censored/uncensored"
msgstr[0] ""
msgstr[1] ""
-#: ../../mod/admin.php:805
+#: ../../mod/admin.php:806
#, php-format
msgid "%s channel deleted"
msgid_plural "%s channels deleted"
msgstr[0] ""
msgstr[1] ""
-#: ../../mod/admin.php:824
+#: ../../mod/admin.php:825
msgid "Channel not found"
msgstr ""
-#: ../../mod/admin.php:835
+#: ../../mod/admin.php:836
#, php-format
msgid "Channel '%s' deleted"
msgstr ""
-#: ../../mod/admin.php:845
+#: ../../mod/admin.php:846
#, php-format
msgid "Channel '%s' uncensored"
msgstr ""
-#: ../../mod/admin.php:845
+#: ../../mod/admin.php:846
#, php-format
msgid "Channel '%s' censored"
msgstr ""
-#: ../../mod/admin.php:888
+#: ../../mod/admin.php:889
msgid "Censor"
msgstr ""
-#: ../../mod/admin.php:889
+#: ../../mod/admin.php:890
msgid "Uncensor"
msgstr ""
-#: ../../mod/admin.php:892
+#: ../../mod/admin.php:893
msgid "UID"
msgstr ""
-#: ../../mod/admin.php:894
+#: ../../mod/admin.php:895
msgid ""
"Selected channels will be deleted!\\n\\nEverything that was posted in these "
"channels on this site will be permanently deleted!\\n\\nAre you sure?"
msgstr ""
-#: ../../mod/admin.php:895
+#: ../../mod/admin.php:896
msgid ""
"The channel {0} will be deleted!\\n\\nEverything that was posted in this "
"channel on this site will be permanently deleted!\\n\\nAre you sure?"
msgstr ""
-#: ../../mod/admin.php:934
+#: ../../mod/admin.php:935
#, php-format
msgid "Plugin %s disabled."
msgstr ""
-#: ../../mod/admin.php:938
+#: ../../mod/admin.php:939
#, php-format
msgid "Plugin %s enabled."
msgstr ""
-#: ../../mod/admin.php:948 ../../mod/admin.php:1150
+#: ../../mod/admin.php:949 ../../mod/admin.php:1151
msgid "Disable"
msgstr ""
-#: ../../mod/admin.php:950 ../../mod/admin.php:1152
+#: ../../mod/admin.php:951 ../../mod/admin.php:1153
msgid "Enable"
msgstr ""
-#: ../../mod/admin.php:976 ../../mod/admin.php:1181
+#: ../../mod/admin.php:977 ../../mod/admin.php:1182
msgid "Toggle"
msgstr ""
-#: ../../mod/admin.php:984 ../../mod/admin.php:1191
+#: ../../mod/admin.php:985 ../../mod/admin.php:1192
msgid "Author: "
msgstr ""
-#: ../../mod/admin.php:985 ../../mod/admin.php:1192
+#: ../../mod/admin.php:986 ../../mod/admin.php:1193
msgid "Maintainer: "
msgstr ""
-#: ../../mod/admin.php:1114
+#: ../../mod/admin.php:1115
msgid "No themes found."
msgstr ""
-#: ../../mod/admin.php:1173
+#: ../../mod/admin.php:1174
msgid "Screenshot"
msgstr ""
-#: ../../mod/admin.php:1221
+#: ../../mod/admin.php:1222
msgid "[Experimental]"
msgstr ""
-#: ../../mod/admin.php:1222
+#: ../../mod/admin.php:1223
msgid "[Unsupported]"
msgstr ""
-#: ../../mod/admin.php:1249
+#: ../../mod/admin.php:1250
msgid "Log settings updated."
msgstr ""
-#: ../../mod/admin.php:1305
+#: ../../mod/admin.php:1306
msgid "Clear"
msgstr ""
-#: ../../mod/admin.php:1311
+#: ../../mod/admin.php:1312
msgid "Debugging"
msgstr ""
-#: ../../mod/admin.php:1312
+#: ../../mod/admin.php:1313
msgid "Log file"
msgstr ""
-#: ../../mod/admin.php:1312
+#: ../../mod/admin.php:1313
msgid ""
"Must be writable by web server. Relative to your Red top-level directory."
msgstr ""
-#: ../../mod/admin.php:1313
+#: ../../mod/admin.php:1314
msgid "Log level"
msgstr ""
@@ -6642,39 +6811,35 @@ msgstr ""
msgid "item not found."
msgstr ""
-#: ../../mod/thing.php:269
+#: ../../mod/thing.php:272
msgid "Edit Thing"
msgstr ""
-#: ../../mod/thing.php:271 ../../mod/thing.php:318
+#: ../../mod/thing.php:274 ../../mod/thing.php:321
msgid "Select a profile"
msgstr ""
-#: ../../mod/thing.php:273 ../../mod/thing.php:320
-msgid "Select a category of stuff. e.g. I ______ something"
-msgstr ""
-
-#: ../../mod/thing.php:275 ../../mod/thing.php:321
+#: ../../mod/thing.php:278 ../../mod/thing.php:324
msgid "Post an activity"
msgstr ""
-#: ../../mod/thing.php:275 ../../mod/thing.php:321
+#: ../../mod/thing.php:278 ../../mod/thing.php:324
msgid "Only sends to viewers of the applicable profile"
msgstr ""
-#: ../../mod/thing.php:277 ../../mod/thing.php:323
+#: ../../mod/thing.php:280 ../../mod/thing.php:326
msgid "Name of thing e.g. something"
msgstr ""
-#: ../../mod/thing.php:279 ../../mod/thing.php:324
+#: ../../mod/thing.php:282 ../../mod/thing.php:327
msgid "URL of thing (optional)"
msgstr ""
-#: ../../mod/thing.php:281 ../../mod/thing.php:325
+#: ../../mod/thing.php:284 ../../mod/thing.php:328
msgid "URL for photo of thing (optional)"
msgstr ""
-#: ../../mod/thing.php:316
+#: ../../mod/thing.php:319
msgid "Add Thing to your Profile"
msgstr ""
@@ -6844,16 +7009,16 @@ msgstr ""
msgid "Executable content type not permitted to this channel."
msgstr ""
-#: ../../mod/item.php:828
+#: ../../mod/item.php:832
msgid "System error. Post not saved."
msgstr ""
-#: ../../mod/item.php:1271
+#: ../../mod/item.php:1275
#, php-format
msgid "You have reached your limit of %1$.0f top level posts."
msgstr ""
-#: ../../mod/item.php:1277
+#: ../../mod/item.php:1281
#, php-format
msgid "You have reached your limit of %1$.0f webpages."
msgstr ""
@@ -6871,6 +7036,10 @@ msgstr ""
msgid "Layout Name"
msgstr ""
+#: ../../mod/like.php:97
+msgid "thing"
+msgstr ""
+
#: ../../mod/lockview.php:30 ../../mod/lockview.php:36
msgid "Remote privacy information not available."
msgstr ""
@@ -6916,7 +7085,7 @@ msgid ""
"Password reset failed."
msgstr ""
-#: ../../mod/lostpass.php:85 ../../boot.php:1467
+#: ../../mod/lostpass.php:85 ../../boot.php:1475
msgid "Password Reset"
msgstr ""
@@ -7229,133 +7398,6 @@ msgid ""
"Or import an existing channel from another location"
msgstr ""
-#: ../../mod/photos.php:77
-msgid "Page owner information could not be retrieved."
-msgstr ""
-
-#: ../../mod/photos.php:97
-msgid "Album not found."
-msgstr ""
-
-#: ../../mod/photos.php:119 ../../mod/photos.php:669
-msgid "Delete Album"
-msgstr ""
-
-#: ../../mod/photos.php:159 ../../mod/photos.php:952
-msgid "Delete Photo"
-msgstr ""
-
-#: ../../mod/photos.php:453
-msgid "No photos selected"
-msgstr ""
-
-#: ../../mod/photos.php:500
-msgid "Access to this item is restricted."
-msgstr ""
-
-#: ../../mod/photos.php:574
-#, php-format
-msgid "You have used %1$.2f Mbytes of %2$.2f Mbytes photo storage."
-msgstr ""
-
-#: ../../mod/photos.php:577
-#, php-format
-msgid "You have used %1$.2f Mbytes of photo storage."
-msgstr ""
-
-#: ../../mod/photos.php:596
-msgid "Upload Photos"
-msgstr ""
-
-#: ../../mod/photos.php:600 ../../mod/photos.php:664
-msgid "New album name: "
-msgstr ""
-
-#: ../../mod/photos.php:601
-msgid "or existing album name: "
-msgstr ""
-
-#: ../../mod/photos.php:602
-msgid "Do not show a status post for this upload"
-msgstr ""
-
-#: ../../mod/photos.php:653 ../../mod/photos.php:675 ../../mod/photos.php:1124
-#: ../../mod/photos.php:1139
-msgid "Contact Photos"
-msgstr ""
-
-#: ../../mod/photos.php:679
-msgid "Edit Album"
-msgstr ""
-
-#: ../../mod/photos.php:685
-msgid "Show Newest First"
-msgstr ""
-
-#: ../../mod/photos.php:687
-msgid "Show Oldest First"
-msgstr ""
-
-#: ../../mod/photos.php:730 ../../mod/photos.php:1171
-msgid "View Photo"
-msgstr ""
-
-#: ../../mod/photos.php:776
-msgid "Permission denied. Access to this item may be restricted."
-msgstr ""
-
-#: ../../mod/photos.php:778
-msgid "Photo not available"
-msgstr ""
-
-#: ../../mod/photos.php:838
-msgid "Use as profile photo"
-msgstr ""
-
-#: ../../mod/photos.php:862
-msgid "View Full Size"
-msgstr ""
-
-#: ../../mod/photos.php:936
-msgid "Edit photo"
-msgstr ""
-
-#: ../../mod/photos.php:938
-msgid "Rotate CW (right)"
-msgstr ""
-
-#: ../../mod/photos.php:939
-msgid "Rotate CCW (left)"
-msgstr ""
-
-#: ../../mod/photos.php:941
-msgid "New album name"
-msgstr ""
-
-#: ../../mod/photos.php:944
-msgid "Caption"
-msgstr ""
-
-#: ../../mod/photos.php:946
-msgid "Add a Tag"
-msgstr ""
-
-#: ../../mod/photos.php:949
-msgid "Example: @bob, @Barbara_Jensen, @jim@example.com, #California, #camping"
-msgstr ""
-
-#: ../../mod/photos.php:1102
-msgid "In This Photo:"
-msgstr ""
-
-#: ../../mod/photos.php:1177
-msgid "View Album"
-msgstr ""
-
-#: ../../mod/photos.php:1186
-msgid "Recent Photos"
-msgstr ""
-
#: ../../mod/notifications.php:26
msgid "Invalid request identifier."
msgstr ""
@@ -7717,41 +7759,61 @@ msgstr ""
msgid "Are you a clean desk or a messy desk person?"
msgstr ""
-#: ../../boot.php:1265
+#: ../../view/tpl/smarty3/compiled/de0b699d2fc212753c3f166003476a343ca00174.file.cloud_directory.tpl.php:38
+msgid "Type"
+msgstr ""
+
+#: ../../view/tpl/smarty3/compiled/de0b699d2fc212753c3f166003476a343ca00174.file.cloud_directory.tpl.php:40
+msgid "Size"
+msgstr ""
+
+#: ../../view/tpl/smarty3/compiled/de0b699d2fc212753c3f166003476a343ca00174.file.cloud_directory.tpl.php:42
+msgid "Last modified"
+msgstr ""
+
+#: ../../view/tpl/smarty3/compiled/de0b699d2fc212753c3f166003476a343ca00174.file.cloud_directory.tpl.php:85
+msgid "Are you sure you want to delete this item?"
+msgstr ""
+
+#: ../../view/tpl/smarty3/compiled/de0b699d2fc212753c3f166003476a343ca00174.file.cloud_directory.tpl.php:103
+msgid "Total"
+msgstr ""
+
+#: ../../boot.php:1273
#, php-format
msgid "Update %s failed. See error logs."
msgstr ""
-#: ../../boot.php:1268
+#: ../../boot.php:1276
#, php-format
msgid "Update Error at %s"
msgstr ""
-#: ../../boot.php:1432
+#: ../../boot.php:1440
msgid ""
"Create an account to access services and applications within the Red Matrix"
msgstr ""
-#: ../../boot.php:1460
+#: ../../boot.php:1468
msgid "Password"
msgstr ""
-#: ../../boot.php:1461
+#: ../../boot.php:1469
msgid "Remember me"
msgstr ""
-#: ../../boot.php:1466
+#: ../../boot.php:1474
msgid "Forgot your password?"
msgstr ""
-#: ../../boot.php:1531
+#: ../../boot.php:1539
msgid "permission denied"
msgstr ""
-#: ../../boot.php:1532
+#: ../../boot.php:1540
msgid "Got Zot?"
msgstr ""
-#: ../../boot.php:1962
+#: ../../boot.php:1970
msgid "toggle mobile"
msgstr ""
diff --git a/vendor/autoload.php b/vendor/autoload.php
index 4ab3c99bc..655527c54 100644
--- a/vendor/autoload.php
+++ b/vendor/autoload.php
@@ -4,4 +4,4 @@
require_once __DIR__ . '/composer' . '/autoload_real.php';
-return ComposerAutoloaderInitd0f40897631bfac5572c9d06d82344bf::getLoader();
+return ComposerAutoloaderInita478c0bdc9041edcc4f485e8fb39b90d::getLoader();
diff --git a/vendor/composer/ClassLoader.php b/vendor/composer/ClassLoader.php
index a71055531..88684c526 100644
--- a/vendor/composer/ClassLoader.php
+++ b/vendor/composer/ClassLoader.php
@@ -202,10 +202,11 @@ class ClassLoader
* Registers a set of PSR-4 directories for a given namespace,
* replacing any others previously set for this namespace.
*
- * @param string $prefix The prefix/namespace, with trailing '\\'
- * @param array|string $paths The PSR-4 base directories
+ * @param string $prefix The prefix/namespace, with trailing '\\'
+ * @param array|string $paths The PSR-4 base directories
*/
- public function setPsr4($prefix, $paths) {
+ public function setPsr4($prefix, $paths)
+ {
if (!$prefix) {
$this->fallbackDirsPsr4 = (array) $paths;
} else {
diff --git a/vendor/composer/autoload_namespaces.php b/vendor/composer/autoload_namespaces.php
index a3c1e111b..e64e0a875 100644
--- a/vendor/composer/autoload_namespaces.php
+++ b/vendor/composer/autoload_namespaces.php
@@ -12,5 +12,4 @@ return array(
'Sabre\\DAV' => array($vendorDir . '/sabre/dav/lib'),
'Sabre\\CardDAV' => array($vendorDir . '/sabre/dav/lib'),
'Sabre\\CalDAV' => array($vendorDir . '/sabre/dav/lib'),
- 'Monolog' => array($vendorDir . '/monolog/monolog/src'),
);
diff --git a/vendor/composer/autoload_real.php b/vendor/composer/autoload_real.php
index 33803553e..09fa3b8c0 100644
--- a/vendor/composer/autoload_real.php
+++ b/vendor/composer/autoload_real.php
@@ -2,7 +2,7 @@
// autoload_real.php @generated by Composer
-class ComposerAutoloaderInitd0f40897631bfac5572c9d06d82344bf
+class ComposerAutoloaderInita478c0bdc9041edcc4f485e8fb39b90d
{
private static $loader;
@@ -19,12 +19,9 @@ class ComposerAutoloaderInitd0f40897631bfac5572c9d06d82344bf
return self::$loader;
}
- spl_autoload_register(array('ComposerAutoloaderInitd0f40897631bfac5572c9d06d82344bf', 'loadClassLoader'), true, true);
+ spl_autoload_register(array('ComposerAutoloaderInita478c0bdc9041edcc4f485e8fb39b90d', 'loadClassLoader'), true, true);
self::$loader = $loader = new \Composer\Autoload\ClassLoader();
- spl_autoload_unregister(array('ComposerAutoloaderInitd0f40897631bfac5572c9d06d82344bf', 'loadClassLoader'));
-
- $vendorDir = dirname(__DIR__);
- $baseDir = dirname($vendorDir);
+ spl_autoload_unregister(array('ComposerAutoloaderInita478c0bdc9041edcc4f485e8fb39b90d', 'loadClassLoader'));
$map = require __DIR__ . '/autoload_namespaces.php';
foreach ($map as $namespace => $path) {
@@ -47,7 +44,7 @@ class ComposerAutoloaderInitd0f40897631bfac5572c9d06d82344bf
}
}
-function composerRequired0f40897631bfac5572c9d06d82344bf($file)
+function composerRequirea478c0bdc9041edcc4f485e8fb39b90d($file)
{
require $file;
}
diff --git a/vendor/composer/installed.json b/vendor/composer/installed.json
index bd9d342fb..42f46fb2c 100644
--- a/vendor/composer/installed.json
+++ b/vendor/composer/installed.json
@@ -1,49 +1,4 @@
[
- {
- "name": "monolog/monolog",
- "version": "1.0.2",
- "version_normalized": "1.0.2.0",
- "source": {
- "type": "git",
- "url": "https://github.com/Seldaek/monolog.git",
- "reference": "b704c49a3051536f67f2d39f13568f74615b9922"
- },
- "dist": {
- "type": "zip",
- "url": "https://api.github.com/repos/Seldaek/monolog/zipball/b704c49a3051536f67f2d39f13568f74615b9922",
- "reference": "b704c49a3051536f67f2d39f13568f74615b9922",
- "shasum": ""
- },
- "require": {
- "php": ">=5.3.0"
- },
- "time": "2011-10-24 09:39:02",
- "type": "library",
- "installation-source": "dist",
- "autoload": {
- "psr-0": {
- "Monolog": "src/"
- }
- },
- "notification-url": "https://packagist.org/downloads/",
- "license": [
- "MIT"
- ],
- "authors": [
- {
- "name": "Jordi Boggiano",
- "email": "j.boggiano@seld.be",
- "homepage": "http://seld.be",
- "role": "Developer"
- }
- ],
- "description": "Logging for PHP 5.3",
- "homepage": "http://github.com/Seldaek/monolog",
- "keywords": [
- "log",
- "logging"
- ]
- },
{
"name": "sabre/vobject",
"version": "2.1.4",
@@ -96,17 +51,17 @@
},
{
"name": "sabre/dav",
- "version": "1.8.9",
- "version_normalized": "1.8.9.0",
+ "version": "1.8.10",
+ "version_normalized": "1.8.10.0",
"source": {
"type": "git",
"url": "https://github.com/fruux/sabre-dav.git",
- "reference": "25e095469e44d195cd255bdce55ce473224558bc"
+ "reference": "0d064536ed3c7974e486b6ebb5b17ad7a974fe18"
},
"dist": {
"type": "zip",
- "url": "https://api.github.com/repos/fruux/sabre-dav/zipball/25e095469e44d195cd255bdce55ce473224558bc",
- "reference": "25e095469e44d195cd255bdce55ce473224558bc",
+ "url": "https://api.github.com/repos/fruux/sabre-dav/zipball/0d064536ed3c7974e486b6ebb5b17ad7a974fe18",
+ "reference": "0d064536ed3c7974e486b6ebb5b17ad7a974fe18",
"shasum": ""
},
"require": {
@@ -127,15 +82,14 @@
},
"require-dev": {
"evert/phpdoc-md": "~0.0.7",
- "phing/phing": "2.4.14",
- "phpunit/phpunit": "3.7.*"
+ "phpunit/phpunit": "~4.0.0"
},
"suggest": {
"ext-apc": "*",
"ext-curl": "*",
"ext-pdo": "*"
},
- "time": "2014-02-26 22:17:11",
+ "time": "2014-05-16 00:14:02",
"bin": [
"bin/sabredav"
],
@@ -157,7 +111,7 @@
"authors": [
{
"name": "Evert Pot",
- "email": "evert@rooftopsolutions.nl",
+ "email": "me@evertpot.com",
"homepage": "http://evertpot.com/",
"role": "Developer"
}
diff --git a/vendor/sabre/dav/.travis.yml b/vendor/sabre/dav/.travis.yml
index baffa5b97..9c98702f0 100644
--- a/vendor/sabre/dav/.travis.yml
+++ b/vendor/sabre/dav/.travis.yml
@@ -17,6 +17,7 @@ services:
before_script:
- mysql -e 'create database sabredav'
+ - composer self-update
- composer install --prefer-source
# - echo "zend.enable_gc=0" >> `php --ini | grep "Loaded Configuration" | sed -e "s|.*:\s*||"`
diff --git a/vendor/sabre/dav/ChangeLog b/vendor/sabre/dav/ChangeLog
index e41a6c88a..92fe1a231 100644
--- a/vendor/sabre/dav/ChangeLog
+++ b/vendor/sabre/dav/ChangeLog
@@ -1,3 +1,7 @@
+1.8.10-stable (2014-05-15)
+ * The zip release ships with sabre/vobject 2.1.4.
+ * includes changes from version 1.7.12.
+
1.8.9-stable (2014-02-26)
* The zip release ships with sabre/vobject 2.1.3.
* includes changes from version 1.7.11.
@@ -57,6 +61,26 @@
* Added: The Proxy principal classes now both implement an interface, for
greater flexiblity.
+1.7.13-stable (????-??-??)
+ * Changed: Removed phing and went with a custom build script for now.
+
+1.7.12-stable (2014-05-15)
+ * The zip release ships with sabre/vobject 2.1.4.
+ * Updated: Issue #439. Lots of updates in PATCH support. The
+ Sabre_DAV_PartialUpdate_IFile interface is now deprecated and will be
+ removed in a future version.
+ * Fixed: Restoring old setting after changing
+ libxml_disable_entity_loader.
+ * Fixed: Issue #422: Preconditions were not being set on PUT on non-
+ existant files. Not really a chance for data-loss, but incorrect
+ nevertheless.
+ * Fixed: Issue #427: Now checking preconditions on DELETE requests.
+ * Fixed: Issue #428: Etag check with If: fails if the target is a
+ collection.
+ * Fixed: Issue #393: PATCH request with missing end-range was handled
+ incorrectly.
+ * Added: Sabre_DAV_Exception_LengthRequired to omit 411 errors.
+
1.7.11-stable (2014-02-26)
* The zip release ships with sabre/vobject 2.1.3.
* Fixed: Issue #407: large downloads failed.
diff --git a/vendor/sabre/dav/bin/build.php b/vendor/sabre/dav/bin/build.php
new file mode 100644
index 000000000..11cca1e61
--- /dev/null
+++ b/vendor/sabre/dav/bin/build.php
@@ -0,0 +1,137 @@
+ [
+ 'init', 'test', 'clean',
+ ],
+ 'markrelease' => [
+ 'init', 'test', 'clean',
+ ],
+ 'clean' => [],
+ 'test' => [
+ 'composerupdate',
+ ],
+ 'init' => [],
+ 'composerupdate' => [],
+ ];
+
+$default = 'buildzip';
+
+$baseDir = __DIR__ . '/../';
+chdir($baseDir);
+
+$currentTask = $default;
+if ($argc > 1) $currentTask = $argv[1];
+$version = null;
+if ($argc > 2) $version = $argv[2];
+
+if (!isset($tasks[$currentTask])) {
+ echo "Task not found: ", $currentTask, "\n";
+ die(1);
+}
+
+// Creating the dependency graph
+$newTaskList = [];
+$oldTaskList = [$currentTask => true];
+
+while(count($oldTaskList)>0) {
+
+ foreach($oldTaskList as $task=>$foo) {
+
+ if (!isset($tasks[$task])) {
+ echo "Dependency not found: " . $task, "\n";
+ die(1);
+ }
+ $dependencies = $tasks[$task];
+
+ $fullFilled = true;
+ foreach($dependencies as $dependency) {
+ if (isset($newTaskList[$dependency])) {
+ // Already in the fulfilled task list.
+ continue;
+ } else {
+ $oldTaskList[$dependency] = true;
+ $fullFilled = false;
+ }
+
+ }
+ if ($fullFilled) {
+ unset($oldTaskList[$task]);
+ $newTaskList[$task] = 1;
+ }
+
+ }
+
+}
+
+foreach(array_keys($newTaskList) as $task) {
+
+ echo "task: " . $task, "\n";
+ call_user_func($task);
+ echo "\n";
+
+}
+
+function init() {
+
+ global $version;
+ if (!$version) {
+ include __DIR__ . '/../vendor/autoload.php';
+ $version = Sabre\DAV\Version::VERSION;
+ }
+
+ echo " Building sabre/dav " . $version, "\n";
+
+}
+
+function clean() {
+
+ global $baseDir;
+ echo " Removing build files\n";
+ $outputDir = $baseDir . '/build/SabreDAV';
+ if (is_dir($outputDir)) {
+ system('rm -r ' . $baseDir . '/build/SabreDAV');
+ }
+
+}
+
+function composerupdate() {
+
+ global $baseDir;
+ echo " Updating composer packages to latest version\n\n";
+ system('cd ' . $baseDir . '; composer update --dev');
+}
+
+function test() {
+
+ global $baseDir;
+
+ echo " Running all unittests.\n";
+ echo " This may take a while.\n\n";
+ system(__DIR__ . '/phpunit --configuration ' . $baseDir . '/tests/phpunit.xml --stop-on-failure', $code);
+ if ($code != 0) {
+ echo "PHPUnit reported error code $code\n";
+ die(1);
+ }
+
+}
+
+function buildzip() {
+
+ global $baseDir, $version;
+ echo " Asking composer to download sabre/dav $version\n\n";
+ system("composer create-project --no-dev sabre/dav build/SabreDAV $version", $code);
+ if ($code!==0) {
+ echo "Composer reported error code $code\n";
+ die(1);
+ }
+ //
+
+ echo "\n";
+ echo "Zipping the sabredav distribution\n\n";
+ system('cd build; zip -qr sabredav-' . $version . '.zip SabreDAV');
+
+ echo "Done.";
+
+}
diff --git a/vendor/sabre/dav/build.xml b/vendor/sabre/dav/build.xml
deleted file mode 100644
index 0f70f8199..000000000
--- a/vendor/sabre/dav/build.xml
+++ /dev/null
@@ -1,72 +0,0 @@
-
-
-
-
-
-
-
-
-
-
-
- Running composer
-
-
-
-
-
-
-
-
-
-
-
- Creating Git release tag
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Creating api documentation using PHP documentor
- Writing to ${sabredav.apidocspath}
-
-
-
-
-
-
-
-
-
- getProject()->setNewProperty('sabredav.version',\Sabre\DAV\Version::VERSION);
- $this->getProject()->setNewProperty('sabredav.stability',\Sabre\DAV\Version::STABILITY);
- $this->getProject()->setNewProperty('sabredav.ucstability',ucwords(Sabre\DAV\Version::STABILITY));
-
- }
-
- }
-
- ]]>
-
- SabreDAV version ${sabredav.version}
-
-
-
-
diff --git a/vendor/sabre/dav/docs/caldav-ctag.txt b/vendor/sabre/dav/docs/caldav-ctag.txt
deleted file mode 100644
index 4787ca260..000000000
--- a/vendor/sabre/dav/docs/caldav-ctag.txt
+++ /dev/null
@@ -1,336 +0,0 @@
-
-
-
-Calendar Server Extension C. Daboo
- Apple
- May 3, 2007
-
-
- Calendar Collection Entity Tag (CTag) in CalDAV
- caldav-ctag-02
-
-Abstract
-
- This specification defines an extension to CalDAV that provides a
- fast way for a client to determine whether the contents of a calendar
- collection may have changed.
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
- 2. Conventions Used in This Document . . . . . . . . . . . . . . . 2
- 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 3.1. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 3.2. Client . . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 4. New features in CalDAV . . . . . . . . . . . . . . . . . . . . 3
- 4.1. getctag WebDAV Property . . . . . . . . . . . . . . . . . . 4
- 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
- 7. Normative References . . . . . . . . . . . . . . . . . . . . . 5
- Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 5
- Appendix B. Change History . . . . . . . . . . . . . . . . . . . . 5
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo [Page 1]
-
- CalDAV Proxy May 2007
-
-
-1. Introduction
-
- In CalDAV [RFC4791] calendar data is stored in calendar collection
- resources. Clients need to "poll" calendar collections in order to
- find out what has changed since the last time they examined it.
- Currently that involves having to do a PROPFIND Depth:1 HTTP request,
- or a CALDAV:calendar-query REPORT request. When a calendar
- collection contains a large number of calendar resources those
- operations become expensive on the server.
-
- Calendar users often configure their clients to poll at short time
- intervals. So polling traffic to the server will be high, even
- though the frequency at which changes actually occur to a calendar is
- typically low.
-
- To improve on performance, this specification defines a new "calendar
- collection entity tag" (CTag) WebDAV property that is defined on
- calendar collections. When the calendar collection changes, the CTag
- value changes. Thus a client can cache the CTag at some point in
- time, then poll the collection only (i.e. PROPFIND Depth:0 HTTP
- requests) and determine if a change has happened based on the
- returned CTag value. If there is a change, it can then fall back to
- doing the full (Depth:1) poll of the collection to actually determine
- which resources in the collection changed.
-
- This extension also defines CTag's on CalDAV scheduling
- [I-D.desruisseaux-caldav-sched] Inbox and Outbox collections.
-
-
-2. Conventions Used in This Document
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
- When XML element types in the namespaces "DAV:" and
- "urn:ietf:params:xml:ns:caldav" are referenced in this document
- outside of the context of an XML fragment, the string "DAV:" and
- "CALDAV:" will be prefixed to the element type names respectively.
-
- The namespace "http://calendarserver.org/ns/" is used for XML
- elements defined in this specification. When XML element types in
- this namespace are referenced in this document outside of the context
- of an XML fragment, the string "CS:" will be prefixed to the element
- type names respectively.
-
-
-
-
-
-
-Daboo [Page 2]
-
- CalDAV Proxy May 2007
-
-
-3. Overview
-
-3.1. Server
-
- For each calendar or scheduling Inbox or Outbox collection on the
- server, a new CS:getctag WebDAV property is present.
-
- The property value is an "opaque" token whose value is guaranteed to
- be unique over the lifetime of any calendar or scheduling Inbox or
- Outbox collection at a specific URI.
-
- Whenever a calendar resource is added to, modified or deleted from
- the calendar collection, the value of the CS:getctag property MUST
- change. Typically this change will occur when the DAV:getetag
- property on a child resource changes due to some protocol action. It
- could be the result of a change to the body or properties of the
- resource.
-
-3.2. Client
-
- The client starts off with an empty string as the initial value for
- the cached CTag of a calendar or scheduling Inbox or Outbox
- collection that it intends to synchronize with.
-
- When polling a calendar or scheduling Inbox or Outbox collection, the
- client issues a PROPFIND Depth:0 HTTP request, asking for the CS:
- getctag property to be returned.
-
- If the returned value of CS:getctag property matches the one
- currently cached for the calendar or scheduling Inbox or Outbox
- collection, then the collection contents have not changed and no
- further action is required until the next poll.
-
- If the returned value of CS:getctag property does not match the one
- found previously, then the contents of the calendar or scheduling
- Inbox or Outbox collection have changed. At that point the client
- should re-issue the PROPFIND Depth:1 request to get the collection
- changes in detail and the CS:getctag property value corresponding to
- the new state. The new CSgetctag property value should replace the
- one currently cached for that calendar or scheduling Inbox or Outbox
- collection.
-
-
-4. New features in CalDAV
-
-
-
-
-
-
-
-Daboo [Page 3]
-
- CalDAV Proxy May 2007
-
-
-4.1. getctag WebDAV Property
-
- Name: getctag
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Specifies a "synchronization" token used to indicate when
- the contents of a calendar or scheduling Inbox or Outbox
- collection have changed.
-
- Conformance: This property MUST be defined on a calendar or
- scheduling Inbox or Outbox collection resource. It MUST be
- protected and SHOULD be returned by a PROPFIND DAV:allprop request
- (as defined in Section 12.14.1 of [RFC2518]).
-
- Description: The CS:getctag property allows clients to quickly
- determine if the contents of a calendar or scheduling Inbox or
- Outbox collection have changed since the last time a
- "synchronization" operation was done. The CS:getctag property
- value MUST change each time the contents of the calendar or
- scheduling Inbox or Outbox collection change, and each change MUST
- result in a value that is different from any other used with that
- collection URI.
-
- Definition:
-
-
-
- Example:
-
- ABCD-GUID-IN-THIS-COLLECTION-20070228T122324010340
-
-
-5. Security Considerations
-
- The CS:getctag property value changes whenever any resource in the
- collection or scheduling Inbox or Outbox changes. Thus a change to a
- resource that a user does not have read access to will result in a
- change in the CTag and the user will know that a change occurred.
- However, that user will not able to get additional details about
- exactly what changed as WebDAV ACLs [RFC3744] will prevent that. So
- this does expose the fact that there are potentially "hidden"
- resources in a calendar collection, but it does not expose any
- details about them.
-
-
-
-
-
-
-Daboo [Page 4]
-
- CalDAV Proxy May 2007
-
-
-6. IANA Considerations
-
- This document does not require any actions on the part of IANA.
-
-
-7. Normative References
-
- [I-D.desruisseaux-caldav-sched]
- Desruisseaux, B., "Scheduling Extensions to CalDAV",
- draft-desruisseaux-caldav-sched-03 (work in progress),
- January 2007.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D.
- Jensen, "HTTP Extensions for Distributed Authoring --
- WEBDAV", RFC 2518, February 1999.
-
- [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web
- Distributed Authoring and Versioning (WebDAV) Access
- Control Protocol", RFC 3744, May 2004.
-
- [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
- "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
- March 2007.
-
-
-Appendix A. Acknowledgments
-
- This specification is the result of discussions between the Apple
- calendar server and client teams.
-
-
-Appendix B. Change History
-
- Changes from -01:
-
- 1. Updated to RFC4791 reference.
-
- 2. Added text indicating that ctag applies to schedule Inbox and
- Outbox as well.
-
- Changes from -00:
-
- 1. Relaxed requirement so that any type of change to a child
- resource can trigger a CTag change (similar behavior to ETag).
-
-
-
-
-Daboo [Page 5]
-
- CalDAV Proxy May 2007
-
-
-Author's Address
-
- Cyrus Daboo
- Apple Inc.
- 1 Infinite Loop
- Cupertino, CA 95014
- USA
-
- Email: cyrus@daboo.name
- URI: http://www.apple.com/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo [Page 6]
-
diff --git a/vendor/sabre/dav/docs/caldav-notifications.txt b/vendor/sabre/dav/docs/caldav-notifications.txt
deleted file mode 100644
index 75c2e5e07..000000000
--- a/vendor/sabre/dav/docs/caldav-notifications.txt
+++ /dev/null
@@ -1,1568 +0,0 @@
-
-
-
-Calendar Server Extension C. Daboo
- Apple Inc.
- March 19, 2012
-
-
- CalDAV: Calendar User Notifications
-
-Abstract
-
- This specification defines an extension to CalDAV that allows the
- server to provide notifications to calendar users.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo [Page 1]
-
- CalDAV User Notifications March 2012
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 3. Conventions Used in This Document . . . . . . . . . . . . . . 3
- 4. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 3
- 4.1. Additional Principal Properties . . . . . . . . . . . . . 4
- 4.1.1. CS:notification-URL Property . . . . . . . . . . . . . 5
- 4.2. Properties on Notification Resources . . . . . . . . . . . 5
- 4.2.1. CS:notificationtype Property . . . . . . . . . . . . . 5
- 4.3. XML Element Definitions . . . . . . . . . . . . . . . . . 6
- 4.3.1. CS:notifications . . . . . . . . . . . . . . . . . . . 6
- 4.3.2. CS:notification . . . . . . . . . . . . . . . . . . . 6
- 4.3.3. CS:dtstamp . . . . . . . . . . . . . . . . . . . . . . 7
- 5. Notification Definitions . . . . . . . . . . . . . . . . . . . 7
- 5.1. System Status Notification . . . . . . . . . . . . . . . . 7
- 5.1.1. CS:systemstatus Element Definition . . . . . . . . . . 8
- 5.2. Quota Notification . . . . . . . . . . . . . . . . . . . . 8
- 5.2.1. CS:quotastatus Element Definition . . . . . . . . . . 9
- 5.3. Resource Changes Notification . . . . . . . . . . . . . . 10
- 5.3.1. CS:resource-change Element Definition . . . . . . . . 11
- 5.3.2. CS:calendar-changes Element Definition . . . . . . . . 15
- 5.3.2.1. Handling Recurrences in CS:calendar-changes . . . 17
- 5.3.3. CS:deleted-details Element Definition . . . . . . . . 18
- 5.3.4. CS:notify-changes Property . . . . . . . . . . . . . . 20
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
- 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
- 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
- 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
- 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
- 9.2. Informative References . . . . . . . . . . . . . . . . . . 21
- Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 21
- A.1. Resource Created . . . . . . . . . . . . . . . . . . . . . 21
- A.2. Resource Updated - Property Change . . . . . . . . . . . . 22
- A.3. Resource Updated - Parameter Change . . . . . . . . . . . 23
- A.4. Resource Updated - Multiple Instances Change . . . . . . . 23
- A.5. Resource Updated - Multiple User Change . . . . . . . . . 24
- A.6. Resource Deleted . . . . . . . . . . . . . . . . . . . . . 25
- A.7. Collection Created . . . . . . . . . . . . . . . . . . . . 26
- A.8. Collection Updated . . . . . . . . . . . . . . . . . . . . 26
- A.9. Collection Deleted . . . . . . . . . . . . . . . . . . . . 27
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27
-
-
-
-
-
-
-
-
-
-Daboo [Page 2]
-
- CalDAV User Notifications March 2012
-
-
-1. Introduction
-
- CalDAV [RFC4791] provides a way for calendar users to store calendar
- data and exchange this data via scheduling operations. Based on the
- WebDAV [RFC4918] protocol, it also includes the ability to manage
- access to calendar data via the WebDAV ACL [RFC3744] extension.
-
- It is often useful for servers to communicate arbitrary information
- to calendar users, e.g., system status, message of the day, quota
- warnings, changes to shared resources made by others etc. This
- specification defines a generic "notification" mechanism that allows
- a server to do that. Whilst primarily aimed at CalDAV [RFC4791],
- this mechanism has been designed to be adaptable to WebDAV [RFC4918].
-
-
-2. Open Issues
-
- 1. Define specific child elements for system status notification,
- e.g. "server-maintenance-period", "server-read-only-period",
- "client-upgrade-required".
-
-
-3. Conventions Used in This Document
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
- When XML element types in the namespaces "DAV:" and
- "urn:ietf:params:xml:ns:caldav" are referenced in this document
- outside of the context of an XML fragment, the string "DAV:" and
- "CALDAV:" will be prefixed to the element type names respectively.
-
- The namespace "http://calendarserver.org/ns/" is used for XML
- elements defined in this specification. When XML element types in
- that namespace are referenced in this document outside of the context
- of an XML fragment, the string "CS:" will be prefixed to the element
- type names.
-
-
-4. Notifications
-
- When this feature is available, a CS:notification-URL (Section 4.1.1)
- property appears on principal resources for those principals who are
- able to receive notifications. That property specifies a single DAV:
- href element whose content refers to a WebDAV collection resource.
- Notification "messages" are deposited into this collection and can be
- retrieved by clients and acted on accordingly.
-
-
-
-Daboo [Page 3]
-
- CalDAV User Notifications March 2012
-
-
- The notification collection referenced by the CS:notification-URL
- (Section 4.1.1) property MUST have a DAV:resourcetype property with
- DAV:collection and CS:notifications (Section 4.3.1) child elements.
-
- Notification "messages" are XML documents stored as resources in the
- notification collection. Each XML document contains a CS:
- notification (Section 4.3.2) element as its root. The root element
- contains a CS:dtstamp element, and one additional element which
- represents the type of notification being conveyed in the message.
- That child element will typically contain additional content that
- describes the notification.
-
- Each notification resource has a CS:notificationtype (Section 4.2.1)
- property which contains as its single child element an empty element
- that matches the child element of the notification resource XML
- document root. Any attributes on the child element in the XML
- document are also present in the property child element.
-
- Notifications are automatically generated by the server (perhaps in
- response to a action) with an appropriate resource stored in the
- notifications collection of the user to whom the notification is
- targeted. Clients SHOULD monitor the notification collection looking
- for new notification resources. When doing so, clients SHOULD look
- at the CS:notificationtype (Section 4.2.1) property to ensure that
- the notification is of a type that the client can handle. Once a
- client has handled the notification in whatever way is appropriate it
- SHOULD delete the notification resource. Clients SHOULD remove
- notifications being displayed to a user when the notification
- resource is removed from the notification collection, to enable the
- user to dismiss a notification on one device and have it
- automatically removed from others. Clients MUST ignore all
- notifications for types they do not recognize. Servers MAY delete
- notification resources on their own if they determine that the
- notifications are no longer relevant or valid. Servers MAY coalesce
- notifications as appropriate.
-
- Servers MUST prevent clients from adding resources in the
- notification collection.
-
-4.1. Additional Principal Properties
-
- This section defines new properties for WebDAV principal resources as
- defined in RFC3744 [RFC3744]. These properties are likely to be
- protected but the server MAY allow them to be written by appropriate
- users.
-
-
-
-
-
-
-Daboo [Page 4]
-
- CalDAV User Notifications March 2012
-
-
-4.1.1. CS:notification-URL Property
-
- Name: notification-URL
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Identify the URL of the notification collection owned by
- the associated principal resource.
-
- Protected: This property SHOULD be protected.
-
- PROPFIND behavior: This property SHOULD NOT be returned by a
- PROPFIND allprop request (as defined in Section 14.2 of
- [RFC4918]).
-
- COPY/MOVE behavior: This property value SHOULD be preserved in COPY
- and MOVE operations.
-
- Description: This property is needed for a client to determine where
- the notification collection of the current user is located so that
- processing of notification messages can occur. If not present,
- then the associated calendar user is not enabled for notification
- messages on the server.
-
- Definition:
-
-
-
-4.2. Properties on Notification Resources
-
- The following new WebDAV properties are defined for notification
- resources.
-
-4.2.1. CS:notificationtype Property
-
- Name: notificationtype
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Identify the type of notification of the corresponding
- resource.
-
- Protected: This property MUST be protected.
-
- PROPFIND behavior: This property SHOULD NOT be returned by a
- PROPFIND allprop request (as defined in Section 14.2 of
- [RFC4918]).
-
-
-
-
-Daboo [Page 5]
-
- CalDAV User Notifications March 2012
-
-
- COPY/MOVE behavior: This property value MUST be preserved in COPY
- and MOVE operations.
-
- Description: This property allows a client, via a PROPFIND Depth:1
- request, to quickly find notification messages that the client can
- handle in a notification collection. The single child element is
- the notification resource root element's child defining the
- notification itself. This element MUST be empty, though any
- attributes on the element in the notification resource MUST be
- present in the property element.
-
- Definition:
-
-
-
-
-4.3. XML Element Definitions
-
-4.3.1. CS:notifications
-
- Name: notifications
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Indicates a notification collection.
-
- Description: This XML element is used in a DAV:resourcetype element
- to indicate that the corresponding resource is a notification
- collection.
-
- Definition:
-
-
-
-4.3.2. CS:notification
-
- Name: notification
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Notification message root element.
-
- Description: The root element used in notification resources.
-
-
-
-
-
-
-
-Daboo [Page 6]
-
- CalDAV User Notifications March 2012
-
-
- Definition:
-
-
-
-
-4.3.3. CS:dtstamp
-
- Name: dtstamp
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Date-time stamp.
-
- Description: Contains the date-time stamp corresponding to the
- creation of a notification message, using the format defined in
- [RFC3339], or the "compact" format without "-" and ":" characters
- between date and time elements, respectively.
-
- Definition:
-
-
-
-
-
-5. Notification Definitions
-
- This section defines a set of common notification types.
-
-5.1. System Status Notification
-
- The system status notification is used to convey a URI and/or textual
- description to the user. The assumption is that the URI points to a
- webpage where current system status is described in detail, with the
- provided description being a summary of that. A "type" attribute on
- the element is used to indicate the importance of the current status
- notification, and has the values "low", "medium" and "high",
- representing the increasing level of importance of the message
- respectively.
-
- Servers might have knowledge of specific calendar user language
- preferences, in which case it MAY localise the CS:description value
- as appropriate based on the calendar user accessing the notification,
- but if it does, it SHOULD include an xml:lang attribute on the CS:
- description element to indicate what language is being used.
-
-
-
-
-
-Daboo [Page 7]
-
- CalDAV User Notifications March 2012
-
-
-5.1.1. CS:systemstatus Element Definition
-
- Name: systemstatus
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Indicates a system status notification.
-
- Description: This XML element is used in a CS:notification element
- to describe a system status notification.
-
- Definition:
-
-
-
-
-
-
-
-
- Example: This is an example of the body of a notification resource
- for an emergency system outage:
-
-
-
- 2011-12-09T11:12:53-05:00
-
- http://example.com/emergency_shutdown.html
- Emergency shutdown now
-
-
-
- Example: This is an example of the WebDAV property on the example
- notification resource above:
-
-
-
-
-
-
-5.2. Quota Notification
-
- The quota notification is used to convey information about the status
- of one or more quotas for the user. The notification contains
- elements for different types of quota being reported to the user. In
-
-
-
-Daboo [Page 8]
-
- CalDAV User Notifications March 2012
-
-
- some cases these may be warnings (e.g., a user getting to 80% of
- their quota limit), or in other cases errors (e.g., a user exceeding
- their quota).
-
-5.2.1. CS:quotastatus Element Definition
-
- Name: quotastatus
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Indicates a quota status notification.
-
- Description: This XML element is used in a CS:notification element
- to describe a quota status notification. The CS:quota-percent-
- used element contains an integer greater than or equal to zero.
- If the value is greater than or equal to 100, then the user's
- quota has been reached or exceeded. The DAV:href element contains
- a URI for a webpage where the user can go to get further
- information about their quota status or take corrective action.
-
- Definition:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Example: This is an example of the body of a notification resource
- for a quota warning:
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo [Page 9]
-
- CalDAV User Notifications March 2012
-
-
-
-
- 2011-12-09T11:12:53-05:00
-
-
-
- 80
- https://example.com/your-account.html
-
-
-
-
- Example: This is an example of the body of a notification resource
- for a quota that has been exceeded, and a count-based limit that
- is shown as a warning:
-
-
-
- 2011-12-09T11:12:53-05:00
-
-
-
- 102
- https://example.com/fix-account.html
-
-
-
- 82
- 4980
- https://example.com/buy-more-space.html
-
-
-
-
-5.3. Resource Changes Notification
-
- The resource change notification is used to inform the user of new,
- updated or deleted resources caused by changes made by someone else
- (note: servers MUST NOT generate notifications to users for changes
- they themselves make, though the possibility of an automated process
- acting on behalf of a user needs to be considered). This
- notification can be used by clients to show changes that a user can
- acknowledge in their own time. When the notification is present, it
- can be displayed on all devices a user is accessing their data from.
- When the user acknowledges and dismisses the notification on one
- device, other devices SHOULD also remove the notification when they
-
-
-
-Daboo [Page 10]
-
- CalDAV User Notifications March 2012
-
-
- next synchronize the notification collection.
-
- A new WebDAV property CS:notify-changes (Section 5.3.4) is defined
- for calendar collections. This allows users to enable or disable the
- sending of resource change notifications for the calendar and its
- child resources. Servers MUST allow users to set this property on a
- per-user basis on any calendars accessible to them. Servers MUST
- honor the chosen setting to enable or disable change notifications.
-
- Servers can send notifications for calendar object resources, and
- ones for calendar collections. Servers SHOULD coalesce notifications
- that refer to the same resource into a single notification resource,
- containing multiple CS:created, CS:updated or CS:deleted elements all
- with the same DAV:href child element value. Servers MAY coalesce
- changes to multiple resources into a change notification for the
- parent collection of those resources and use a CS:collection-changes
- element to indicate the number of individual resources that changed.
-
-5.3.1. CS:resource-change Element Definition
-
- Name: resource-change
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Indicates that resources have been created, updated or
- deleted.
-
- Description: This XML element is used in a CS:notification element
- to describe a resource change notification. It can describe a
- change directly to a calendar object resource or to a calendar
- collection.
-
- When used for a calendar object resource change, it can contain
- one of the CS:created, or CS:deleted elements, or multiple CS:
- updated elements, which indicate a created, deleted or updated
- resource, respectively. The DAV:href element within those
- elements, contains the URI of the changed resource, optional
- information about who changed the resource and when that change
- was made (the CS:changed-by element), and information specific to
- the nature of the change. Servers SHOULD coalesce resource change
- notifications for the same resource into a single notification
- resource where possible. The CS:updated element optionally
- contains CS:content and/or DAV:prop elements to indicate a change
- to the body of the resource or resource WebDAV properties,
- respectively. The DAV:prop element MAY contain a list of property
- elements to indicate which properties changed. The CS:updated
- element can also contain zero or more CS:calendar-changes elements
- to list details of the changes. If no CS:calendar-changes element
-
-
-
-Daboo [Page 11]
-
- CalDAV User Notifications March 2012
-
-
- is present, the specific details are not provided, and clients
- will need to assume that some set of changes occurred, but the
- server is unwilling to disclose the full details. The CS:deleted
- element can also contain zero or more CS:deleted-details elements
- to list details of the deleted resource.
-
- When used for a calendar collection change, it can contain a CS:
- collection-changes element. The DAV:href element within that
- element, contains the URI of the changed calendar collection. The
- DAV:prop element indicates a change to WebDAV properties on the
- calendar collection resource. The CS:child-created, CS:child-
- updated, and CS:child-deleted elements each contain a positive
- integer value indicating how many child resources were added,
- updated or deleted in the collection, respectively.
-
- Definition:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo [Page 12]
-
- CalDAV User Notifications March 2012
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Example: This is an example of the body of a notification resource
- for changes where one resource has been created:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo [Page 13]
-
- CalDAV User Notifications March 2012
-
-
-
-
- 2011-12-09T11:51:14-05:00
-
-
- http://example.com/cyrus/calendar/new.ics
-
- Cyrus Daboo
- /principals/cyrusdaboo
-
-
-
-
-
- Example: This is an example of the body of a notification resource
- for changes where a resource has been updated twice. One of the
- updated resources elements contains additional information
- indicating which recurrence instances in the iCalendar data were
- changed:
-
-
-
- 2011-12-09T11:51:14-05:00
-
-
- http://example.com/cyrus/calendar/event.ics
-
- Oliver
- Daboo
- mailto:oliver@example.com
-
-
-
- http://example.com/cyrus/calendar/event.ics
-
- Eleanor
- Daboo
- mailto:eleanor@example.com
-
-
-
-
-
-
-
-
-
-
-
-Daboo [Page 14]
-
- CalDAV User Notifications March 2012
-
-
- Example: This is an example of the body of a notification resource
- for changes where one resource has been deleted:
-
-
-
- 2011-12-09T11:51:14-05:00
-
-
- http://example.com/cyrus/calendar/old.ics
-
- Cyrus
- Daboo
- /principals/cyrusdaboo
-
-
-
-
-
- Example: This example is the same as the previous three, except that
- all the individual resource changes have been coalesced into a
- single notification about changes to the parent calendar
- collection:
-
-
-
- 2011-12-09T11:51:14-05:00
-
-
- http://example.com/cyrus/calendar/
- 1
- 2
- 1
-
-
-
-
-5.3.2. CS:calendar-changes Element Definition
-
- Name: calendar-changes
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Indicates which portions of an calendar object resource
- have changed, or provides details of deleted calendar object
- resources.
-
-
-
-
-Daboo [Page 15]
-
- CalDAV User Notifications March 2012
-
-
- Description: This XML element is used in a CS:updated element to
- describe how a calendar object resource changed, or in a CS:
- deleted element to provide details of a deleted resource. It can
- identify the master instance, or individual recurrence instances,
- and for each indicate which iCalendar properties and parameters
- changed during the update for which the notification was
- generated. For details of handling recurrences please see
- Section 5.3.2.1.
-
- Definition:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Example: This example indicates that a non-recurring component, or
- the master component in a recurring component, was changed and
- that the change was to the "SUMMARY" iCalendar property.
-
-
-
-
-
-
-Daboo [Page 16]
-
- CalDAV User Notifications March 2012
-
-
-
-
-
-
-
-
-
-
-
- Example: This example indicates that an instance of a recurring
- component was changed and that the change was to the "DTSTART"
- iCalendar property.
-
-
-
- 20111215T160000Z
-
-
-
-
-
-
-5.3.2.1. Handling Recurrences in CS:calendar-changes
-
- Changes to recurring components can be complex. This section
- describes the possible set of changes that could occur, and what the
- CS:calendar-changes element will contain as a result.
-
- Master exists, unchanged override added In this case, a CS:
- recurrence element will be present, containing a CS:recurrence-id
- element with a value equal to the RECURRENCE-ID property value (in
- UTC) of the added component. A CS:added element will be present.
- There will not be any CS:removed or CS:changes elements.
-
- Master exists, changed override added In this case, a CS:recurrence
- element will be present, containing a CS:recurrence-id element
- with a value equal to the RECURRENCE-ID property value (in UTC) of
- the added component. Both CS:added and CS:changes elements will
- be present. There will not be a CS:removed element.
-
- Master exists, override changed In this case, a CS:recurrence
- element will be present, containing a CS:recurrence-id element
- with a value equal to the RECURRENCE-ID property value (in UTC) of
- the added component. A CS:changes element will be present. There
- will not be any CS:added or CS:removed elements.
-
-
-
-
-
-
-Daboo [Page 17]
-
- CalDAV User Notifications March 2012
-
-
- Master exists, override removed In this case, a CS:recurrence
- element will be present, containing a CS:recurrence-id element
- with a value equal to the RECURRENCE-ID property value (in UTC) of
- the added component. A CS:removed element will be present. There
- will not be a CS:added element. A CS:changes element will only be
- present if the removed component differs from the "derived" master
- instance.
-
- Master exists, override cancelled In this case, a CS:recurrence
- element will be present, containing a CS:recurrence-id element
- with a value equal to the RECURRENCE-ID property value (in UTC) of
- the added component. A CS:removed element will be present. There
- will not be any CS:added or CS:changes element. There will also
- be a CS:master element present, with an appropriate CS:changes
- element, likely covering a change to "RRULE" or addition of
- "EXDATE" properties.
-
- Master does not exist, override added In this case, a CS:recurrence
- element will be present, containing a CS:recurrence-id element
- with a value equal to the RECURRENCE-ID property value (in UTC) of
- the added component. A CS:added element will be present. There
- will not be a CS:removed or CS:changes element.
-
- Master does not exist, override changed In this case, a CS:
- recurrence element will be present, containing a CS:recurrence-id
- element with a value equal to the RECURRENCE-ID property value (in
- UTC) of the added component. A CS:changes element will be
- present. There will not be any CS:added or CS:removed elements.
-
- Master does not exist, override removed In this case, a CS:
- recurrence element will be present, containing a CS:recurrence-id
- element with a value equal to the RECURRENCE-ID property value (in
- UTC) of the added component. A CS:removed element will be
- present. There will not be any CS:added or CS:changes element.
-
-5.3.3. CS:deleted-details Element Definition
-
- Name: deleted-details
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Provides summary information about a deleted resource or
- collection.
-
- Description: This XML element is used in a CS:deleted element to
- describe useful information about a deleted resource or
- collection, so clients can provide a meaningful notification
- message to users. This element has two variants: one for deletion
-
-
-
-Daboo [Page 18]
-
- CalDAV User Notifications March 2012
-
-
- of a calendar object resource, the other for deletion of a
- calendar collection.
-
- Definition:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Example: This example indicates deletion of a non-recurring event
- that was yet to occur at the time of deletion.
-
-
- VEVENT
- Birthday Party
-
- Holidays
-
-
-5.3.4. CS:notify-changes Property
-
- Name: notify-changes
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Allows a user to specify whether resource change
- notifications are generated by the server.
-
- Protected: This property MUST NOT be protected.
-
- PROPFIND behavior: This property SHOULD NOT be returned by a
- PROPFIND allprop request (as defined in Section 14.2 of
- [RFC4918]).
-
- COPY/MOVE behavior: This property value MUST be preserved in COPY
- and MOVE operations.
-
- Description: This property allows a user to enable or disable the
- server generation of resource change notifications for the
- calendar collection, and all its child resources, on which the
- property resides. If the property is not present on a calendar
- collection, the client and server MUST assume that resource change
- notifications are enabled.
-
- Definition:
-
-
-
-
-
-
-
-
-6. Security Considerations
-
- Some notification mechanisms might allow a user to trigger a
- notification to be delivered to other users (e.g., an invitation to
- share a calendar). In such cases servers MUST ensure that suitable
- limits are placed on the number and frequency of such user generated
- notifications.
-
-
-
-Daboo [Page 20]
-
- CalDAV User Notifications March 2012
-
-
- TBD: More?
-
-
-7. IANA Considerations
-
- This document does not require any actions on the part of IANA.
-
-
-8. Acknowledgments
-
- This specification is the result of discussions between the various
- Apple calendar server and client teams.
-
-
-9. References
-
-9.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
- Internet: Timestamps", RFC 3339, July 2002.
-
- [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed
- Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
-
-9.2. Informative References
-
- [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web
- Distributed Authoring and Versioning (WebDAV)
- Access Control Protocol", RFC 3744, May 2004.
-
- [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
- "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
- March 2007.
-
-
-Appendix A. Examples
-
- This section provides more detailed examples of resource change
- notifications for illustrative purposes only.
-
-A.1. Resource Created
-
- This is an example of the body of a notification resource where one
- resource has been created.
-
-
-
-
-Daboo [Page 21]
-
- CalDAV User Notifications March 2012
-
-
-
-
- 2011-12-09T11:51:14-05:00
-
-
- http://example.com/cyrus/calendar/new.ics
-
- Cyrus
- Daboo
- /principals/cyrusdaboo
-
-
-
-
-
-A.2. Resource Updated - Property Change
-
- This is an example of the body of a notification resource where one
- non-recurring event has had its "DTSTART" and "SUMMARY" iCalendar
- property values changed.
-
-
-
- 2011-12-09T11:51:14-05:00
-
-
- http://example.com/cyrus/calendar/new.ics
-
- Cyrus
- Daboo
- /principals/cyrusdaboo
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo [Page 22]
-
- CalDAV User Notifications March 2012
-
-
-A.3. Resource Updated - Parameter Change
-
- This is an example of the body of a notification resource where one
- non-recurring event has had the "PARTSTAT" iCalendar property
- parameter on an "ATTENDEE" property changed, and a "TRANSP" property
- added.
-
-
-
- 2011-12-09T11:51:14-05:00
-
-
- http://example.com/cyrus/calendar/new.ics
-
- Cyrus
- Daboo
- /principals/cyrusdaboo
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-A.4. Resource Updated - Multiple Instances Change
-
- This is an example of the body of a notification resource where two
- instances of a recurring event have their "DTSTART" and "SUMMARY"
- iCalendar property values changed.
-
-
-
-
-
-
-
-
-
-
-Daboo [Page 23]
-
- CalDAV User Notifications March 2012
-
-
-
-
- 2011-12-09T11:51:14-05:00
-
-
- http://example.com/cyrus/calendar/new.ics
-
- Cyrus
- Daboo
- /principals/cyrusdaboo
-
-
-
- 20120209T170000Z
-
-
-
-
-
-
- 20120210T170000Z
-
-
-
-
-
-
-
-
-
-
-A.5. Resource Updated - Multiple User Change
-
- This is an example of the body of a notification resource where two
- instances of a recurring event have their "DTSTART" and "SUMMARY"
- iCalendar property values changed. Each instance was changed by a
- different user.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo [Page 24]
-
- CalDAV User Notifications March 2012
-
-
-
-
- 2011-12-09T11:51:14-05:00
-
-
- http://example.com/cyrus/calendar/new.ics
-
- Cyrus
- Daboo
- /principals/cyrusdaboo
-
-
-
- 20120209T170000Z
-
-
-
-
-
-
-
-
- http://example.com/cyrus/calendar/new.ics
-
- Eric
- York
- /principals/ericyork
-
-
-
- 20120210T170000Z
-
-
-
-
-
-
-
-
-
-
-A.6. Resource Deleted
-
- This is an example of the body of a notification resource where one
- resource has been deleted. The resource was a VEVENT whose next
- occurrence was in the future on 20120210T170000Z.
-
-
-
-
-Daboo [Page 25]
-
- CalDAV User Notifications March 2012
-
-
-
-
- 2011-12-09T11:51:14-05:00
-
-
- http://example.com/cyrus/calendar/new.ics
-
- Cyrus
- Daboo
- /principals/cyrusdaboo
-
-
- VEVENT
- CalDAV Meeting
- 20120210T170000Z
-
-
-
-
-
-A.7. Collection Created
-
- This is an example of the body of a notification resource where a
- calendar collection has been created.
-
-
-
- 2011-12-09T11:51:14-05:00
-
-
- http://example.com/cyrus/new-calendar/
-
- Cyrus
- Daboo
- /principals/cyrusdaboo
-
-
-
-
-
-A.8. Collection Updated
-
- This is an example of the body of a notification resource where
- coalesced changes in a calendar collection are shown. In this case 1
- child resource was created, 2 updated, and 1 deleted.
-
-
-
-Daboo [Page 26]
-
- CalDAV User Notifications March 2012
-
-
-
-
- 2011-12-09T11:51:14-05:00
-
-
- http://example.com/cyrus/calendar/
- 1
- 2
- 1
-
-
-
-
-A.9. Collection Deleted
-
- This is an example of the body of a notification resource where a
- calendar collection has been deleted.
-
-
-
- 2011-12-09T11:51:14-05:00
-
-
- http://example.com/cyrus/old-calendar/
-
- Cyrus
- Daboo
- /principals/cyrusdaboo
-
-
- Holidays
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo [Page 27]
-
- CalDAV User Notifications March 2012
-
-
-Author's Address
-
- Cyrus Daboo
- Apple Inc.
- 1 Infinite Loop
- Cupertino, CA 95014
- USA
-
- Email: cyrus@daboo.name
- URI: http://www.apple.com/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo [Page 28]
-
diff --git a/vendor/sabre/dav/docs/caldav-proxy.txt b/vendor/sabre/dav/docs/caldav-proxy.txt
deleted file mode 100644
index 2d96bfc82..000000000
--- a/vendor/sabre/dav/docs/caldav-proxy.txt
+++ /dev/null
@@ -1,560 +0,0 @@
-
-
-
-Calendar Server Extension C. Daboo
- Apple Computer
- May 3, 2007
-
-
- Calendar User Proxy Functionality in CalDAV
- caldav-cu-proxy-02
-
-Abstract
-
- This specification defines an extension to CalDAV that makes it easy
- for clients to setup and manage calendar user proxies, using the
- WebDAV Access Control List extension as a basis.
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
- 2. Conventions Used in This Document . . . . . . . . . . . . . . 2
- 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 3.1. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 3.2. Client . . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 4. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 5. New features in CalDAV . . . . . . . . . . . . . . . . . . . . 4
- 5.1. Proxy Principal Resource . . . . . . . . . . . . . . . . . 4
- 5.2. Privilege Provisioning . . . . . . . . . . . . . . . . . . 8
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
- 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
- 8. Normative References . . . . . . . . . . . . . . . . . . . . . 9
- Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 9
- Appendix B. Change History . . . . . . . . . . . . . . . . . . . 10
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo [Page 1]
-
- CalDAV Proxy May 2007
-
-
-1. Introduction
-
- CalDAV [RFC4791] provides a way for calendar users to store calendar
- data and exchange this data via scheduling operations. Based on the
- WebDAV protocol [RFC2518], it also includes the ability to manage
- access to calendar data via the WebDAV ACL extension [RFC3744].
-
- It is often common for a calendar user to delegate some form of
- responsibility for their calendar and schedules to another calendar
- user (e.g., a boss allows an assistant to check a calendar or to send
- and accept scheduling invites on his behalf). The user handling the
- calendar data on behalf of someone else is often referred to as a
- "calendar user proxy".
-
- Whilst CalDAV does have fine-grained access control features that can
- be used to setup complex sharing and management of calendars, often
- the proxy behavior required is an "all-or-nothing" approach - i.e.
- the proxy has access to all the calendars or to no calendars (in
- which case they are of course not a proxy). So a simple way to
- manage access to an entire set of calendars and scheduling ability
- would be handy.
-
- In addition, calendar user agents will often want to display to a
- user who has proxy access to their calendars, or to whom they are
- acting as a proxy. Again, CalDAV's access control discovery and
- report features can be used to do that, but with fine-grained control
- that exists, it can be hard to tell who is a "real" proxy as opposed
- to someone just granted rights to some subset of calendars. Again, a
- simple way to discover proxy information would be handy.
-
-
-2. Conventions Used in This Document
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
- When XML element types in the namespace "DAV:" are referenced in this
- document outside of the context of an XML fragment, the string "DAV:"
- will be prefixed to the element type names.
-
- When XML element types in the namespaces "DAV:" and
- "urn:ietf:params:xml:ns:caldav" are referenced in this document
- outside of the context of an XML fragment, the string "DAV:" and
- "CALDAV:" will be prefixed to the element type names respectively.
-
- The namespace "http://calendarserver.org/ns/" is used for XML
- elements defined in this specification. When XML element types in
-
-
-
-Daboo [Page 2]
-
- CalDAV Proxy May 2007
-
-
- this namespace are referenced in this document outside of the context
- of an XML fragment, the string "CS:" will be prefixed to the element
- type names respectively.
-
-
-3. Overview
-
-3.1. Server
-
- For each calendar user principal on the server, the server will
- generate two group principals - "proxy groups". One is used to hold
- the list of principals who have read-only proxy access to the main
- principal's calendars, the other holds the list of principals who
- have read-write and scheduling proxy access. NB these new group
- principals would have no equivalent in Open Directory.
-
- Privileges on each "proxy group" principal will be set so that the
- "owner" has the ability to change property values.
-
- The "proxy group" principals will be child resources of the user
- principal resource with specific resource types and thus are easy to
- discover. As a result the user principal resources will also be
- collection resources.
-
- When provisioning the calendar user home collection, the server will:
-
- a. Add an ACE to the calendar home collection giving the read-only
- "proxy group" inheritable read access.
-
- b. Add an ACE to the calendar home collection giving the read-write
- "proxy group" inheritable read-write access.
-
- c. Add an ACE to each of the calendar Inbox and Outbox collections
- giving the CALDAV:schedule privilege
- [I-D.desruisseaux-caldav-sched] to the read-write "proxy group".
-
-3.2. Client
-
- A client can see who the proxies are for the current principal by
- examining the principal resource for the two "proxy group" properties
- and then looking at the DAV:group-member-set property of each.
-
- The client can edit the list of proxies for the current principal by
- editing the DAV:group-member-set property on the relevant "proxy
- group" principal resource.
-
- The client can find out who the current principal is a proxy for by
- running a DAV:principal-match REPORT on the principal collection.
-
-
-
-Daboo [Page 3]
-
- CalDAV Proxy May 2007
-
-
- Alternatively, the client can find out who the current principal is a
- proxy for by examining the DAV:group-membership property on the
- current principal resource looking for membership in other users'
- "proxy groups".
-
-
-4. Open Issues
-
- 1. Do we want to separate read-write access to calendars vs the
- ability to schedule as a proxy?
-
- 2. We may want to restrict changing properties on the proxy group
- collections to just the DAV:group-member-set property?
-
- 3. There is no way for a proxy to be able to manage the list of
- proxies. We could allow the main calendar user DAV:write-acl on
- their "proxy group" principals, in which case they could grant
- others the right to modify the group membership.
-
- 4. Should the "proxy group" principals also be collections given
- that the regular principal resources will be?
-
-
-5. New features in CalDAV
-
-5.1. Proxy Principal Resource
-
- Each "regular" principal resource that needs to allow calendar user
- proxy support MUST be a collection resource. i.e. in addition to
- including the DAV:principal XML element in the DAV:resourcetype
- property on the resource, it MUST also include the DAV:collection XML
- element.
-
- Each "regular" principal resource MUST contain two child resources
- with names "calendar-proxy-read" and "calendar-proxy-write" (note
- that these are only suggested names - the server could choose any
- unique name for these). These resources are themselves principal
- resources that are groups contain the list of principals for calendar
- users who can act as a read-only or read-write proxy respectively.
-
- The server MUST include the CS:calendar-proxy-read or CS:calendar-
- proxy-write XML elements in the DAV:resourcetype property of the
- child resources, respectively. This allows clients to discover the
- "proxy group" principals by using a PROPFIND, Depth:1 request on the
- current user's principal resource and requesting the DAV:resourcetype
- property be returned. The element type declarations are:
-
-
-
-
-
-Daboo [Page 4]
-
- CalDAV Proxy May 2007
-
-
-
-
-
-
- The server MUST allow the "parent" principal to change the DAV:group-
- member-set property on each of the "child" "proxy group" principal
- resources. When a principal is listed as a member of the "child"
- resource, the server MUST include the "child" resource URI in the
- DAV:group-membership property on the included principal resource.
- Note that this is just "normal" behavior for a group principal.
-
- An example principal resource layout might be:
-
- + /
- + principals/
- + users/
- + cyrus/
- calendar-proxy-read
- calendar-proxy-write
- + red/
- calendar-proxy-read
- calendar-proxy-write
- + wilfredo/
- calendar-proxy-read
- calendar-proxy-write
-
- If the principal "cyrus" wishes to have the principal "red" act as a
- calendar user proxy on his behalf and have the ability to change
- items on his calendar or schedule meetings on his behalf, then he
- would add the principal resource URI for "red" to the DAV:group-
- member-set property of the principal resource /principals/users/
- cyrus/calendar-proxy-write, giving:
-
-
- /principals/users/red/
-
-
- The DAV:group-membership property on the resource /principals/users/
- red/ would be:
-
-
- /principals/users/cyrus/calendar-proxy-write
-
-
- If the principal "red" was also a read-only proxy for the principal
- "wilfredo", then the DA:group-membership property on the resource
- /principals/users/red/ would be:
-
-
-
-
-Daboo [Page 5]
-
- CalDAV Proxy May 2007
-
-
-
- /principals/users/cyrus/calendar-proxy-write
- /principals/users/wilfredo/calendar-proxy-read
-
-
- Thus a client can discover to which principals a particular principal
- is acting as a calendar user proxy for by examining the DAV:group-
- membership property.
-
- An alternative to discovering which principals a user can proxy as is
- to use the WebDAV ACL principal-match report, targeted at the
- principal collections available on the server.
-
- Example:
-
- >> Request <<
-
- REPORT /principals/ HTTP/1.1
- Host: cal.example.com
- Depth: 0
- Content-Type: application/xml; charset="utf-8"
- Content-Length: xxxx
- Authorization: Digest username="red",
- realm="cal.example.com", nonce="...",
- uri="/principals/", response="...", opaque="..."
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo [Page 6]
-
- CalDAV Proxy May 2007
-
-
- >> Response <<
-
- HTTP/1.1 207 Multi-Status
- Date: Fri, 10 Nov 2006 09:32:12 GMT
- Content-Type: application/xml; charset="utf-8"
- Content-Length: xxxx
-
-
-
-
- /principals/users/red/
-
-
-
-
-
-
-
- HTTP/1.1 200 OK
-
-
-
- /principals/users/cyrus/calendar-proxy-write
-
-
-
-
-
-
-
- HTTP/1.1 200 OK
-
-
-
- /principals/users/wilfredo/calendar-proxy-read
-
-
-
-
-
-
-
- HTTP/1.1 200 OK
-
-
-
-
-
-
-
-Daboo [Page 7]
-
- CalDAV Proxy May 2007
-
-
-5.2. Privilege Provisioning
-
- In order for a calendar user proxy to be able to access the calendars
- of the user they are proxying for the server MUST ensure that the
- privileges on the relevant calendars are setup accordingly:
-
- The DAV:read privilege MUST be granted for read-only and read-
- write calendar user proxy principals
-
- The DAV:write privilege MUST be granted for read-write calendar
- user proxy principals.
-
- Additionally, the CalDAV scheduling Inbox and Outbox calendar
- collections for the user allowing proxy access, MUST have the CALDAV:
- schedule privilege [I-D.desruisseaux-caldav-sched] granted for read-
- write calendar user proxy principals.
-
- Note that with a suitable repository layout, a server may be able to
- grant the appropriate privileges on a parent collection and ensure
- that all the contained collections and resources inherit that. For
- example, given the following repository layout:
-
- + /
- + calendars/
- + users/
- + cyrus/
- inbox
- outbox
- home
- work
- + red/
- inbox
- outbox
- work
- soccer
- + wilfredo/
- inbox
- outbox
- home
- work
- flying
-
- In order for the principal "red" to act as a read-write proxy for the
- principal "cyrus", the following WebDAV ACE will need to be granted
- on the resource /calendars/users/cyrus/ and all children of that
- resource:
-
-
-
-
-
-Daboo [Page 8]
-
- CalDAV Proxy May 2007
-
-
-
-
- /principals/users/cyrus/calendar-proxy-write
-
-
-
-
-
-
-
-6. Security Considerations
-
- TBD
-
-
-7. IANA Considerations
-
- This document does not require any actions on the part of IANA.
-
-
-8. Normative References
-
- [I-D.desruisseaux-caldav-sched]
- Desruisseaux, B., "Scheduling Extensions to CalDAV",
- draft-desruisseaux-caldav-sched-03 (work in progress),
- January 2007.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D.
- Jensen, "HTTP Extensions for Distributed Authoring --
- WEBDAV", RFC 2518, February 1999.
-
- [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web
- Distributed Authoring and Versioning (WebDAV) Access
- Control Protocol", RFC 3744, May 2004.
-
- [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
- "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
- March 2007.
-
-
-Appendix A. Acknowledgments
-
- This specification is the result of discussions between the Apple
- calendar server and client teams.
-
-
-
-
-Daboo [Page 9]
-
- CalDAV Proxy May 2007
-
-
-Appendix B. Change History
-
- Changes from -00:
-
- 1. Updated to RFC 4791 reference.
-
- Changes from -00:
-
- 1. Added more details on actual CalDAV protocol changes.
-
- 2. Changed namespace from http://apple.com/ns/calendarserver/ to
- http://calendarserver.org/ns/.
-
- 3. Made "proxy group" principals child resources of their "owner"
- principals.
-
- 4. The "proxy group" principals now have their own resourcetype.
-
-
-Author's Address
-
- Cyrus Daboo
- Apple Computer, Inc.
- 1 Infinite Loop
- Cupertino, CA 95014
- USA
-
- Email: cyrus@daboo.name
- URI: http://www.apple.com/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo [Page 10]
-
diff --git a/vendor/sabre/dav/docs/caldav-sharing.txt b/vendor/sabre/dav/docs/caldav-sharing.txt
deleted file mode 100644
index c69d6bbbe..000000000
--- a/vendor/sabre/dav/docs/caldav-sharing.txt
+++ /dev/null
@@ -1,1624 +0,0 @@
-
-
-
-Calendar Server Extension C. Daboo
- E. York
- Apple Inc.
- September 19, 2012
-
-
- Shared and Published Calendars in CalDAV
-
-Abstract
-
- This specification defines an extension to CalDAV that enables the
- sharing of calendars between users on a CalDAV server.
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
- 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 4. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 5
- 4.1. Additional Principal Properties . . . . . . . . . . . . . 5
- 4.1.1. CS:notification-URL Property . . . . . . . . . . . . . 6
- 4.2. Properties on Notification Resources . . . . . . . . . . . 6
- 4.2.1. CS:notificationtype Property . . . . . . . . . . . . . 6
- 5. Shared Calendaring . . . . . . . . . . . . . . . . . . . . . . 7
- 5.1. Feature Discovery . . . . . . . . . . . . . . . . . . . . 7
- 5.2. Additional Properties for Calendars . . . . . . . . . . . 7
- 5.2.1. DAV:resourcetype Property . . . . . . . . . . . . . . 7
- 5.2.2. CS:invite Property . . . . . . . . . . . . . . . . . . 8
- 5.2.3. CS:allowed-sharing-modes Property . . . . . . . . . . 8
- 5.2.4. CS:shared-url Property . . . . . . . . . . . . . . . . 9
- 5.3. Sharer Actions on Shared Calendars . . . . . . . . . . . . 9
- 5.3.1. Sharing or Unsharing a Calendar . . . . . . . . . . . 9
- 5.3.2. Manipulating Sharees of a Shared Calendar . . . . . . 10
- 5.3.2.1. Example: Successful Sharee Add Request . . . . . . 11
- 5.3.2.2. Example: Successful Multiple Sharee Change
- Request . . . . . . . . . . . . . . . . . . . . . 11
- 5.4. Sharee Actions on Shared Calendars . . . . . . . . . . . . 12
- 5.4.1. Replying to a Sharing Invite . . . . . . . . . . . . . 12
- 5.4.2. Removing a Shared Calendar . . . . . . . . . . . . . . 13
- 5.5. General Considerations . . . . . . . . . . . . . . . . . . 13
- 5.5.1. Access Levels . . . . . . . . . . . . . . . . . . . . 13
- 5.5.2. Allowing or Disallowing Sharing . . . . . . . . . . . 13
- 5.5.3. Per-user WebDAV Properties . . . . . . . . . . . . . . 14
- 5.5.4. Per-user Calendar Data . . . . . . . . . . . . . . . . 14
- 5.5.5. Scheduling . . . . . . . . . . . . . . . . . . . . . . 15
- 6. XML Element Definitions . . . . . . . . . . . . . . . . . . . 16
- 6.1. CS:shared-owner . . . . . . . . . . . . . . . . . . . . . 16
-
-
-
-Daboo & York [Page 1]
-
- CalDAV Sharing and Publishing September 2012
-
-
- 6.2. CS:shared . . . . . . . . . . . . . . . . . . . . . . . . 17
- 6.3. CS:can-be-shared . . . . . . . . . . . . . . . . . . . . . 17
- 6.4. CS:can-be-published . . . . . . . . . . . . . . . . . . . 18
- 6.5. CS:user . . . . . . . . . . . . . . . . . . . . . . . . . 18
- 6.6. CS:invite-noresponse . . . . . . . . . . . . . . . . . . . 18
- 6.7. CS:invite-deleted . . . . . . . . . . . . . . . . . . . . 19
- 6.8. CS:invite-accepted . . . . . . . . . . . . . . . . . . . . 19
- 6.9. CS:invite-declined . . . . . . . . . . . . . . . . . . . . 19
- 6.10. CS:invite-invalid . . . . . . . . . . . . . . . . . . . . 20
- 6.11. CS:access . . . . . . . . . . . . . . . . . . . . . . . . 20
- 6.12. CS:read . . . . . . . . . . . . . . . . . . . . . . . . . 21
- 6.13. CS:read-write . . . . . . . . . . . . . . . . . . . . . . 21
- 6.14. CS:summary . . . . . . . . . . . . . . . . . . . . . . . . 21
- 6.15. CS:invite-notification . . . . . . . . . . . . . . . . . . 22
- 6.16. CS:uid . . . . . . . . . . . . . . . . . . . . . . . . . . 22
- 6.17. CS:hosturl . . . . . . . . . . . . . . . . . . . . . . . . 23
- 6.18. CS:organizer . . . . . . . . . . . . . . . . . . . . . . . 23
- 6.19. CS:common-name . . . . . . . . . . . . . . . . . . . . . . 23
- 6.20. CS:first-name . . . . . . . . . . . . . . . . . . . . . . 24
- 6.21. CS:last-name . . . . . . . . . . . . . . . . . . . . . . . 24
- 6.22. CS:invite-reply . . . . . . . . . . . . . . . . . . . . . 24
- 6.23. CS:in-reply-to . . . . . . . . . . . . . . . . . . . . . . 25
- 6.24. CS:notification . . . . . . . . . . . . . . . . . . . . . 25
- 6.25. CS:dtstamp . . . . . . . . . . . . . . . . . . . . . . . . 26
- 6.26. CS:share . . . . . . . . . . . . . . . . . . . . . . . . . 26
- 6.27. CS:set . . . . . . . . . . . . . . . . . . . . . . . . . . 26
- 6.28. CS:remove . . . . . . . . . . . . . . . . . . . . . . . . 27
- 6.29. CS:shared-as . . . . . . . . . . . . . . . . . . . . . . . 27
- 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
- 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
- 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
- 10. Normative References . . . . . . . . . . . . . . . . . . . . . 28
- Appendix A. Change History . . . . . . . . . . . . . . . . . . . 28
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & York [Page 2]
-
- CalDAV Sharing and Publishing September 2012
-
-
-1. Introduction
-
- CalDAV [RFC4791] provides a way for calendar users to store calendar
- data and exchange this data via scheduling operations. Based on the
- WebDAV [RFC4918] protocol, it also includes the ability to manage
- access to calendar data via the WebDAV ACL [RFC3744] extension.
-
- WebDAV ACL [RFC3744] provides a way to manage fine-grained access
- controls on WebDAV resources. Whilst this could be used directly to
- manage sharing of calendars, experience has shown that client
- developers are averse to using it due to its complexity. Instead a
- simpler process for sharing calendars is preferred.
-
- This extension defines a way for individual calendar users to share
- calendars with other users. This is done via an "opt-in" process in
- which a sharing invite is sent from the sharer to a sharee, allowing
- the sharee to accept or decline. If the sharee accepts the sharing
- invite, the shared calendar is made available to them in their own
- calendar home collection (i.e., alongside their own personal
- calendars). HTTP POST operations are used to manage the sharing
- invitations and replies, and WebDAV properties are used to expose the
- state of shared calendars.
-
-
-2. Conventions Used in This Document
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
- When XML element types in the namespaces "DAV:" and
- "urn:ietf:params:xml:ns:caldav" are referenced in this document
- outside of the context of an XML fragment, the string "DAV:" and
- "CALDAV:" will be prefixed to the element type names respectively.
-
- The namespace "http://calendarserver.org/ns/" is used for XML
- elements defined in this specification. When XML element types in
- that namespace are referenced in this document outside of the context
- of an XML fragment, the string "CS:" will be prefixed to the element
- type names.
-
- Terms Used:
-
- Sharer A calendar user who is sharing a calendar with other calendar
- users.
-
-
-
-
-
-
-Daboo & York [Page 3]
-
- CalDAV Sharing and Publishing September 2012
-
-
- Sharee A calendar user to whom a calendar has been shared.
-
- Sharing Invite A message sent by a sharer to a sharee to indicate
- the status of a shared calendar.
-
- Sharing Reply A message sent by a sharee to a sharer to indicate the
- status of a shared calendar.
-
-
-3. Overview
-
- This section provides a basic overview of this protocol by way of a
- simple use case of a sharer sharing a calendar with a single sharee.
-
- To share a calendar with another user, the sharer's client executes
- an HTTP POST request against the calendar collection resource for the
- calendar to be shared. The POST request body will contain details of
- the calendar user to whom the calendar is to be shared as well as the
- access right to be granted to them. If the request succeeds, a
- notification is sent to the sharee with details of the calendar being
- shared to them.
-
- The sharer's client will show the notification to the sharee and
- present them with the choice to accept or decline the invitation to
- the shared calendar. If the sharee chooses to decline, then nothing
- changes for that sharee. If the sharee chooses to accept, then the
- server automatically creates a new calendar collection resource in
- the sharee's calendar home collection, and ensures that calendar
- provides a mapping to the actual shared calendar of the sharer. Thus
- the shared calendar is available to the sharee as just another
- calendar in their calendar home. The server enforces the appropriare
- access privileges for the sharee.
-
- At any time, the sharer can inspect properties on the calendar
- collection being shared, and determine the accept/decline status of
- each sharee. Additional sharees can be added and existing ones
- removed. The access privileges for existing sharees can also be
- changed.
-
- Once a sharee has a shared calendar set to appear in their calendar
- home collection, they can remove it and decline the sharing invite by
- simply having their client issue an HTTP DELETE request on the shared
- calendar collection. That does not delete any calendar data, but
- rather simply removes the "link" to the sharer's calendar collection
- and sets the sharee's inviate status to declined.
-
-
-
-
-
-
-Daboo & York [Page 4]
-
- CalDAV Sharing and Publishing September 2012
-
-
-4. Notifications
-
- In order to facilitate the process of sharing invitations, this
- specification defines a new generic notification mechanism for CalDAV
- servers. When this feature is available, a CS:notification-URL
- (Section 4.1.1) property appears on principal resources for those
- principals who are able to receive notifications. That property
- specifies a single DAV:href element whose content refers to a WebDAV
- collection resource. Notification "messages" are deposited into this
- collection and can be retrieved by clients and acted on accordingly.
-
- The notification collection referenced by the CS:notification-URL
- (Section 4.1.1) property MUST have a DAV:resourcetype property with
- DAV:collection and CS:notification (Section 6.24) child elements.
-
- Notification "messages" are XML documents stored as resources in the
- notification collection. Each XML document contains a CS:
- notification (Section 6.24) element as its root. The root element
- contains a CS:dtstamp (Section 6.25) element, and one additional
- element which represents the type of notification being conveyed in
- the message. That child element will typically contain additional
- content that describes the notification.
-
- Each notification resource has a CS:notificationtype (Section 4.2.1)
- property which contains as its single child element an empty element
- that matches the child element of the notification resource XML
- document root. Any attributes on the child element in the XML
- document are also present in the property child element.
-
- Notifications are automatically generated by the server (perhaps in
- response to a client action) with an appropriate resource stored in
- the notifications collection of the user to whom the notification is
- targeted. Clients SHOULD monitor the notification collection looking
- for new notification resources. When doing so, clients SHOULD look
- at the CS:notificationtype (Section 4.2.1) property to ensure that
- the notification is of a type that the client can handle. Once a
- client has handled the notification in whatever way is appropriate it
- SHOULD delete the notification resource. Servers MAY delete
- notification resources on their own if they determine that the
- notifications are no longer relevant or valid. Servers MAY coalesce
- notifications as appropriate.
-
-4.1. Additional Principal Properties
-
- This section defines new properties for WebDAV principal resources as
- defined in RFC3744 [RFC3744]. These properties are likely to be
- protected but the server MAY allow them to be written by appropriate
- users.
-
-
-
-Daboo & York [Page 5]
-
- CalDAV Sharing and Publishing September 2012
-
-
-4.1.1. CS:notification-URL Property
-
- Name: notification-URL
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Identify the URL of the notification collection owned by
- the associated principal resource.
-
- Protected: This property SHOULD be protected.
-
- PROPFIND behavior: This property SHOULD NOT be returned by a
- PROPFIND allprop request (as defined in Section 14.2 of
- [RFC4918]).
-
- COPY/MOVE behavior: This property value SHOULD be preserved in COPY
- and MOVE operations.
-
- Description: This property is needed for a client to determine where
- the notification collection of the current user is located so that
- processing of notification messages can occur. If not present,
- then the associated calendar user is not enabled for notification
- messages on the server.
-
- Definition:
-
-
-
-4.2. Properties on Notification Resources
-
- The following new WebDAV properties are defined for notification
- resources.
-
-4.2.1. CS:notificationtype Property
-
- Name: notificationtype
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Identify the type of notification of the corresponding
- resource.
-
- Protected: This property MUST be protected.
-
- PROPFIND behavior: This property SHOULD NOT be returned by a
- PROPFIND allprop request (as defined in Section 14.2 of
- [RFC4918]).
-
-
-
-
-Daboo & York [Page 6]
-
- CalDAV Sharing and Publishing September 2012
-
-
- COPY/MOVE behavior: This property value MUST be preserved in COPY
- and MOVE operations.
-
- Description: This property allows a client, via a PROPFIND Depth:1
- request, to quickly find notification messages that the client can
- handle in a notification collection. The single child element is
- the notification resource root element's child defining the
- notification itself. This element MUST be empty, though any
- attributes on the element in the notification resource MUST be
- present in the property element.
-
- Definition:
-
-
-
-
-
-5. Shared Calendaring
-
-5.1. Feature Discovery
-
- A server that supports the features described in this document MUST
- include "calendarserver-sharing" as a field in the DAV response
- header from an OPTIONS request on any resource that supports these
- features.
-
-5.2. Additional Properties for Calendars
-
- The following new or modified WebDAV properties are defined for
- calendar collections and used to view or manipulate shared calendar
- features.
-
-5.2.1. DAV:resourcetype Property
-
- Calendar collections that are shared have addition elements listed in
- their DAV:resourcetype property in addition to DAV:collection and
- CALDAV:calendar.
-
- o CS:shared-owner (Section 6.1): used to indicate that the calendar
- is owned by the current user and is being shared by them.
-
- o CS:shared (Section 6.2): used to indicate that the calendar is
- owned by another user and is being shared to the current user.
-
-
-
-
-
-
-
-Daboo & York [Page 7]
-
- CalDAV Sharing and Publishing September 2012
-
-
-5.2.2. CS:invite Property
-
- Name: invite
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Used to show to whom a calendar has been shared.
-
- Protected: This property MUST be protected.
-
- PROPFIND behavior: This property SHOULD NOT be returned by a
- PROPFIND allprop request (as defined in Section 14.2 of
- [RFC4918]).
-
- COPY/MOVE behavior: This property value MUST be preserved in COPY
- and MOVE operations.
-
- Description: This WebDAV property is present on a calendar
- collection resource that has been shared by the owner, or on the
- calendar collection resources of the sharees of the calendar. It
- provides a list of users to whom the calendar has been shared,
- along with the "status" of the sharing invites sent to each user.
- In addition, servers SHOULD include a CS:organizer XML element on
- calendar collection resources of the sharees to provide clients
- with a fast way to determine who the sharer is. A server's local
- privacy policy may prevent sharees from knowing about other
- sharees on a shared calendar. If that is so server will not
- include CS:user XML elements for other sharees.
-
- Definition:
-
-
-
-5.2.3. CS:allowed-sharing-modes Property
-
- Name: allowed-sharing-modes
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Used to show which modes of sharing are supported on a
- calendar collection.
-
- Protected: This property MUST be protected.
-
- PROPFIND behavior: This property SHOULD NOT be returned by a
- PROPFIND allprop request (as defined in Section 14.2 of
- [RFC4918]).
-
-
-
-
-Daboo & York [Page 8]
-
- CalDAV Sharing and Publishing September 2012
-
-
- COPY/MOVE behavior: This property value MUST be preserved in COPY
- and MOVE operations.
-
- Description: This WebDAV property is present on a calendar
- collection resource that can been shared or published. It
- provides a list of options indicating what sharing modes are
- allowed as per Section 5.5.2.
-
- Definition:
-
-
-
-5.2.4. CS:shared-url Property
-
- Name: shared-url
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Indicates the URL of the owner's copy of a shared calendar.
-
- Protected: This property MUST be protected.
-
- PROPFIND behavior: This property SHOULD NOT be returned by a
- PROPFIND allprop request (as defined in Section 14.2 of
- [RFC4918]).
-
- COPY/MOVE behavior: This property value MUST be preserved in COPY
- and MOVE operations.
-
- Description: This WebDAV property is present on a shared calendar
- collection resource that appears in a sharee's calendar home
- collection. Its content is a single DAV:href element whose value
- is the URL of the sharer's calendar being shared.
-
- Definition:
-
-
-
-5.3. Sharer Actions on Shared Calendars
-
-5.3.1. Sharing or Unsharing a Calendar
-
- To update an existing calendar to be shared, the sharer simply adds
- one or more sharees to the calendar collection as per Section 5.3.2.
- The server MUST update the DAV:resourcetype property on the calendar
- collection to ensure it contains a CS:shared-owner XML element to
- indicate the calendar collection is now shared.
-
-
-
-Daboo & York [Page 9]
-
- CalDAV Sharing and Publishing September 2012
-
-
- To unshare a calendar, the sharer simply removes all sharees to the
- CS:invite property of the calendar collection as per Section 5.3.2.
- The server MUST update the DAV:resourcetype property on the calendar
- collection to ensure it does not contain a CS:shared-owner XML
- element to indicate the calendar collection is not shared.
-
-5.3.2. Manipulating Sharees of a Shared Calendar
-
- The sharer of a shared calendar is able to manipulate the sharee list
- by issuing a POST request targeted at the calendar collection
- resource. The POST request MUST contain an XML document as its body
- with the root element being CS:share (Section 6.26).
-
- The CS:share (Section 6.26) element in the POST requests MUST contain
- one or more CS:set (Section 6.27) or CS:remove (Section 6.28)
- elements. For each CS:set (Section 6.27) element, the server MUST
- add the specified sharee access to the calendar. For each CS:remove
- (Section 6.28) element the server MUST remove the specified sharee
- access from the shared calendar. In each case the server MUST send a
- notification message to any sharees whose status is changed (added,
- modified or removed), indicating to them a change in status for the
- shared calendar. The server SHOULD NOT send notification messages to
- sharees whose status is unchanged.
-
- Sharee's are identified via a DAV:href element whose value is either
- a principal-URL for a sharee hosted on the same server, a calendar
- user address or email address. In the case of the later two, the
- sharee might not be a user on the same server - though in that case
- how invitations are sent or access enabled is out of scope for this
- specification. A server MAY change the sharee's "address" to any
- suitable alternative that it might prefer when returning the list of
- sharees via the CS:invite property (Section 5.2.2).
-
- The client MAY include a CS:common-name (Section 6.19) element in the
- CS:set (Section 6.27) element. When provided, the value represents
- the common name for the sharee, and is returned in the list of
- sharees via the CS:invite property (Section 5.2.2). The server MAY
- change this to a suitable alternative when it is able to match the
- sharee to a known user. If absent from the client request, the
- server SHOULD add a CS:common-name when it is able to match the
- sharee with a known user, and a common name for that user can be
- determined.
-
- When the sharee list on a shared calendar is changed, the server MUST
- send notifications to each sharee to update them on their current
- sharing status. This is accomplished by sending a CS:invite-
- notification (Section 6.15) notification to each sharee.
-
-
-
-
-Daboo & York [Page 10]
-
- CalDAV Sharing and Publishing September 2012
-
-
-5.3.2.1. Example: Successful Sharee Add Request
-
- This example shows how to add a single sharee (with calendar user
- address "mailto:eric@example.com") to a shared calendar with CS:read-
- write access.
-
- >> Request <<
-
- POST /calendars/users/cyrus/shared/ HTTP/1.1
- Host: calendar.example.com
- Content-Type: application/xml; charset="utf-8"
- Content-Length: xxxx
-
-
-
-
- mailto:eric@example.com
- Eric York
- Shared workspace
-
-
-
-
- >> Response <<
-
- HTTP/1.1 200 OK
- Cache-Control: no-cache
- Date: Sat, 11 Nov 2006 09:32:12 GMT
-
-5.3.2.2. Example: Successful Multiple Sharee Change Request
-
- This example shows how multiple sharee's can be manipulated in a
- single request. The sharee with calendar user address
- "mailto:eric@example.com" has their access downgraded to CS:read,
- whilst another sharee is removed from the access list entirely.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & York [Page 11]
-
- CalDAV Sharing and Publishing September 2012
-
-
- >> Request <<
-
- POST /calendars/users/cyrus/shared/ HTTP/1.1
- Host: calendar.example.com
- Content-Type: application/xml; charset="utf-8"
- Content-Length: xxxx
-
-
-
-
- mailto:eric@example.com
- Shared workspace
-
-
-
- mailto:wilfredo@example.com
-
-
-
- >> Response <<
-
- HTTP/1.1 200 OK
- Cache-Control: no-cache
- Date: Sat, 11 Nov 2006 09:32:12 GMT
-
-5.4. Sharee Actions on Shared Calendars
-
-5.4.1. Replying to a Sharing Invite
-
- When a sharee is invited to a shared calendar they can accept or
- decline the invite by issuing a POST request to the sharee's calendar
- home collection resource. The POST request MUST contain an XML
- document as its body with the root element being CS:invite-reply
- (Section 6.22).
-
- The CS:invite-reply (Section 6.22) element in the POST request
- specifies the sharee who is replying in the DAV:href element, the
- accept or decline action via the CS:invite-accepted or CS:invite-
- declined elements, the URL of the shared calendar in the CS:hosturl
- element, the unique identifier of the invite to which it is a reply
- in the CS:in-reply-to element, and an optional CS:summary element.
-
- The response to a POST request that accepts a shared calendar invite
- MUST be an XML document containing CS:shared-as (Section 6.29) as its
- root element. That root element contains a single DAV:href element
- whose content is the URI of the shared calendar in the sharee's
- calendar home created by the invite acceptance.
-
-
-
-Daboo & York [Page 12]
-
- CalDAV Sharing and Publishing September 2012
-
-
- When the sharee replies to an invite, the server SHOULD send a
- notification to the sharer to update them on the change in the sharee
- state. This is accomplished by sending a CS:invite-reply
- (Section 6.22) notification to the sharer.
-
-5.4.2. Removing a Shared Calendar
-
- To remove a shared calendar from a sharee's calendar home collection
- a DELETE request is targeted at the shared calendar URI. When such a
- request is received the server MUST remove the shared calendar from
- the sharee's calendar home and automatically update the sharee's
- status in the sharer's calendar's CS:invite property.
-
-5.5. General Considerations
-
-5.5.1. Access Levels
-
- Two levels of access ca be granted by a sharer to any sharee. These
- are governed by the CS:access element used in the CS:invite/CS:user
- element that specifies a shared user invite. CS:access contains a
- single empty element that defines the type of access granted:
-
- CS:read When present this indicates that sharees can read calendar
- data but cannot change it.
-
- CS:read-write When present this indicates that sharees can read and
- write calendar data.
-
-5.5.2. Allowing or Disallowing Sharing
-
- Servers MAY support calendar sharing on a per-calendar basis - e.g.,
- they could treat some calendars as always private (cannot be shared)
- or always public (always shared). As a result clients need a way to
- determine which calendar could be shared so they can enable or
- disable sharing options on a per-calendar basis.
-
- This specification adds a CS:allowed-sharing-modes (Section 5.2.3)
- WebDAV property which servers can return on calendar collection
- resources. This property contains XML elements that describe which
- sharing or publishing capabilities can be supported by the
- corresponding calendar collection:
-
- CS:can-be-shared (Section 6.3): when present indicates that the
- calendar collection can be shared. When not present, the calendar
- collection cannot be shared.
-
- CS:can-be-published (Section 6.4): when present indicates that the
- calendar collection can be published. When not present, the
-
-
-
-Daboo & York [Page 13]
-
- CalDAV Sharing and Publishing September 2012
-
-
- calendar collection cannot be published.
-
- When not present on a calendar collection, sharing or publishing of
- that calendar is not allowed. Clients SHOULD NOT attempt to use
- requests to enable sharing or publishing targeted at those calendar
- collections.
-
-5.5.3. Per-user WebDAV Properties
-
- Servers MUST support "per-user" WebDAV properties on shared calendar
- collections and MAY support them on calendar object resources within
- shared calendar collections. A "per-user" WebDAV property is one
- whose value can be set and retrieved independently by each user with
- appropriate access rights. e.g., user "A" changes the DAV:displayname
- property on a shared calendar in their calendar home to "My
- calendar", and user "B" changes the same property to "Shared" on the
- same shared calendar in their calendar home. When each user
- retrieves the property value they will see their own last stored
- value and not the value of the other user.
-
- For shared calendars, the server MUST allow all users to write "per-
- user" WebDAV properties on the shared calendar collection and MAY
- allow property writes on calendar object resources within the shared
- calendar collection. This is required even in the case where the
- sharee has been granted read access only (i.e., the ability to change
- calendar data is disallowed). This requirement ensures that sharees
- can always change "personal" properties such as calendar colors and
- display names.
-
- Servers MUST treat the following properties as "per-user":
-
- DAV:displayname
-
- CALDAV:calendar-description
-
- CALDAV:schedule-calendar-transp
-
- ICAL:calendar-color
-
- Servers MAY treat any dead property as per-user.
-
- Servers MUST NOT treat live properties as per-user.
-
-5.5.4. Per-user Calendar Data
-
- Servers MUST support "per-user" calendar data in calendar object
- resources stored in shared calendars. This allows each sharee and
- the sharer to store their own alarms and free busy transparency
-
-
-
-Daboo & York [Page 14]
-
- CalDAV Sharing and Publishing September 2012
-
-
- status without "interfering" with other users who also have access to
- the same calendar object resources.
-
- For calendaring object resources in shared calendar collections, the
- server MUST treat the following iCalendar data objects as per-user:
-
- TRANSP property
-
- VALARM component
-
- Servers MAY treat any non-standard X- iCalendar properties as per-
- user.
-
- When handling per-user data in recurring components, servers SHOULD
- eliminate overridden instances when returning iCalendar data to
- clients in the case where there are no differences between the
- overridden component and the instance that could be derived from the
- "master" recurrence component. For example, consider a daily
- recurring event, Monday through Friday, initially defined without any
- overridden instances, that is in a shared calendar. If user "A"
- overrides the Tuesday instance and adds their own "VALARM" component
- only, then when user "A" later retrieves the data again they would
- see that overridden instance, but when user "B" does so, they would
- not. This ensures that each user sees the most "compact"
- representation of the calendar data.
-
-5.5.5. Scheduling
-
- CalDAV Scheduling [RFC6638] defines how a CalDAV server carries out
- scheduling operations when calendar object resources are created,
- modified or deleted and include "ORGANIZER" and "ATTENDEE" iCalendar
- properties.
-
- When calendar object resources are created, modified or deleted in
- shared calendars by sharees, the following restrictions apply:
-
- 1. The "ORGANIZER" iCalendar property value in the iCalendar data
- MUST match a calendar user address of the sharer (owner) of the
- shared calendar. The DAV:owner WebDAV property MUST be present
- on a shared calendar and MUST provide a reference to a principal-
- URL of the sharer (owner) of the shared calendar. Clients can
- use this value to determine what the allowed "ORGANIZER"
- iCalendar property values are. The server MUST reject any
- attempt by a sharee to create an iCalendar component with an
- "ORGANIZER" property value other than the sharer (owner) of the
- shared calendar.
-
-
-
-
-
-Daboo & York [Page 15]
-
- CalDAV Sharing and Publishing September 2012
-
-
- 2. The server MUST reject any attempt by a sharee to MOVE a calendar
- object resource in a shared calendar to some other collection.
-
- 3. When a sharee is listed as an Attendee in a calendar object
- resource in a shared calendar, and write access is granted, the
- sharee is allowed to change not only iCalendar data related to
- the Organizer, but also data related to the Attendee. i.e., a
- sharee can change their own participation status on the
- "ATTENDEE" iCalendar property referring to them. Additionally,
- if the sharee is not listed as an Attendee, and write access is
- granted, the sharee can add themselves as an Attendee.
-
- 4. The default calendar collection defined in Section 6.3 of
- [RFC6638] MUST NOT be a calendar shared to the corresponding
- calendar user.
-
- Following are additional considerations for scheduling with shared
- calendars:
-
- 1. A scheduled iCalendar component could appear in more than one
- calendar collection within a sharee's calendar home if the sharee
- is an Attendee and the Organizer or other Attendees have shared a
- calendar with the sharee that includes their copies of the
- iCalendar component. It is important to note that the scheduled
- component in the shared calendar could have different access
- rights than the one in the sharee's owned calendar.
-
- 2. A scheduled iCalendar component appearing in a sharee's shared
- calendar could include the sharee as an Attendee. For recurring
- events, it is possible for the sharee to only be listed as an
- Attendee in some instances, as opposed to all. Clients will need
- to be aware of this when allowing sharee's to set their own
- participation status.
-
- In addition, when a shared calendar is first accepted by a sharee,
- the server SHOULD set the CALDAV:schedule-calendar-transp property to
- the value CALDAV:transparent to ensure newly accepted shared
- calendars do not contribute to the sharee's freebusy time until the
- sharee explicitly requests it.
-
-
-6. XML Element Definitions
-
-6.1. CS:shared-owner
-
-
-
-
-
-
-
-Daboo & York [Page 16]
-
- CalDAV Sharing and Publishing September 2012
-
-
- Name: shared-owner
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Used to indicate that a calendar is being shared by the
- owner.
-
- Description: This property appears in the DAV:resourcetype property
- on the calendar collection resource shared by a sharer. See
- Section 5.2.
-
- Definition:
-
-
-
-6.2. CS:shared
-
- Name: shared
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Used to indicate that a calendar is being shared to a
- sharee.
-
- Description: This property appears in the DAV:resourcetype property
- on a calendar collection resource that is shared to a sharee and
- appears in the sharee's calendar home collection. See
- Section 5.2.
-
- Definition:
-
-
-
-6.3. CS:can-be-shared
-
- Name: can-be-shared
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Used to indicate that a calendar can be shared.
-
- Description: This element indicates that a calendar can be shared
- with other users. See Section 5.2.3
-
- Definition:
-
-
-
-
-
-
-Daboo & York [Page 17]
-
- CalDAV Sharing and Publishing September 2012
-
-
-6.4. CS:can-be-published
-
- Name: can-be-published
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Used to indicate that a calendar can be published.
-
- Description: This element indicates that a calendar can be published
- to anyone. See Section 5.2.3
-
- Definition:
-
-
-
-6.5. CS:user
-
- Name: user
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Used to show status of sharing invites sent to sharees.
-
- Description: This element provides the "status" of a sharing invite
- sent to a particular user. See Section 5.2.2.
-
- Definition:
-
-
-
-6.6. CS:invite-noresponse
-
- Name: invite-noresponse
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Sharing invite status.
-
- Description: When used in a CS:user (Section 6.5) element, this
- element is used to indicate that the sharee has never replied to
- the corresponding sharing invite. When used in a CS:invite-
- notification (Section 6.15) element, this element is used to
- indicate to the sharee that a sharing reply is needed.
-
-
-
-
-
-
-Daboo & York [Page 18]
-
- CalDAV Sharing and Publishing September 2012
-
-
- Definition:
-
-
-
-6.7. CS:invite-deleted
-
- Name: invite-deleted
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Sharing invite status.
-
- Description: When used in a CS:invite-notification (Section 6.15)
- element, this element is used to indicate to the sharee that a
- shared calendar has been unshared by the sharer.
-
- Definition:
-
-
-
-6.8. CS:invite-accepted
-
- Name: invite-accepted
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Sharing invite status.
-
- Description: When used in a CS:user (Section 6.5) element, this
- element is used to indicate that the sharee has accepted the
- corresponding sharing invite. When used in a CS:invite-
- notification (Section 6.15) element, this element is used to
- indicate to the sharee that the sharing invite is an update for
- one they previously accepted.
-
- Definition:
-
-
-
-6.9. CS:invite-declined
-
- Name: invite-declined
-
- Namespace: http://calendarserver.org/ns/
-
-
-
-
-
-
-
-Daboo & York [Page 19]
-
- CalDAV Sharing and Publishing September 2012
-
-
- Purpose: Sharing invite status.
-
- Description: When used in a CS:user (Section 6.5) element, this
- element is used to indicate that the sharee has declined the
- corresponding sharing invite. When used in a CS:invite-
- notification (Section 6.15) element, this element is used to
- indicate to the sharee that the sharing invite is an update for
- one they previously declined.
-
- Definition:
-
-
-
-6.10. CS:invite-invalid
-
- Name: invite-invalid
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Sharing invite status.
-
- Description: When used in a CS:user (Section 6.5) element, this
- element is used to indicate that the corresponding sharee is not a
- valid calendar user known to the server.
-
- Definition:
-
-
-
-6.11. CS:access
-
- Name: access
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Shared calendar access level.
-
- Description: When used in a CS:user (Section 6.5) element, this
- element is used to indicate the sharing access level granted to
- the corresponding sharee.
-
- Definition:
-
-
-
-
-
-
-
-
-
-Daboo & York [Page 20]
-
- CalDAV Sharing and Publishing September 2012
-
-
-6.12. CS:read
-
- Name: read
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Shared calendar access level privilege.
-
- Description: Indicates that the access level granted only allows
- sharees to read data in the shared calendar (though they can write
- per-user data (Section 5.5.4)).
-
- Definition:
-
-
-
-6.13. CS:read-write
-
- Name: read-write
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Shared calendar access level privilege.
-
- Description: Indicates that the access level granted allows sharees
- to read and write all data in the shared calendar, with the
- exception of components that would trigger scheduling.
-
- Definition:
-
-
-
-6.14. CS:summary
-
- Name: summary
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Summary or title of shared calendar.
-
- Description: A brief description of a shared calendar. This can be
- used by sharers to communicate the nature of a shared calendar to
- sharees, as well as used by sharees to indicate back to the sharer
- how each sharee is refering to the shared calendar.
-
-
-
-
-
-
-
-Daboo & York [Page 21]
-
- CalDAV Sharing and Publishing September 2012
-
-
- Definition:
-
-
-
-6.15. CS:invite-notification
-
- Name: invite-notification
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: A notification used as a shared calendar invite.
-
- Description: Defines a notification message sent automatically by
- the server when a sharer adds, changes or removes a sharee from a
- shared calendar. The DAV:href element specifies the calendar user
- address of the sharee to whom the message was sent. The CALDAV:
- supported-calendar-component-set is a copy of the matching WebDAV
- property on the sharers calendar collection, to allow clients to
- know what restrictions might apply to the shared calendar before
- accepting it.
-
- Definition:
-
-
-
-6.16. CS:uid
-
- Name: uid
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Unique identifier.
-
- Description: A unique identifier for an invitation to a shared
- calendar.
-
- Definition:
-
-
-
-
-
-
-
-
-Daboo & York [Page 22]
-
- CalDAV Sharing and Publishing September 2012
-
-
-6.17. CS:hosturl
-
- Name: hosturl
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Identifies the source URL of a shared calendar.
-
- Description: Contains a single DAV:href element that refers to the
- source of a shared calendar - i.e., the URL of the calendar shared
- by the sharer.
-
- Definition:
-
-
-
-6.18. CS:organizer
-
- Name: organizer
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Identifies the sharer of a shared calendar.
-
- Description: Contains a single DAV:href element that identifies the
- calendar user address of the sharer of a shared calendar, and an
- optional CS:common-name element that matches that user, and an
- option CS:first-name, CS:last-name pair of elements that match
- that user. In some cases servers might have directory information
- that includes only the common name, or only the first or last
- name, and it is better to expose those directly to the client
- as-is rather than to try and split or combine the attributes to
- synthesize one set or the other.
-
- Definition:
-
-
-
-6.19. CS:common-name
-
- Name: common-name
-
- Namespace: http://calendarserver.org/ns/
-
-
-
-
-
-
-Daboo & York [Page 23]
-
- CalDAV Sharing and Publishing September 2012
-
-
- Purpose: The common name of a sharer or sharee.
-
- Description: The common name is optionally provided by a client when
- adding a sharee and optionally included (or modified) by the
- server when returning results for sharers or sharees and in
- notifications.
-
- Definition:
-
-
-
-6.20. CS:first-name
-
- Name: first-name
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: The first name of a sharer or sharee.
-
- Description: The first name is optionally included by the server
- when returning results for sharers or sharees and in
- notifications.
-
- Definition:
-
-
-
-6.21. CS:last-name
-
- Name: last-name
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: The last name of a sharer or sharee.
-
- Description: The last name is optionally included by the server when
- returning results for sharers or sharees and in notifications.
-
- Definition:
-
-
-
-6.22. CS:invite-reply
-
-
-
-
-
-
-
-
-Daboo & York [Page 24]
-
- CalDAV Sharing and Publishing September 2012
-
-
- Name: invite-reply
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: A notification used as a reply to a shared calendar invite.
-
- Description: Defines a notification message sent automatically by
- the server when a sharee replies to a shared calendar invite. The
- DAV:href element specifies the calendar user address of the sharee
- to whom the original invite message was sent.
-
- Definition:
-
-
-
-6.23. CS:in-reply-to
-
- Name: in-reply-to
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Unique identifier.
-
- Description: Specifies the unique identifier of the inviate message
- that this notification message is a reply to.
-
- Definition:
-
-
-
-6.24. CS:notification
-
- Name: notification
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Notification message root element.
-
- Description: The root element used in notification resources.
-
- Definition:
-
-
-
-
-
-
-Daboo & York [Page 25]
-
- CalDAV Sharing and Publishing September 2012
-
-
-6.25. CS:dtstamp
-
- Name: dtstamp
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Date-time stamp.
-
- Description: Contains the date-time stamp corresponding to the
- creation of a notification message.
-
- Definition:
-
-
-
-6.26. CS:share
-
- Name: share
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Describes changes to sharees.
-
- Description: The root element used in POST requests on calendars by
- sharers to manipulate the sharee list of a shared calendar.
-
- Definition:
-
-
-
-6.27. CS:set
-
- Name: set
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Sets access for a sharee.
-
- Description: Used to add or modify sharee access to a shared
- calendar. The specified access to the shared calendar is given to
- the sharee.
-
- Definition:
-
-
-
-
-
-
-
-Daboo & York [Page 26]
-
- CalDAV Sharing and Publishing September 2012
-
-
-6.28. CS:remove
-
- Name: remove
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Removes access for a sharee.
-
- Description: Used to remove sharee access to a shared calendar. All
- access to the shared calendar is removed for the sharee.
-
- Definition:
-
-
-
-6.29. CS:shared-as
-
- Name: shared-as
-
- Namespace: http://calendarserver.org/ns/
-
- Purpose: Identifies a shared calendar.
-
- Description: Returned by the server for a POST request by a sharee
- accepting a shared calendar invite. The DAV:href element
- specifies the URI of the calendar created by the acceptance.
-
- Definition:
-
-
-
-
-7. Security Considerations
-
- Per-user WebDAV properties and iCalendar data MUST only be accessible
- by the user that created them.
-
- Alarms set by the sharer SHOULD NOT be propagated to sharees by
- default. Clients SHOULD NOT automatically enable triggering of
- alarms on shared calendars that have just been accepted without
- confirmation by the user.
-
- TBD
-
-
-8. IANA Considerations
-
- This document does not require any actions on the part of IANA.
-
-
-
-Daboo & York [Page 27]
-
- CalDAV Sharing and Publishing September 2012
-
-
-9. Acknowledgments
-
- This specification is the result of discussions between the Apple
- calendar server and client teams.
-
-
-10. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web
- Distributed Authoring and Versioning (WebDAV)
- Access Control Protocol", RFC 3744, May 2004.
-
- [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
- "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
- March 2007.
-
- [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed
- Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
-
- [RFC6638] Daboo, C. and B. Desruisseaux, "Scheduling Extensions to
- CalDAV", RFC 6638, June 2012.
-
-
-Appendix A. Change History
-
- Changes in -03:
-
- 1. Fixed access element DTD.
-
- 2. Remove MKxxx and PROPPATCH mechanism for upgrading/downgrading
- shared state on a calendar collection. Instead the server
- implicitly sets the state based on whether there are any sharees
- or not..
-
- 3. Added CS:first-name and CS:last-name optional element to CS:
- organizer.
-
- 4. Added CALDAV:supported-calendar-component-set optional element to
- CS:invite-notification.
-
- Changes in -02:
-
- 1. Removed read-write-shared access mode - now a server that does
- not support shared scheduling should advertise that via a DAV
- header
-
-
-
-Daboo & York [Page 28]
-
- CalDAV Sharing and Publishing September 2012
-
-
- Changes in -01:
-
- 1. Added CS:shared-url property
-
- 2. Clarified that notifications are only required to be sent when
- sharee status is changed
-
-
-Authors' Addresses
-
- Cyrus Daboo
- Apple Inc.
- 1 Infinite Loop
- Cupertino, CA 95014
- USA
-
- Email: cyrus@daboo.name
- URI: http://www.apple.com/
-
-
- Eric York
- Apple Inc.
- 1 Infinite Loop
- Cupertino, CA 95014
- USA
-
- Email:
- URI: http://www.apple.com/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & York [Page 29]
-
diff --git a/vendor/sabre/dav/docs/draft-daboo-carddav-directory-gateway-02.txt b/vendor/sabre/dav/docs/draft-daboo-carddav-directory-gateway-02.txt
deleted file mode 100644
index 63aa8b29c..000000000
--- a/vendor/sabre/dav/docs/draft-daboo-carddav-directory-gateway-02.txt
+++ /dev/null
@@ -1,560 +0,0 @@
-
-
-
-Network Working Group C. Daboo
-Internet-Draft Apple Inc.
-Updates: XXXX-CardDAV August 24, 2010
-(if approved)
-Intended status: Standards Track
-Expires: February 25, 2011
-
-
- CardDAV Directory Gateway Extension
- draft-daboo-carddav-directory-gateway-02
-
-Abstract
-
- This document defines an extension to the vCard Extensions to WebDAV
- (CardDAV) protocol that allows a server to expose a directory as a
- read-only address book collection.
-
-Status of this Memo
-
- This Internet-Draft is submitted in full conformance with the
- provisions of BCP 78 and BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF). Note that other groups may also distribute
- working documents as Internet-Drafts. The list of current Internet-
- Drafts is at http://datatracker.ietf.org/drafts/current/.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- This Internet-Draft will expire on February 25, 2011.
-
-Copyright Notice
-
- Copyright (c) 2010 IETF Trust and the persons identified as the
- document authors. All rights reserved.
-
- This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents
- (http://trustee.ietf.org/license-info) in effect on the date of
- publication of this document. Please review these documents
- carefully, as they describe your rights and restrictions with respect
- to this document. Code Components extracted from this document must
- include Simplified BSD License text as described in Section 4.e of
- the Trust Legal Provisions and are provided without warranty as
- described in the Simplified BSD License.
-
-
-
-Daboo Expires February 25, 2011 [Page 1]
-
-Internet-Draft CardDAV Directory Gateway Extension August 2010
-
-
-Table of Contents
-
- 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3
- 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 3. CARDDAV:directory-gateway Property . . . . . . . . . . . . . . 4
- 4. XML Element Definitions . . . . . . . . . . . . . . . . . . . 5
- 4.1. CARDDAV:directory . . . . . . . . . . . . . . . . . . . . 5
- 5. Client Guidelines . . . . . . . . . . . . . . . . . . . . . . 5
- 6. Server Guidelines . . . . . . . . . . . . . . . . . . . . . . 6
- 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
- 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 8
- 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
- 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8
- 10.2. Informative References . . . . . . . . . . . . . . . . . . 9
- Appendix A. Change History (to be removed prior to
- publication as an RFC) . . . . . . . . . . . . . . . 9
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo Expires February 25, 2011 [Page 2]
-
-Internet-Draft CardDAV Directory Gateway Extension August 2010
-
-
-1. Introduction and Overview
-
- The CardDAV [I-D.ietf-vcarddav-carddav] protocol defines a standard
- way of accessing, managing, and sharing contact information based on
- the vCard [RFC2426] format. Often, in an enterprise or service
- provider environment, a directory of all users hosted on the server
- (or elsewhere) is available (for example via Lightweight Directory
- Access Protocol (LDAP) [RFC4510] or some direct database access). It
- would be convenient for CardDAV clients if this directory were
- exposed as a "global" address book on the CardDAV server so it could
- be searched in the same way as personal address books are. This
- specification defines a "directory gateway" feature extension to
- CardDAV to enable this.
-
- This specification adds one new WebDAV property to principal
- resources that contains the URL to one or more directory gateway
- address book collection resources. It is important for clients to be
- able to distinguish this address book collection from others because
- there are specific limitations involved in using it as described
- below. To aid that, this specification defines an XML element that
- can be included as a child element of the DAV:resourcetype property
- of address book collections to identify them as directory gateways.
-
- Note that this feature is in no way intended to replace full
- directory access - it is meant to simply provide a convenient way for
- CardDAV clients to query contact-related attributes in directory
- records.
-
-
-2. Conventions
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
- The term "protected" is used in the Conformance field of property
- definitions as defined in Section 15 of [RFC4918].
-
- This document uses XML DTD fragments ([W3C.REC-xml-20081126], Section
- 3.2) as a purely notational convention. WebDAV request and response
- bodies cannot be validated by a DTD due to the specific extensibility
- rules defined in Section 17 of [RFC4918] and due to the fact that all
- XML elements defined by this specification use the XML namespace name
- "DAV:". In particular:
-
- 1. element names use the "DAV:" namespace,
-
-
-
-
-
-Daboo Expires February 25, 2011 [Page 3]
-
-Internet-Draft CardDAV Directory Gateway Extension August 2010
-
-
- 2. element ordering is irrelevant unless explicitly stated,
-
- 3. extension elements (elements not already defined as valid child
- elements) may be added anywhere, except when explicitly stated
- otherwise,
-
- 4. extension attributes (attributes not already defined as valid for
- this element) may be added anywhere, except when explicitly
- stated otherwise.
-
- When XML element types in the namespaces "DAV:" and
- "urn:ietf:params:xml:ns:carddav" are referenced in this document
- outside of the context of an XML fragment, the strings "DAV:" and
- "CARDDAV:" will be prefixed to the element types, respectively.
-
-
-3. CARDDAV:directory-gateway Property
-
- Name: directory-gateway
-
- Namespace: urn:ietf:params:xml:ns:carddav
-
- Purpose: Identifies URLs of CardDAV address book collections acting
- as a directory gateway for the server.
-
- Protected: MUST be protected.
-
- allprop behavior: SHOULD NOT be returned by a PROPFIND DAV:allprop
- request.
-
- Description: The CARDDAV:directory-gateway identifies address book
- collection resources that are directory gateway address books for
- the server.
-
- Definition:
-
-
-
- Example:
-
-
- /directory
-
-
-
-
-
-
-
-
-Daboo Expires February 25, 2011 [Page 4]
-
-Internet-Draft CardDAV Directory Gateway Extension August 2010
-
-
-4. XML Element Definitions
-
-4.1. CARDDAV:directory
-
- Name: directory
-
- Namespace: urn:ietf:params:xml:ns:carddav
-
- Purpose: Used to indicate that an address book collection is a
- directory gateway.
-
- Description: This element appears in the DAV:resourcetype property
- on a address book collection resources that are directory
- gateways. Clients can use the presence of this element to
- identify directory gateway collections when doing PROPFINDs to
- list collection contents.
-
- Definition:
-
-
-
- Example:
-
-
-
-
-
-
-
-
-5. Client Guidelines
-
- Clients wishing to make use of directory gateway address books can
- request the CARDDAV:directory-gateway property (Section 3) when
- examining other properties on the principal resource for the user.
- If the property is not present, then the directory gateway feature is
- not supported by the server at that time.
-
- Clients can also detect the presence of directory gateway address
- book collections by retrieving the DAV:resourcetype property on
- collections that it lists, and look for the presence of the CARDDAV:
- directory element (Section 4.1).
-
- Since the directory being exposed via a directory gateway address
- book collection could be large, clients SHOULD limit the number of
- results returned in an CARDDAV:addressbook-query REPORT as defined in
- Section 8.6.1 of [I-D.ietf-vcarddav-carddav].
-
-
-
-Daboo Expires February 25, 2011 [Page 5]
-
-Internet-Draft CardDAV Directory Gateway Extension August 2010
-
-
- Clients MUST treat the directory gateway address book collection as a
- read-only collection, so HTTP methods that modify resource data or
- properties in the address book collection MUST NOT be used.
-
- Clients SHOULD NOT attempt to cache the entire contents of the
- directory gateway address book collection resource by retrieving all
- resources, or trying to examine all the properties of all resources
- (e.g., via a PROPFIND Depth:1 request). Instead, CARDDAV:
- addressbook-query REPORTs are used to search for specific address
- book object resources, and CARDDAV:multiget REPORTs and individual
- GET requests can be made to retrieve the actual vCard data for
- address book object resources found via a query.
-
- When presenting directory gateway collections to the user, clients
- SHOULD use the DAV:displayname property on the corresponding address
- book collections as the name of the directory gateway. This is
- important in the case where more than one directory gateway is
- available. Clients MAY also provide descriptive information about
- each directory gateway by examining the CARDDAV:addressbook-
- description property (see Section 6.2.1 of
- [I-D.ietf-vcarddav-carddav]) on the resource.
-
-
-6. Server Guidelines
-
- Servers wishing to expose a directory gateway as an address book
- collection MUST include the CARDDAV:directory-gateway property on all
- principal resources of users expected to use the feature.
-
- Since the directory being exposed via the directory gateway address
- book collection could be large, servers SHOULD truncate the number of
- results returned in an CARDDAV:addressbook-query REPORT as defined in
- Section 8.6.2 of [I-D.ietf-vcarddav-carddav]. In addition, servers
- SHOULD disallow requests that effectively enumerate the collection
- contents (e.g., PROPFIND Depth:1, trivial CARDDAV:addressbook-query,
- DAV:sync-collection REPORT).
-
- Servers need to expose the directory information as a set of address
- book object resources in the directory gateway address book
- collection resource. To do that, a mapping between the directory
- record format and the vCard data has to be applied. In general, only
- directory record attributes that have a direct equivalent in vCard
- SHOULD be mapped. It is up to individual implementations to
- determine which attributes to map. But in all cases servers MUST
- generate valid vCard data as returned to the client. In addition, as
- required by CardDAV, the UID vCard property MUST be present in the
- vCard data, and this value MUST be persistent from query to query for
- the same directory record.
-
-
-
-Daboo Expires February 25, 2011 [Page 6]
-
-Internet-Draft CardDAV Directory Gateway Extension August 2010
-
-
- Multiple directory sources could be available to the server. The
- server MAY use a single directory gateway resource to aggregate
- results from each directory source. When doing so care is needed
- when dealing with potential records that refer to the same entity.
- Servers MAY suppress any duplicates that they are able to determine
- themselves. Alternatively, multiple directory sources can be exposed
- as separate directory gateway resources.
-
- For any directory source, a server MAY expose multiple directory
- gateway resources where each represents a different query "scope" for
- the directory. Different scopes MAY be offered to different
- principals on the server. For example, the server might expose an
- entire company directory for searching as the resource "/directory-
- all" to all principals, but then provide "/directory-department-XYZ"
- as another directory gateway that has a search scope that implicitly
- limits the search results to just the "XYZ" department. Users in
- that department would then have a CARDDAV:directory-gateway property
- on their principal resource that included the "/directory-department-
- XYZ" resource. Users in other departments would have corresponding
- directory gateway resources available to them.
-
- Records in a directory can include data for more than just people,
- e.g, resources such as rooms or projectors, groups, computer systems
- etc. It is up to individual implementations to determine the most
- appropriate "scope" for the data returned via the directory gateway
- by filtering the appropriate record types. As above, servers could
- choose to expose people and resources under different directory
- gateway resources by implicitly limiting the search "scope" for each
- of those.
-
- Servers MAY apply implementation defined access rules to determine,
- on a per-user basis, what records are returned to a particularly user
- and the content of those records exposed via vCard data. This per-
- user behavior is in addition to the general security requirements
- detailed below.
-
- When multiple directory gateway collections are present, servers
- SHOULD provide a DAV:displayname property on each that disambiguates
- them. Servers MAY include a CARDDAV:addressbook-description property
- (see Section 6.2.1 of [I-D.ietf-vcarddav-carddav]) on each directory
- gateway resource to provide a description of the directory and any
- search "scope" that might be used, or any other useful information
- for users.
-
-
-7. Security Considerations
-
- Servers MUST ensure that client requests against the directory
-
-
-
-Daboo Expires February 25, 2011 [Page 7]
-
-Internet-Draft CardDAV Directory Gateway Extension August 2010
-
-
- gateway address book collection cannot use excessive resources (CPU,
- memory, network bandwidth etc), given that the directory could be
- large.
-
- Servers MUST take care not to expose sensitive directory record
- attributes in the vCard data via the directory gateway address book.
- In general only those properties that have direct correspondence in
- vCard SHOULD be exposed.
-
- Servers need to determine whether it is appropriate for the directory
- information to be available via CardDAV to unauthenticated users. If
- not, servers MUST ensure that unauthenticated users do not have
- access to the directory gateway address book object resource and its
- contents. If unauthenticated access is allowed, servers MAY choose
- to limit the set of vCard properties that are searchable or returned
- in the address book object resources when unauthenticated requests
- are made.
-
-
-8. IANA Consideration
-
- This document does not require any actions on the part of IANA.
-
-
-9. Acknowledgments
-
-
-10. References
-
-10.1. Normative References
-
- [I-D.ietf-vcarddav-carddav]
- Daboo, C., "vCard Extensions to WebDAV (CardDAV)",
- draft-ietf-vcarddav-carddav-10 (work in progress),
- November 2009.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile",
- RFC 2426, September 1998.
-
- [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed
- Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
-
- [W3C.REC-xml-20081126]
- Paoli, J., Yergeau, F., Bray, T., Sperberg-McQueen, C.,
- and E. Maler, "Extensible Markup Language (XML) 1.0 (Fifth
-
-
-
-Daboo Expires February 25, 2011 [Page 8]
-
-Internet-Draft CardDAV Directory Gateway Extension August 2010
-
-
- Edition)", World Wide Web Consortium Recommendation REC-
- xml-20081126, November 2008,
- .
-
-10.2. Informative References
-
- [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol
- (LDAP): Technical Specification Road Map", RFC 4510,
- June 2006.
-
-
-Appendix A. Change History (to be removed prior to publication as an
- RFC)
-
- Changes in -02
-
- 1. Added CARDDAV:directory element for use in DAV:resourcetype
-
- 2. Allow CARDDAV:directory-gateway to be multi-valued
-
- 3. Explain how a server could implicit "scope" queries on different
- directory gateway resources
-
- Changes in -01
-
- 1. Remove duplicated text in a couple of sections
-
- 2. Add example of LDAP/generic database as possible directory
- "sources"
-
- 3. Add text to explain why the client needs to treat this as special
- and thus the need for a property
-
- 4. Added text to server guidelines indicating requirements for
- handling vCard UID properties
-
- 5. Added text to server guidelines explain that different record
- "types" may exist in the directory and the server is free to
- filter those as appropriate
-
- 6. Added text to server guidelines indicating that server are free
- to aggregate directory records from multiple sources
-
- 7. Added text to server guidelines indicating that servers are free
- to apply implementation defined access control to the returned
- data on a per-user basis
-
-
-
-
-
-Daboo Expires February 25, 2011 [Page 9]
-
-Internet-Draft CardDAV Directory Gateway Extension August 2010
-
-
-Author's Address
-
- Cyrus Daboo
- Apple Inc.
- 1 Infinite Loop
- Cupertino, CA 95014
- USA
-
- Email: cyrus@daboo.name
- URI: http://www.apple.com/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo Expires February 25, 2011 [Page 10]
-
diff --git a/vendor/sabre/dav/docs/draft-desruisseaux-caldav-sched-10.txt b/vendor/sabre/dav/docs/draft-desruisseaux-caldav-sched-10.txt
deleted file mode 100644
index bcb2520f0..000000000
--- a/vendor/sabre/dav/docs/draft-desruisseaux-caldav-sched-10.txt
+++ /dev/null
@@ -1,5544 +0,0 @@
-
-
-
-Network Working Group C. Daboo
-Internet-Draft Apple Inc.
-Updates: 4791 (if approved) B. Desruisseaux
-Intended status: Standards Track Oracle
-Expires: March 10, 2012 September 7, 2011
-
-
- CalDAV Scheduling Extensions to WebDAV
- draft-desruisseaux-caldav-sched-10
-
-Abstract
-
- This document defines extensions to the CalDAV "calendar-access"
- feature to specify a standard way of performing scheduling
- transactions with iCalendar-based calendar components. This document
- defines the "calendar-auto-schedule" feature of CalDAV.
-
-Status of This Memo
-
- This Internet-Draft is submitted in full conformance with the
- provisions of BCP 78 and BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF). Note that other groups may also distribute
- working documents as Internet-Drafts. The list of current Internet-
- Drafts is at http://datatracker.ietf.org/drafts/current/.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- This Internet-Draft will expire on March 10, 2012.
-
-Copyright Notice
-
- Copyright (c) 2011 IETF Trust and the persons identified as the
- document authors. All rights reserved.
-
- This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents
- (http://trustee.ietf.org/license-info) in effect on the date of
- publication of this document. Please review these documents
- carefully, as they describe your rights and restrictions with respect
- to this document. Code Components extracted from this document must
- include Simplified BSD License text as described in Section 4.e of
- the Trust Legal Provisions and are provided without warranty as
- described in the Simplified BSD License.
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 1]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- This document may contain material from IETF Documents or IETF
- Contributions published or made publicly available before November
- 10, 2008. The person(s) controlling the copyright in some of this
- material may not have granted the IETF Trust the right to allow
- modifications of such material outside the IETF Standards Process.
- Without obtaining an adequate license from the person(s) controlling
- the copyright in such materials, this document may not be modified
- outside the IETF Standards Process, and derivative works of it may
- not be created outside the IETF Standards Process, except to format
- it for publication as an RFC or to translate it into languages other
- than English.
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
- 1.2. Approach . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 1.3. Limitations . . . . . . . . . . . . . . . . . . . . . . . 7
- 1.4. Notational Conventions . . . . . . . . . . . . . . . . . . 8
- 1.5. XML Namespaces and Processing . . . . . . . . . . . . . . 8
- 2. Scheduling Process . . . . . . . . . . . . . . . . . . . . . . 10
- 3. Scheduling Support . . . . . . . . . . . . . . . . . . . . . . 11
- 3.1. Example OPTIONS Request . . . . . . . . . . . . . . . . . 11
- 4. Scheduling Collections . . . . . . . . . . . . . . . . . . . . 12
- 4.1. Scheduling Outbox Collection . . . . . . . . . . . . . . . 12
- 4.2. Scheduling Inbox Collection . . . . . . . . . . . . . . . 13
- 4.3. Calendaring Reports Extensions . . . . . . . . . . . . . . 15
- 5. Scheduling Transactions . . . . . . . . . . . . . . . . . . . 16
- 5.1. Identifying Scheduling Object Resources . . . . . . . . . 16
- 5.2. Handling Scheduling Object Resources . . . . . . . . . . . 16
- 5.2.1. Organizer Scheduling Object Resources . . . . . . . . 16
- 5.2.1.1. Create . . . . . . . . . . . . . . . . . . . . . . 17
- 5.2.1.2. Modify . . . . . . . . . . . . . . . . . . . . . . 18
- 5.2.1.3. Remove . . . . . . . . . . . . . . . . . . . . . . 20
- 5.2.2. Attendee Scheduling Object Resources . . . . . . . . . 20
- 5.2.2.1. Allowed Attendee Changes . . . . . . . . . . . . . 20
- 5.2.2.2. Create . . . . . . . . . . . . . . . . . . . . . . 21
- 5.2.2.3. Modify . . . . . . . . . . . . . . . . . . . . . . 22
- 5.2.2.4. Remove . . . . . . . . . . . . . . . . . . . . . . 23
- 5.2.3. HTTP Methods . . . . . . . . . . . . . . . . . . . . . 24
- 5.2.3.1. PUT . . . . . . . . . . . . . . . . . . . . . . . 24
- 5.2.3.2. COPY . . . . . . . . . . . . . . . . . . . . . . . 24
- 5.2.3.3. MOVE . . . . . . . . . . . . . . . . . . . . . . . 25
- 5.2.3.4. DELETE . . . . . . . . . . . . . . . . . . . . . . 26
- 5.2.4. Additional Method Preconditions . . . . . . . . . . . 26
- 5.2.4.1. CALDAV:unique-scheduling-object-resource
- Precondition . . . . . . . . . . . . . . . . . . . 26
- 5.2.4.2. CALDAV:same-organizer-in-all-components
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 2]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- Precondition . . . . . . . . . . . . . . . . . . . 26
- 5.2.4.3. CALDAV:allowed-organizer-scheduling-object-chan
- Precondition . . . . . . . . . . . . . . . . . . . 27
- 5.2.4.4. CALDAV:allowed-attendee-scheduling-object-chang
- Precondition . . . . . . . . . . . . . . . . . . . 28
- 5.2.5. DTSTAMP and SEQUENCE Properties . . . . . . . . . . . 28
- 5.2.6. Restrict Recurrence Instances Sent to Attendees . . . 28
- 5.2.7. Forcing the Server to Send a Scheduling Message . . . 29
- 6. Processing Incoming Scheduling Messages . . . . . . . . . . . 30
- 6.1. Processing Organizer Requests, Additions, and
- Cancellations . . . . . . . . . . . . . . . . . . . . . . 30
- 6.2. Processing Attendee Replies . . . . . . . . . . . . . . . 31
- 6.3. Scheduling Messages as Notifications . . . . . . . . . . . 31
- 6.4. Default Calendar Collection . . . . . . . . . . . . . . . 31
- 6.4.1. Additional Method Preconditions . . . . . . . . . . . 32
- 6.4.1.1. CALDAV:default-calendar-needed Precondition . . . 32
- 6.4.1.2. CALDAV:valid-schedule-default-calendar-URL
- Precondition . . . . . . . . . . . . . . . . . . . 33
- 7. Request for Busy Time Information . . . . . . . . . . . . . . 34
- 7.1. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 34
- 7.2. Additional Method Preconditions . . . . . . . . . . . . . 34
- 7.2.1. DAV:need-privileges Precondition . . . . . . . . . . . 34
- 7.2.2. CALDAV:supported-collection Precondition . . . . . . . 35
- 7.2.3. CALDAV:supported-calendar-data Precondition . . . . . 36
- 7.2.4. CALDAV:valid-calendar-data Precondition . . . . . . . 36
- 7.2.5. CALDAV:valid-scheduling-message Precondition . . . . . 37
- 7.2.6. CALDAV:valid-organizer Precondition . . . . . . . . . 37
- 7.2.7. CALDAV:max-resource-size Precondition . . . . . . . . 38
- 7.3. Response to a POST request . . . . . . . . . . . . . . . . 38
- 8. Avoiding Conflicts when Updating Scheduling Object
- Resources . . . . . . . . . . . . . . . . . . . . . . . . . . 40
- 8.1. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
- 8.2. DELETE, COPY or MOVE . . . . . . . . . . . . . . . . . . . 42
- 9. Other Scheduling Considerations . . . . . . . . . . . . . . . 44
- 9.1. Attendee Participation Status . . . . . . . . . . . . . . 44
- 9.2. Schedule Status Values . . . . . . . . . . . . . . . . . . 45
- 10. Additional iCalendar Property Parameters . . . . . . . . . . . 49
- 10.1. Schedule Agent Parameter . . . . . . . . . . . . . . . . . 49
- 10.2. Schedule Force Send Parameter . . . . . . . . . . . . . . 50
- 10.3. Schedule Status Parameter . . . . . . . . . . . . . . . . 51
- 11. Additional Message Header Fields . . . . . . . . . . . . . . . 53
- 11.1. Schedule-Reply Request Header . . . . . . . . . . . . . . 53
- 11.2. Schedule-Tag Response Header . . . . . . . . . . . . . . . 53
- 11.3. If-Schedule-Tag-Match Request Header . . . . . . . . . . . 54
- 12. Additional WebDAV Properties . . . . . . . . . . . . . . . . . 55
- 12.1. CALDAV:schedule-calendar-transp Property . . . . . . . . . 55
- 12.2. CALDAV:schedule-default-calendar-URL Property . . . . . . 56
- 12.3. CALDAV:schedule-tag Property . . . . . . . . . . . . . . . 57
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 3]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- 13. Scheduling Access Control . . . . . . . . . . . . . . . . . . 58
- 13.1. Scheduling Privileges . . . . . . . . . . . . . . . . . . 58
- 13.1.1. Privileges on Scheduling Inbox Collections . . . . . . 58
- 13.1.1.1. CALDAV:schedule-deliver Privilege . . . . . . . . 58
- 13.1.1.2. CALDAV:schedule-deliver-invite Privilege . . . . . 59
- 13.1.1.3. CALDAV:schedule-deliver-reply Privilege . . . . . 59
- 13.1.1.4. CALDAV:schedule-query-freebusy Privilege . . . . . 59
- 13.1.2. Privileges on Scheduling Outbox Collections . . . . . 59
- 13.1.2.1. CALDAV:schedule-send Privilege . . . . . . . . . . 59
- 13.1.2.2. CALDAV:schedule-send-invite Privilege . . . . . . 60
- 13.1.2.3. CALDAV:schedule-send-reply Privilege . . . . . . . 60
- 13.1.2.4. CALDAV:schedule-send-freebusy Privilege . . . . . 60
- 13.1.3. Aggregation of Scheduling Privileges . . . . . . . . . 60
- 13.2. Additional Principal Properties . . . . . . . . . . . . . 61
- 13.2.1. CALDAV:schedule-inbox-URL Property . . . . . . . . . . 61
- 13.2.2. CALDAV:schedule-outbox-URL Property . . . . . . . . . 62
- 13.2.3. CALDAV:calendar-user-address-set Property . . . . . . 62
- 13.2.4. CALDAV:calendar-user-type Property . . . . . . . . . . 63
- 14. XML Element Definitions . . . . . . . . . . . . . . . . . . . 65
- 14.1. CALDAV:schedule-response XML Element . . . . . . . . . . . 65
- 14.2. CALDAV:response XML Element . . . . . . . . . . . . . . . 65
- 14.3. CALDAV:recipient XML Element . . . . . . . . . . . . . . . 65
- 14.4. CALDAV:request-status XML Element . . . . . . . . . . . . 66
- 15. Security Considerations . . . . . . . . . . . . . . . . . . . 67
- 15.1. Verifying Scheduling Transactions . . . . . . . . . . . . 67
- 15.2. Verifying Busy Time Information Requests . . . . . . . . . 67
- 15.3. Privacy Issues . . . . . . . . . . . . . . . . . . . . . . 68
- 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69
- 16.1. Message Header Field Registrations . . . . . . . . . . . . 69
- 16.1.1. Schedule-Reply . . . . . . . . . . . . . . . . . . . . 69
- 16.1.2. Schedule-Tag . . . . . . . . . . . . . . . . . . . . . 69
- 16.1.3. If-Schedule-Tag-Match . . . . . . . . . . . . . . . . 69
- 16.2. iCalendar Property Parameter Registrations . . . . . . . . 70
- 16.3. iCalendar REQUEST-STATUS Value Registrations . . . . . . . 70
- 16.4. Additional iCalendar Elements Registries . . . . . . . . . 70
- 16.4.1. Schedule Agent Values Registry . . . . . . . . . . . . 70
- 16.4.2. Schedule Force Send Values Registry . . . . . . . . . 71
- 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 72
- 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 73
- 18.1. Normative References . . . . . . . . . . . . . . . . . . . 73
- 18.2. Informative References . . . . . . . . . . . . . . . . . . 74
- Appendix A. Scheduling Privileges Summary . . . . . . . . . . . . 75
- A.1. Scheduling Inbox Privileges . . . . . . . . . . . . . . . 75
- A.2. Scheduling Outbox Privileges . . . . . . . . . . . . . . . 75
- Appendix B. Example Scheduling Transactions . . . . . . . . . . . 77
- B.1. Example: Organizer Inviting Multiple Attendees . . . . . . 77
- B.2. Example: Attendee Receiving an Invitation . . . . . . . . 79
- B.3. Example: Attendee Replying to an Invitation . . . . . . . 81
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 4]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- B.4. Example: Organizer Receiving a Reply to an Invitation . . 83
- B.5. Example: Organizer Requesting Busy Time Information . . . 85
- B.6. Example: User Attempting to Invite Attendee on behalf
- of Organizer . . . . . . . . . . . . . . . . . . . . . . . 87
- B.7. Example: Attendee Declining an Instance of a Recurring
- Event . . . . . . . . . . . . . . . . . . . . . . . . . . 88
- B.8. Example: Attendee Removing an Instance of a Recurring
- Event . . . . . . . . . . . . . . . . . . . . . . . . . . 92
- Appendix C. Changes (to be removed by RFC Editor prior to
- publication) . . . . . . . . . . . . . . . . . . . . 95
- C.1. Changes in -10 . . . . . . . . . . . . . . . . . . . . . . 95
- C.2. Changes in -09 . . . . . . . . . . . . . . . . . . . . . . 95
- C.3. Changes in -08 . . . . . . . . . . . . . . . . . . . . . . 96
- C.4. Changes in -07 . . . . . . . . . . . . . . . . . . . . . . 97
- C.5. Changes in -06 . . . . . . . . . . . . . . . . . . . . . . 97
- C.6. Changes in -05 . . . . . . . . . . . . . . . . . . . . . . 98
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 5]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
-1. Introduction
-
- This document specifies extensions to the CalDAV "calendar-access"
- [RFC4791] feature to enable scheduling of iCalendar-based [RFC5545]
- calendar components between Calendar Users. This extension leverages
- the scheduling methods defined in the iCalendar Transport-independent
- Interoperability Protocol (iTIP) [RFC5546] to permit Calendar Users
- to perform scheduling transactions such as schedule, reschedule,
- respond to scheduling request or cancel calendar components, as well
- as search for busy time information.
-
- Discussion of this Internet-Draft is taking place on the mailing list
- .
-
-1.1. Terminology
-
- This specification uses much of the same terminology as iCalendar
- [RFC5545], iTIP [RFC5546], WebDAV [RFC4918], and CalDAV [RFC4791].
- The following definitions are provided to aid the reader in
- understanding this specification.
-
- Calendar User (CU): An entity (often a human) that accesses calendar
- information [RFC3283].
-
- Calendar collection: A resource that acts as a container of
- references to child calendar object resources [RFC4791].
-
- Calendar object resource: A resource representing a calendar object
- (event, to-do, journal entry, or other calendar components)
- [RFC4791].
-
- Scheduling object resource: A calendar object resource contained in
- a calendar collection for which the server will take care of
- sending scheduling messages on behalf of the owner of the calendar
- collection.
-
- Organizer scheduling object resource: A scheduling object resource
- owned by an Organizer.
-
- Attendee scheduling object resource: A scheduling object resource
- owned by an Attendee.
-
- Automatic scheduling transaction: Add, change or remove operations
- on a scheduling object resource for which the server will deliver
- scheduling messages to other Calendar Users.
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 6]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- Scheduling message: A calendar object that describes a scheduling
- transaction such as schedule, reschedule, reply, or cancel.
-
- Scheduling Outbox collection: A resource at which busy time
- information requests are targeted.
-
- Scheduling Inbox collection: A collection in which incoming
- scheduling messages are delivered.
-
-1.2. Approach
-
- iTIP [RFC5546] outlines a model where Calendar Users exchange
- scheduling messages with one another. Often times, clients are made
- responsible for generating and sending scheduling messages as well as
- processing incoming scheduling messages. This approach yields a
- number of problems, including:
-
- o For most updates to a calendar component, clients are responsible
- for sending appropriate scheduling messages to the Organizer or
- the Attendees.
-
- o The handling of incoming scheduling messages and the updates to
- calendars impacted by those messages only occurs when clients are
- active.
-
- o Due to the update latency, it is possible for calendars of
- different Calendar Users to reflect different, inaccurate states.
-
- This specification uses an alternative approach where the server is
- made responsible for sending scheduling messages and processing
- incoming scheduling messages. This approach frees the clients from
- the submission and processing of scheduling messages and ensures
- better consistency of calendar data across users' calendars. The
- operation of creating, modifying or deleting a calendar component in
- a calendar is enough to trigger the server to deliver the necessary
- scheduling messages to the appropriate Calendar Users.
-
-1.3. Limitations
-
- While the scheduling features described in this specification are
- based on iTIP [RFC5546], some of its more advanced features have
- deliberately been left out in order to keep this specification
- simple. In particular, the following iTIP [RFC5546] features are not
- covered: publishing, countering, delegating, refreshing and
- forwarding calendar components, as well as replacing the Organizer of
- a calendar component.
-
- The goal of this specification is to provide the essential scheduling
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 7]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- features needed. It is expected that future extensions will be
- developed to address the more advanced features.
-
-1.4. Notational Conventions
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
- The Augmented BNF (ABNF) syntax used by this document to specify the
- format definition of new iCalendar elements is defined in [RFC5234].
-
- The Augmented BNF (ABNF) syntax used by this document to specify the
- format definition of new message header fields to be used with the
- HTTP/1.1 protocol is described in Section 2.1 of [RFC2616]. Since
- this Augmented BNF uses the basic production rules provided in
- Section 2.2 of [RFC2616], these rules apply to this document as well.
-
- The term "protected" is used in the Conformance field of WebDAV
- property definitions as defined in Section 15 of [RFC4918].
-
-1.5. XML Namespaces and Processing
-
- This document uses XML DTD fragments ([W3C.REC-xml-20081126], Section
- 3.2) as a purely notational convention. WebDAV request and response
- bodies cannot be validated by a DTD due to the specific extensibility
- rules defined in Section 17 of [RFC4918] and due to the fact that all
- XML elements defined by that specification use the XML namespace name
- "DAV:". In particular:
-
- 1. element names use the "DAV:" namespace,
-
- 2. element ordering is irrelevant unless explicitly stated,
-
- 3. extension elements (elements not already defined as valid child
- elements) may be added anywhere, except when explicitly stated
- otherwise,
-
- 4. extension attributes (attributes not already defined as valid for
- this element) may be added anywhere, except when explicitly
- stated otherwise.
-
- The XML elements specified in this document are defined in the
- "urn:ietf:params:xml:ns:caldav" XML namespace registered by CalDAV
- [RFC4791].
-
- When XML element types in the namespaces "DAV:" and
- "urn:ietf:params:xml:ns:caldav" are referenced in this document
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 8]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- outside of the context of an XML fragment, the strings "DAV:" and
- "CALDAV:" will be prefixed to the element types, respectively.
-
- This document inherits, and sometimes extends, DTD productions from
- Section 14 of [RFC4918].
-
- Also note that some CalDAV XML element names are identical to WebDAV
- XML element names, though their namespace differs. Care must be
- taken not to confuse the two sets of names.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 9]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
-2. Scheduling Process
-
- The process of scheduling an event between different parties often
- involves a series of steps with different actors playing particular
- roles during the whole process. Typically there is an event
- "Organizer" whose role is to schedule an event between one or more
- "Attendees", and this is done by sending out invitations and handling
- responses from each Attendee.
-
- This process can typically be broken down into two phases.
-
- In the first phase, the Organizer will query the busy time
- information of each Attendee to determine the most appropriate time
- for the event. This request is sometimes called a "freebusy" lookup.
-
- In the second phase, the Organizer sends out invitations to each
- Attendee using the time previously determined from the freebusy
- lookup. There then follows exchanges between Organizer and Attendees
- regarding the invitation. Some Attendees may choose to attend at the
- time proposed by the Organizer, others may decline to attend. The
- Organizer needs to process each of the replies from the Attendees and
- take appropriate action to confirm the event, reschedule it or
- perhaps cancel it.
-
- The user expectation as to how a calendaring and scheduling system
- should respond in each of these two phases is somewhat different. In
- the case of a freebusy lookup, users expect to get back results
- immediately so that they can then move on to the invitation phase as
- quickly as possible. In the case of invitations, it is expected that
- each Attendee will reply with their participation status in their own
- time, so delays in receiving replies are anticipated. Thus
- calendaring and scheduling systems should treat these two operational
- phases in different ways to accommodate the user expectations, which
- is what this specification does.
-
- While the scenario described above only covers the case of scheduling
- events between Calendar Users, and requesting busy time information,
- this specification also provides support for the scheduling of to-dos
- between Calendar Users. For the majority of the following
- discussion, scheduling of events and freebusy lookups will be
- discussed, as these are the more common operations.
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 10]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
-3. Scheduling Support
-
- A server that supports the features described in this document MUST
- include "calendar-auto-schedule" as a field in the DAV response
- header from an OPTIONS request on any resource that supports any
- scheduling actions, properties, privileges or methods.
-
- To advertise support for the CalDAV "calendar-auto-schedule" feature
- a server is REQUIRED to support and advertise support for the CalDAV
- "calendar-access" [RFC4791] feature.
-
-3.1. Example OPTIONS Request
-
- In this example, the OPTIONS response indicates that the server
- supports the "calendar-access" and "calendar-auto-schedule" features
- and that the resource "/home/cyrus/calendars/inbox/" supports the
- scheduling actions, properties, privileges and methods defined in
- this specification.
-
- >> Request <<
-
- OPTIONS /home/cyrus/calendars/inbox/ HTTP/1.1
- Host: cal.example.com
-
- >> Response <<
-
- HTTP/1.1 204 No Content
- Date: Thu, 31 Mar 2011 09:00:00 GMT
- Allow: OPTIONS, GET, HEAD, DELETE, TRACE, PROPFIND
- Allow: PROPPATCH, LOCK, UNLOCK, REPORT, ACL
- DAV: 1, 2, 3, access-control
- DAV: calendar-access, calendar-auto-schedule
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 11]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
-4. Scheduling Collections
-
- This specification introduces new collection resource types that are
- used to manage scheduling object resources, and scheduling
- privileges, as well as provide scheduling functionality. It is the
- server's responsibility to create these collection resources, and
- clients have no way to create or delete them.
-
-4.1. Scheduling Outbox Collection
-
- A scheduling Outbox collection is used as the target for busy time
- information requests, and to manage privileges that apply to outgoing
- scheduling requests.
-
- A scheduling Outbox collection MUST report the DAV:collection and
- CALDAV:schedule-outbox XML elements in the value of the DAV:
- resourcetype property. The element type declaration for CALDAV:
- schedule-outbox is:
-
-
-
- Example:
-
-
-
-
-
-
- New WebDAV ACL [RFC3744] privileges can be set on the scheduling
- Outbox collection to control who is allowed to send scheduling
- messages on behalf of the Calendar User associated with the
- scheduling Outbox collection. See Section 13.1 for more details.
-
- A scheduling Outbox collection MUST NOT be a child (at any depth) of
- a calendar collection resource.
-
- The following WebDAV properties specified in CalDAV "calendar-access"
- [RFC4791] MAY also be defined on scheduling Outbox collections:
-
- CALDAV:supported-calendar-component-set - when present this
- indicates the allowed calendar component types for scheduling
- messages submitted to the scheduling Outbox collection with the
- POST method.
-
- CALDAV:supported-calendar-data - when present this indicates the
- allowed media types for scheduling messages submitted to the
- scheduling Outbox collection with the POST method.
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 12]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- CALDAV:max-resource-size - when present this indicates the maximum
- size in octets of a resource that the server is willing to accept
- for scheduling messages submitted to the scheduling Outbox
- collection with the POST method.
-
- CALDAV:min-date-time - when present this indicates the earliest
- date and time (in UTC) that the server is willing to accept for
- any DATE or DATE-TIME value in scheduling messages submitted to
- the scheduling Outbox collection with the POST method.
-
- CALDAV:max-date-time - when present this indicates the latest date
- and time (in UTC) that the server is willing to accept for any
- DATE or DATE-TIME value in scheduling messages submitted to the
- scheduling Outbox collection with the POST method.
-
- CALDAV:max-attendees-per-instance - when present this indicates
- the maximum number of ATTENDEE properties in any instance of
- scheduling messages submitted to the scheduling Outbox collection
- with the POST method. Specifically, this limits the total number
- of Attendees whose freebusy information can be queried in a single
- request.
-
- The use of child resources in a scheduling Outbox collection is
- reserved for future revisions or extensions of this specification.
-
-4.2. Scheduling Inbox Collection
-
- A scheduling Inbox collection contains copies of incoming scheduling
- messages. These may be requests sent by an Organizer, or replies
- sent by an Attendee in response to a request. The scheduling Inbox
- collection is also used to manage scheduling privileges.
-
- A scheduling Inbox collection MUST report the DAV:collection and
- CALDAV:schedule-inbox XML elements in the value of the DAV:
- resourcetype property. The element type declaration for CALDAV:
- schedule-inbox is:
-
-
-
- Example:
-
-
-
-
-
-
- Scheduling Inbox collections MUST only contain calendar object
- resources that obey the restrictions specified in iTIP [RFC5546].
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 13]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- Consequently, scheduling Inbox collections MUST NOT contain any types
- of collection resources. Restrictions defined in Section 4.1 of
- CalDAV "calendar-access" [RFC4791] on calendar object resources
- contained in calendar collections (e.g., "UID" uniqueness) do not
- apply to calendar object resources contained in a scheduling Inbox
- collection. Thus, multiple calendar object resources contained in a
- scheduling Inbox collection can have the same "UID" property value
- (i.e., multiple scheduling messages for the same calendar component).
-
- New WebDAV ACL [RFC3744] privileges can be set on the scheduling
- Inbox collection to control from whom the Calendar User associated
- with the scheduling Inbox collection will accept scheduling messages
- from. See Section 13.1 for more details.
-
- A scheduling Inbox collection MUST NOT be a child (at any depth) of a
- calendar collection resource.
-
- The following WebDAV properties specified in CalDAV "calendar-access"
- [RFC4791] MAY also be defined on scheduling Inbox collections:
-
- CALDAV:calendar-timezone - when present this contains a time zone
- that the server can use when calendar date-time operations are
- carried out, for example when a time-range CALDAV:calendar-query
- REPORT is targeted at a scheduling Inbox collection.
-
- CALDAV:supported-calendar-component-set - when present this
- indicates the allowed calendar component types for scheduling
- messages delivered to the scheduling Inbox collection.
-
- CALDAV:supported-calendar-data - when present this indicates the
- allowed media types for scheduling messages delivered to the
- scheduling Inbox collection.
-
- CALDAV:max-resource-size - when present this indicates the maximum
- size in octets of a resource that the server is willing to accept
- for scheduling messages delivered to the scheduling Inbox
- collection.
-
- CALDAV:min-date-time - when present this indicates the earliest
- date and time (in UTC) that the server is willing to accept for
- any DATE or DATE-TIME value in scheduling messages delivered to
- the scheduling Inbox collection.
-
- CALDAV:max-date-time - when present this indicates the latest date
- and time (in UTC) that the server is willing to accept for any
- DATE or DATE-TIME value in scheduling messages delivered to the
- scheduling Inbox collection.
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 14]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- CALDAV:max-instances - when present this indicates the maximum
- number of recurrence instances in scheduling messages delivered to
- the scheduling Inbox collection.
-
- CALDAV:max-attendees-per-instance - when present this indicates
- the maximum number of ATTENDEE properties in any instance of
- scheduling messages delivered to the scheduling Inbox collection.
-
-4.3. Calendaring Reports Extensions
-
- This specification extends the CALDAV:calendar-query and CALDAV:
- calendar-multiget REPORTs to return results for calendar object
- resources in scheduling Inbox collections.
-
- When a CALDAV:calendar-query REPORT includes a time-range query and
- targets a scheduling Inbox collection, if any calendar object
- resources contain "VEVENT" calendar components that do not include a
- "DTSTART" iCalendar property (as allowed by iTIP [RFC5546]) then such
- components MUST always match the time-range query test.
-
- Note that the CALDAV:free-busy-query REPORT is not supported on
- scheduling Inbox collections.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 15]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
-5. Scheduling Transactions
-
- When a calendar object resource is created, modified or removed from
- a calendar collection, the server examines the calendar data and
- checks to see whether the data represents a scheduling object
- resource. If it does, the server will automatically attempt to
- deliver a scheduling message to the appropriate Calendar Users.
- Several types of scheduling operations can occur in this case,
- equivalent to iTIP "REQUEST", "REPLY", "CANCEL", and "ADD"
- operations.
-
-5.1. Identifying Scheduling Object Resources
-
- Calendar object resources on which the server performs automatic
- scheduling transactions are referred to as scheduling object
- resources. There are two types of scheduling object resources:
- organizer scheduling object resources, and attendee scheduling object
- resources.
-
- A calendar object resource is considered to be a valid organizer
- scheduling object resource if the "ORGANIZER" iCalendar property is
- present and set in all the calendar components to a value that
- matches one of the calendar user addresses of the owner of the
- calendar collection.
-
- A calendar object resource is considered to be a valid attendee
- scheduling object resource if the "ORGANIZER" iCalendar property is
- present and set in all the calendar components to the same value and
- doesn't match one of the calendar user addresses of the owner of the
- calendar collection, and at least one of the "ATTENDEE" iCalendar
- property values matches one of the calendar user addresses of the
- owner of the calendar collection.
-
- The creation of attendee scheduling object resources is typically
- done by the server, with the resource being created in an appropriate
- calendar collection (see Section 6.4).
-
-5.2. Handling Scheduling Object Resources
-
- The server's behavior when processing a scheduling object resource
- depends on whether it is owned by the Organizer or an Attendee
- specified in the calendar data.
-
-5.2.1. Organizer Scheduling Object Resources
-
- An Organizer can create, modify or remove a scheduling object
- resource. The create, modify and remove behaviors for the server are
- each described next, and the way these are invoked via HTTP requests
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 16]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- is described in Section 5.2.3.
-
- The Organizer of a calendar component may also be an Attendee of that
- calendar component. In such cases the server MUST NOT send a
- scheduling message to the Attendee that matches the Organizer.
-
-5.2.1.1. Create
-
- When a scheduling object resource is created by the Organizer, the
- server will inspect each "ATTENDEE" property to determine if a
- scheduling message should be delivered to this Attendee according to
- the value of the "SCHEDULE-AGENT" property parameter (see
- Section 10.1) as described in the table below:
-
- +------------------+-------------+
- | SCHEDULE-AGENT | iTIP METHOD |
- +==================+=============+
- | SERVER (default) | REQUEST |
- +------------------+-------------+
- | CLIENT | -- |
- +------------------+-------------+
- | NONE | -- |
- +------------------+-------------+
-
- The attempt to deliver the scheduling message will either succeed or
- fail. In all cases, the server MUST add a "SCHEDULE-STATUS"
- iCalendar property parameter (see Section 10.3) to the "ATTENDEE"
- iCalendar property in the scheduling object resource being created,
- and set its value as described in Section 9.2. This will result in
- the created calendar object resource differing from the calendar data
- sent in the HTTP request. As a result clients MAY reload the
- calendar data from the server in order to update to the new server
- generated state information. Servers MUST NOT set the "SCHEDULE-
- STATUS" property parameter on the "ATTENDEE" property of Attendees
- for which it did not attempt to deliver a scheduling message.
-
- Restrictions:
-
- 1. The server SHOULD reject any attempt to set the "PARTSTAT"
- iCalendar property parameter value of the "ATTENDEE" iCalendar
- property of other users in the calendar object resource to a
- value other than "NEEDS-ACTION" if the "SCHEDULE-AGENT" property
- parameter value is not present or set to the value "SERVER".
-
- 2. The server MAY reject attempts to create a scheduling object
- resource that specifies a "UID" property value already specified
- in a scheduling object resource contained in another calendar
- collection of the Organizer.
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 17]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- 3. The server MUST take into account scheduling privileges as
- described in Section 13.1 when handling the creation of a
- scheduling object resource.
-
- 4. Restrictions on calendar object resources defined in Section 4.1
- of [RFC4791] MUST also be enforced.
-
- The server MUST return an error with the CALDAV:allowed-organizer-
- scheduling-object-change precondition code (Section 5.2.4.3) when the
- Organizer attempts to change the iCalendar data in a manner that is
- forbidden.
-
-5.2.1.2. Modify
-
- When a scheduling object resource is modified by the Organizer, the
- server will inspect each "ATTENDEE" property in the new calendar data
- to determine which ones have the "SCHEDULE-AGENT" iCalendar property
- parameter. It will then need to compare this with the "ATTENDEE"
- properties in the existing calendar object resource that is being
- modified.
-
- For each Attendee in the old and new calendar data on a per-instance
- basis, and taking into account the addition or removal of Attendees,
- the server will determine whether to deliver a scheduling message to
- the Attendee. The following table determines whether the server
- needs to deliver a scheduling message, and if so which iTIP
- scheduling method to use. The values "SERVER", "CLIENT", and "NONE"
- in the top and left titles of the table refer to the "SCHEDULE-AGENT"
- parameter value of the "ATTENDEE" property, and the values ""
- and "" are used to cover the cases where the "ATTENDEE"
- property is not present (Old) or is being removed (New).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 18]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- +---------------+-----------------------------------------------+
- | | New |
- | ATTENDEE +-----------+-----------+-----------+-----------+
- | | | SERVER | CLIENT | NONE |
- | | | (default) | | |
- +===+===========+===========+===========+===========+===========+
- | | | -- | REQUEST / | -- | -- |
- | | | | ADD | | |
- | +-----------+-----------+-----------+-----------+-----------+
- | | SERVER | CANCEL | REQUEST | CANCEL | CANCEL |
- | O | (default) | | | | |
- | l +-----------+-----------+-----------+-----------+-----------+
- | d | CLIENT | -- | REQUEST / | -- | -- |
- | | | | ADD | | |
- | +-----------+-----------+-----------+-----------+-----------+
- | | NONE | -- | REQUEST / | -- | -- |
- | | | | ADD | | |
- +---+-----------+-----------+-----------+-----------+-----------+
-
- The attempt to deliver the scheduling message will either succeed or
- fail. In all cases, the server MUST add a "SCHEDULE-STATUS"
- iCalendar property parameter to the "ATTENDEE" iCalendar property in
- the scheduling object resource being modified, and set its value as
- described in Section 9.2. This will result in the created calendar
- object resource differing from the calendar data sent in the HTTP
- request. As a result clients MAY reload the calendar data from the
- server in order to update to the new server generated state
- information.
-
- Restrictions:
-
- 1. The server MAY reject any attempt to set the "PARTSTAT" iCalendar
- property parameter value of the "ATTENDEE" iCalendar property of
- other users in the calendar object resource to a value other than
- "NEEDS-ACTION" if the "SCHEDULE-AGENT" property parameter value
- is not present or set to the value "SERVER".
-
- 2. The server MUST take into account scheduling privileges as
- described in Section 13.1 when handling the modification of a
- scheduling object resource.
-
- 3. Restrictions on calendar object resources defined in Section 4.1
- of [RFC4791] MUST also be enforced.
-
- The server MUST return an error with the CALDAV:allowed-organizer-
- scheduling-object-change precondition code (Section 5.2.4.3) when the
- Organizer attempts to change the iCalendar data in a manner that is
- forbidden.
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 19]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
-5.2.1.3. Remove
-
- When a scheduling object resource is removed by the Organizer, the
- server will inspect each "ATTENDEE" property in the scheduling object
- resource being removed to determine which ones have the "SCHEDULE-
- AGENT" iCalendar property parameter.
-
- For each Attendee the server will determine whether to attempt to
- deliver a scheduling message into the Attendee's scheduling Inbox
- collection, based on the table below:
-
- +------------------+-------------+
- | SCHEDULE-AGENT | iTIP METHOD |
- +==================+=============+
- | SERVER (default) | CANCEL |
- +------------------+-------------+
- | CLIENT | -- |
- +------------------+-------------+
- | NONE | -- |
- +------------------+-------------+
-
- Restrictions:
-
- 1. The server MUST take into account scheduling privileges as
- described in Section 13.1 when handling the deletion of a
- scheduling object resource.
-
-5.2.2. Attendee Scheduling Object Resources
-
- An Attendee can create, modify or remove a scheduling object resource
- by issuing HTTP requests with an appropriate method. The create,
- modify and remove behaviors for the server are each described next,
- and the way these are invoked via HTTP requests is described in
- Section 5.2.3.
-
-5.2.2.1. Allowed Attendee Changes
-
- Attendees are allowed to make some changes to a scheduling object
- resource, though key properties such as start time, end time,
- location, and summary are typically under the control of the
- Organizer.
-
- The server MUST allow Attendees to:
-
- 1. change their own "PARTSTAT" iCalendar property parameter value.
-
- 2. add, modify or remove any "TRANSP" iCalendar properties.
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 20]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- 3. add, modify or remove any "PERCENT-COMPLETE" iCalendar
- properties.
-
- 4. add, modify or remove any "COMPLETED" iCalendar properties.
-
- 5. add, modify or remove any "VALARM" iCalendar components.
-
- 6. add, modify or remove the "CALSCALE" iCalendar property within
- the top-level "VCALENDAR" component.
-
- 7. modify the "PRODID" iCalendar property within the top-level
- "VCALENDAR" component.
-
- 8. add "EXDATE" iCalendar properties and possibly remove components
- for overridden recurrence instances.
-
- 9. add, modify or remove any "CREATED", "DTSTAMP" and "LAST-
- MODIFIED" iCalendar properties.
-
- 10. add, modify or remove "SCHEDULE-STATUS" iCalendar property
- parameters on "ATTENDEE" properties that have a "SCHEDULE-AGENT"
- parameter set to "CLIENT".
-
- 11. add new components to represent overridden recurrence instances,
- provided the only changes to the recurrence instance follow the
- rules above.
-
- The server MUST return an error with the CALDAV:allowed-attendee-
- scheduling-object-change precondition code (Section 5.2.4.4) when the
- Attendee attempts to change the iCalendar data in a manner forbidden
- by the server.
-
-5.2.2.2. Create
-
- Typically an Attendee does not create scheduling object resources, as
- scheduling messages delivered to them on the server are automatically
- processed by the server and placed on one of their calendars (see
- Section 6). However, in some cases a scheduling message may get
- delivered directly to the client, and the Attendee may wish to store
- that on the server. In that case the client creates a scheduling
- object resource in a suitable calendar belonging to the Attendee. It
- can then set the "SCHEDULE-AGENT" iCalendar property parameter on all
- "ORGANIZER" iCalendar properties in the resource to determine how the
- server treats the resource. The value of the "SCHEDULE-AGENT"
- iCalendar property parameter on all "ORGANIZER" iCalendar properties
- MUST be the same.
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 21]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- +----------------+--------------------------------------------------+
- | SCHEDULE-AGENT | Action |
- +----------------+--------------------------------------------------+
- | SERVER | The server will attempt to process changes to |
- | (default) | the resource using the normal rules for attendee |
- | | scheduling object resources. |
- | | |
- | CLIENT | The server does no special processing of the |
- | | resource. The client is assumed to be handling |
- | | Attendee replies etc. |
- | | |
- | NONE | The server does no special processing of the |
- | | resource. |
- +----------------+--------------------------------------------------+
-
- In some cases a server may not be able to process an Attendee
- scheduling object resource that originated from another system (i.e.,
- where the server is unable to deliver scheduling messages to the
- Organizer). In such cases the server MUST add a "SCHEDULE-STATUS"
- iCalendar property parameter to all "ORGANIZER" iCalendar properties
- in the resource with a suitable value indicating a error.
-
-5.2.2.3. Modify
-
- When a scheduling object resource is modified by an Attendee, the
- server behavior depends on the value of the "SCHEDULE-AGENT"
- iCalendar property parameter on the "ORGANIZER" iCalendar properties:
-
- +----------------+--------------------------------------------------+
- | SCHEDULE-AGENT | Action |
- +----------------+--------------------------------------------------+
- | SERVER | The server will attempt to process the removal |
- | (default) | using the behavior listed below. |
- | | |
- | CLIENT | The server does no special processing of the |
- | | resource. The client is assumed to be handling |
- | | any Attendee replies etc. |
- | | |
- | NONE | The server does no special processing of the |
- | | resource. |
- +----------------+--------------------------------------------------+
-
- The server will inspect the changes by comparing the new scheduling
- object resource with the existing scheduling object resource.
-
- If the Attendee changes one or more "PARTSTAT" iCalendar property
- values on any component, or adds an overridden component with a
- changed "PARTSTAT" property, then the server MUST deliver an iTIP
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 22]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- "REPLY" scheduling message to the Organizer to indicate the new
- participation status of the Attendee.
-
- If the Attendee adds an "EXDATE" property value to effectively remove
- a recurrence instance, the server MUST deliver an iTIP "REPLY"
- scheduling message to the Organizer to indicate that the Attendee has
- declined the instance (i.e., the Attendee's "PARTSTAT" iCalendar
- property parameter value is set to "DECLINED").
-
- The attempt to deliver the scheduling message will either succeed or
- fail. In all cases, the server MUST add a "SCHEDULE-STATUS"
- iCalendar property parameter to the "ORGANIZER" iCalendar property in
- the scheduling object resource being created, and set its value as
- described in Section 9.2. This will result in the created calendar
- object resource differing from the calendar data sent in the HTTP
- request. As a result clients MAY reload the calendar data from the
- server in order to update to the new server generated state
- information.
-
-5.2.2.4. Remove
-
- When a scheduling object resource is removed by an Attendee, the
- server behavior depends on the value of the "SCHEDULE-AGENT"
- iCalendar property parameter on the "ORGANIZER" iCalendar properties:
-
- +----------------+--------------------------------------------------+
- | SCHEDULE-AGENT | Action |
- +----------------+--------------------------------------------------+
- | SERVER | The server will attempt to process the removal |
- | (default) | using either behaviors (1) or (2) listed below. |
- | | |
- | CLIENT | The server does no special processing of the |
- | | resource. The client is assumed to be handling |
- | | any Attendee replies etc. |
- | | |
- | NONE | The server does no special processing of the |
- | | resource. |
- +----------------+--------------------------------------------------+
-
- 1. If the HTTP request contains a "Schedule-Reply" request header
- set to the value "T" or there is no "Schedule-Reply" request
- header, then the server MUST attempt to deliver a scheduling
- message to the Organizer indicating that the Attendee has a
- "PARTSTAT" iCalendar property parameter value set to "DECLINED".
- That is, the Attendee has chosen not to attend any instances. If
- the server is unable to deliver the scheduling message, the
- remove action MUST fail, and an appropriate "SCHEDULE-STATUS"
- iCalendar property parameter set on the "ORGANIZER" property in
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 23]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- the scheduling object resource stored by the server.
-
- 2. If the HTTP request contains a "Schedule-Reply" request header
- set to the value "F", the server MUST NOT attempt to deliver a
- scheduling message. The resource is simply removed. This
- provides the client a way to silently remove unwanted scheduling
- messages.
-
-5.2.3. HTTP Methods
-
- This section describes how use of various HTTP methods on a
- scheduling object resource will cause a create, modify or remove
- action on that resource as described above. The use of these methods
- is subject to the restrictions in [RFC4791], in addition to what is
- described below.
-
-5.2.3.1. PUT
-
- When a PUT method request is received, the server will execute the
- following actions, provided all appropriate preconditions are met:
-
- +--------------------------+--------------------------+-------------+
- | Existing Destination | Resulting Destination | Server |
- | Resource | Resource | Action |
- +--------------------------+--------------------------+-------------+
- | None | Calendar object resource | None |
- | | | |
- | None | Scheduling object | Create |
- | | resource | |
- | | | |
- | Calendar object resource | Calendar object resource | None |
- | | | |
- | Calendar object resource | Scheduling object | Create |
- | | resource | |
- | | | |
- | Scheduling object | Calendar object resource | Remove |
- | resource | | |
- | | | |
- | Scheduling object | Scheduling object | Modify |
- | resource | resource | |
- +--------------------------+--------------------------+-------------+
-
-5.2.3.2. COPY
-
- When a COPY method request is received, the server will execute the
- following actions based on the source and destination collections in
- the request:
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 24]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- +-------------------------+-------------------------+---------------+
- | Source Collection | Destination Collection | Server Action |
- +-------------------------+-------------------------+---------------+
- | Non-calendar collection | Non-calendar collection | None |
- | | | |
- | Non-calendar collection | Calendar collection | (1) |
- | | | |
- | Calendar collection | Non-calendar collection | None |
- | | | |
- | Calendar collection | Calendar collection | (2) |
- +-------------------------+-------------------------+---------------+
-
- Note 1. The same rules as used for PUT above are applied for the
- destination of the COPY request.
-
- Note 2. The server MAY reject this as per Section 5.2.4.1, otherwise
- None.
-
- The behavior of a COPY method request on a calendar collection is
- undefined.
-
-5.2.3.3. MOVE
-
- When a MOVE method request is received, the server will execute the
- following actions based on the source and destination collections in
- the request:
-
- +-------------------------+-------------------------+---------------+
- | Source Collection | Destination Collection | Server Action |
- +-------------------------+-------------------------+---------------+
- | Non-calendar collection | Non-calendar collection | None |
- | | | |
- | Non-calendar collection | Calendar collection | (1) |
- | | | |
- | Calendar collection | Non-calendar collection | (2) |
- | | | |
- | Calendar collection | Calendar collection | None |
- +-------------------------+-------------------------+---------------+
-
- Note 1. The same rules as used for PUT above are applied for the
- destination of the MOVE request.
-
- Note 2. The same rules as used for DELETE below are applied for the
- source of the MOVE request.
-
- The behavior of a MOVE method request on a calendar collection is
- undefined.
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 25]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
-5.2.3.4. DELETE
-
- When a DELETE method is targeted at a scheduling object resource the
- server will execute the Remove action.
-
- When a DELETE method is targeted at a calendar collection the server
- will execute the Remove action on all scheduling object resources
- contained in the calendar collection.
-
-5.2.4. Additional Method Preconditions
-
- This specification defines method preconditions (see Section 16 of
- WebDAV [RFC4918]), in addition to the ones in [RFC4791], to provide
- machine-parsable information in error responses.
-
-5.2.4.1. CALDAV:unique-scheduling-object-resource Precondition
-
- Name: unique-scheduling-object-resource
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Apply to: PUT, COPY, and MOVE
-
- Use with: 403 Forbidden
-
- Purpose: (precondition) -- Servers MAY reject requests to create a
- scheduling object resource with an iCalendar "UID" property value
- already in use by another scheduling object resource owned by the
- same user in other calendar collections. Servers SHOULD report
- the URL of the scheduling object resource that is already making
- use of the same "UID" property value in the DAV:href element.
-
- Definition:
-
-
-
- Example:
-
-
- /home/bernard/calendars/personal/abc123.ics
-
-
-5.2.4.2. CALDAV:same-organizer-in-all-components Precondition
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 26]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- Name: same-organizer-in-all-components
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Apply to: PUT, COPY, and MOVE
-
- Use with: 403 Forbidden
-
- Purpose: (precondition) -- All the calendar components in a
- scheduling object resource MUST contain the same "ORGANIZER"
- property value when present.
-
- Definition:
-
-
-
- Example:
-
-
-
-5.2.4.3. CALDAV:allowed-organizer-scheduling-object-change Precondition
-
- Name: allowed-organizer-scheduling-object-change
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Apply to: PUT, COPY, and MOVE
-
- Use with: 403 Forbidden
-
- Purpose: (precondition) -- Servers MAY impose restrictions on
- modifications allowed by an Organizer. For instance, servers MAY
- prevent the Organizer setting the "PARTSTAT" property parameter to
- a value other than "NEEDS-ACTION" if the corresponding "ATTENDEE"
- property has the "SCHEDULE-AGENT" property parameter set to
- "SERVER", or has no "SCHEDULE-AGENT" property parameter. See
- Section 5.2.1.
-
- Definition:
-
-
-
- Example:
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 27]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
-5.2.4.4. CALDAV:allowed-attendee-scheduling-object-change Precondition
-
- Name: allowed-attendee-scheduling-object-change
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Apply to: PUT, COPY, and MOVE
-
- Use with: 403 Forbidden
-
- Purpose: (precondition) -- Servers MAY impose restrictions on
- modifications allowed by an Attendee. Attendee modifications that
- servers MUST allow are specified in Section 5.2.2.1.
-
- Definition:
-
-
-
- Example:
-
-
-
-5.2.5. DTSTAMP and SEQUENCE Properties
-
- Whenever the server generates a scheduling message for delivery to a
- Calendar User, it MUST ensure that a "DTSTAMP" iCalendar property is
- present and MUST set the value to the UTC time that the scheduling
- message was generated (as required by iCalendar).
-
- iTIP [RFC5546] places certain requirements on how the "SEQUENCE"
- iCalendar property value in scheduling messages changes. The server
- MUST ensure that for each type of scheduling operation, the
- "SEQUENCE" iCalendar property value is appropriately updated. If the
- client does not update the "SEQUENCE" iCalendar property itself when
- that is required, the server MUST update the property.
-
-5.2.6. Restrict Recurrence Instances Sent to Attendees
-
- When delivering scheduling messages for recurring calendar components
- to Attendees, servers MUST ensure that Attendees only get information
- about recurrence instances that explicitly include them as an
- Attendee.
-
- For example, if an Attendee is invited to a single recurrence
- instance of a recurring event, and no others, the scheduling object
- resource contained in the Organizer's calendar collection will
- contain an overridden instance in the form of a separate calendar
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 28]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- component. That separate calendar component will include the
- "ATTENDEE" property referencing the "one-off" Attendee. That
- Attendee will not be listed in any other calendar components in the
- scheduling object resource. Any scheduling messages delivered to the
- Attendee will only contain information about this overridden
- instance.
-
- As another example, an Attendee could be excluded from one instance
- of a recurring event. In that case the scheduling object resource
- contained in the calendar collection of the Organizer will include an
- overridden instance with an "ATTENDEE" list that does not include the
- Attendee being excluded. The scheduling message that will be
- delivered to the Attendee will not specify the overridden instance
- but rather include an "EXDATE" property in the master recurring
- component defining the recurrence set.
-
-5.2.7. Forcing the Server to Send a Scheduling Message
-
- The iCalendar property parameter "SCHEDULE-FORCE-SEND" defined in
- Section 10.2 can be used by a Calendar User to force the server to
- send a scheduling message to an Attendee or the Organizer in a
- situation where the server would not normally send a scheduling
- message. For instance, an Organizer could use this property
- parameter to request an Attendee, that previously declined an
- invitation, to reconsider their participation status without being
- forced to modify the event.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 29]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
-6. Processing Incoming Scheduling Messages
-
- Scheduling operations can cause the delivery of a scheduling message
- into an Organizer's or Attendee's scheduling Inbox collection. In
- the former case the scheduling messages are replies from Attendees,
- in the latter case the scheduling messages are requests,
- cancellations or additions from the Organizer.
-
- Servers MUST automatically process incoming scheduling messages using
- the rules defined by [RFC5546], by creating or updating the
- corresponding scheduling object resources on calendars owned by the
- owner of the scheduling Inbox collection. In addition, the
- scheduling message is stored in the scheduling Inbox collection as an
- indicator to the client that a scheduling operation has taken place.
-
- The server MUST take into account privileges on the scheduling Inbox
- collection when processing incoming scheduling messages, to determine
- whether delivery of the scheduling message is allowed. Privileges on
- calendars containing any matching scheduling object resource are not
- considered in this case (i.e., a schedule message from another user
- can cause modifications to resources in calendar collections that the
- other user would not normally have read or write access to).
- Additionally, servers MUST take into account any scheduling Inbox
- collection preconditions (see Section 4.2) when delivering the
- scheduling message, and it MUST take into account the similar
- preconditions on any calendar collection which contains, or would
- contain, the corresponding scheduling object resource.
-
-6.1. Processing Organizer Requests, Additions, and Cancellations
-
- For a scheduling message sent by an Organizer, the server first tries
- to locate a corresponding scheduling object resource belonging to the
- Attendee. If no matching scheduling object resource exists, the
- server treats the scheduling message as a new message, otherwise it
- is treated as an update.
-
- In the case of a new message, the server MUST process the scheduling
- message and create a new scheduling object resource in an appropriate
- calendar collection for the Attendee.
-
- In the case of an update, the server MUST process the scheduling
- message and update the matching scheduling object resource belonging
- to the Attendee to reflect the changes sent by the Organizer.
-
- In each case, the scheduling message MUST only appear in the
- Attendee's scheduling Inbox collection once all automatic processing
- has been done.
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 30]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
-6.2. Processing Attendee Replies
-
- For a scheduling message reply sent by an Attendee, the server first
- locates the corresponding scheduling object resource belonging to the
- Organizer.
-
- The server MUST then update the "PARTSTAT" iCalendar property
- parameter value of each "ATTENDEE" iCalendar property in the
- scheduling object resource to match the changes indicated in the
- reply (taking into account the fact that an Attendee could have
- created a new overridden iCalendar component to indicate different
- participation status on one or more recurrence instances of a
- recurring event).
-
- The server MUST also update or add the "SCHEDULE-STATUS" property
- parameter on each matching "ATTENDEE" iCalendar property and set its
- value to that of the "REQUEST-STATUS" property in the reply, or to
- "2.0" if "REQUEST-STATUS" is not present (also taking into account
- recurrence instances). If there are multiple "REQUEST-STATUS"
- properties in the reply, the "SCHEDULE-STATUS" property parameter
- value is set to a comma-separated list of status codes, one from each
- "REQUEST-STATUS" property.
-
- The server SHOULD send scheduling messages to all the other Attendees
- indicating the change in participation status of the Attendee
- replying, subject to the recurrence requirements of Section 5.2.6.
-
- The scheduling message MUST only appear in the Organizer's scheduling
- Inbox collection once all automatic processing has been done.
-
-6.3. Scheduling Messages as Notifications
-
- Once the processing of an incoming scheduling message is completed by
- the server, the message is made available as a child resource in the
- scheduling Inbox collection of the Calendar User that received the
- message, to serve as a notification that a change has been made to
- the corresponding scheduling object resource. Scheduling messages
- are typically removed from the scheduling Inbox collection by the
- client once the calendar user has acknowledged the change.
-
-6.4. Default Calendar Collection
-
- The server is REQUIRED to process scheduling messages received for an
- Attendee by creating a new scheduling object resource in a calendar
- collection belonging to the Attendee, when one does not already
- exist. A Calendar User that is an Attendee in a scheduling operation
- MUST have at least one valid calendar collection available. If there
- is no valid calendar collection, then the server MUST reject the
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 31]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- attempt to deliver the scheduling message to the Attendee.
-
- Servers MAY provide support for a default calendar collection, that
- is, the calendar collection in which new scheduling object resources
- will be created. The CALDAV:schedule-default-calendar-URL WebDAV
- property, which can be present on the scheduling Inbox collection of
- a Calendar User, specifies if this Calendar User has a default
- calendar collection. See Section 12.2.
-
- Servers SHOULD create new scheduling object resources in the default
- calendar collection, if the CALDAV:schedule-default-calendar-URL
- WebDAV property is set.
-
- Servers MAY allow clients to change the default calendar collection
- by changing the value of the CALDAV:schedule-default-calendar-URL
- WebDAV property on the scheduling Inbox collection. However, the
- servers MUST ensure that any new value for that property refers to a
- valid calendar collection belonging to the owner of the scheduling
- Inbox collection.
-
- Servers MUST reject any attempt to delete the default calendar
- collection.
-
-6.4.1. Additional Method Preconditions
-
- This specification defines additional method preconditions (see
- Section 16 of WebDAV [RFC4918]) to provide machine-parsable
- information in error responses.
-
-6.4.1.1. CALDAV:default-calendar-needed Precondition
-
- Name: default-calendar-needed
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Apply to: DELETE
-
- Use with: 403 Forbidden
-
- Purpose: (precondition) -- The client attempted to delete the
- calendar collection currently referenced by the CALDAV:schedule-
- default-calendar-URL property, or attempted to remove the CALDAV:
- schedule-default-calendar-URL property on the scheduling Inbox
- collection on a server that doesn't allow such operations.
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 32]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- Definition:
-
-
-
- Example:
-
-
-
-6.4.1.2. CALDAV:valid-schedule-default-calendar-URL Precondition
-
- Name: valid-schedule-default-calendar-URL
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Apply to: PROPPATCH
-
- Use with: 403 Forbidden
-
- Purpose: (precondition) -- The client attempted to set the CALDAV:
- schedule-default-calendar-URL property to a DAV:href element that
- doesn't reference a valid calendar collection. Note: Servers that
- do not allow clients to change the CALDAV:schedule-default-
- calendar-URL property would simply return the DAV:cannot-modify-
- protected-property precondition defined in Section 16 of WebDAV
- [RFC4918].
-
- Definition:
-
-
-
- Example:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 33]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
-7. Request for Busy Time Information
-
- The POST method is used to request busy time information of one or
- more Calendar Users by submitting a request at the scheduling Outbox
- collection of the Calendar User requesting the information (the
- Organizer). To accomplish this, the request body of a POST method
- MUST contain a "VFREEBUSY" calendar component with the "METHOD"
- iCalendar property set to the value "REQUEST" as specified in Section
- 3.3.2 of iTIP [RFC5546]. The resource identified by the Request-URI
- MUST be a resource collection of type CALDAV:schedule-outbox
- (Section 4.1). The "ORGANIZER" property in the "VFREEBUSY" component
- MUST match that of the Calendar User who "owns" the Outbox
- collection.
-
-7.1. Status Codes
-
- The following are examples of response codes one would expect to be
- used for this method. However, unless explicitly prohibited, any
- 2/3/4/5xx series response code can be used in a response.
-
- 200 (OK) - The command succeeded.
-
- 204 (No Content) - The command succeeded.
-
- 400 (Bad Request) - The client has provided an invalid scheduling
- message.
-
- 403 (Forbidden) - The client cannot submit a scheduling message to
- the specified Request-URI.
-
- 404 (Not Found) - The URL in the Request-URI was not present.
-
- 423 (Locked) - The specified resource is locked and the client
- either is not a lock owner or the lock type requires a lock token
- to be submitted and the client did not submit it.
-
-7.2. Additional Method Preconditions
-
- This specification defines additional method preconditions for the
- POST method. Preconditions defined in WebDAV ACL [RFC3744] and
- CalDAV [RFC4791] that applies to the POST method are also listed here
- for completeness.
-
-7.2.1. DAV:need-privileges Precondition
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 34]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- Name: need-privileges
-
- Namespace: DAV:
-
- Apply to: POST
-
- Use with: 403 Forbidden
-
- Purpose: (precondition) -- The currently authenticated user MUST be
- granted the CALDAV:schedule-send-freebusy privilege on the
- scheduling Outbox collection being targeted by the request.
-
- Definition:
-
-
-
-
- Example:
-
-
-
- /home/bernard/calendars/outbox/
-
-
-
-
-7.2.2. CALDAV:supported-collection Precondition
-
- Name: supported-collection
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Apply to: POST
-
- Use with: 400 Bad Request
-
- Purpose: (precondition) -- The Request-URI MUST identify the
- location of a scheduling Outbox collection.
-
- Definition:
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 35]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- Example:
-
-
-
-7.2.3. CALDAV:supported-calendar-data Precondition
-
- Name: supported-calendar-data
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Apply to: POST
-
- Use with: 400 Bad Request
-
- Purpose: (precondition) -- The resource body submitted in the POST
- request MUST be a supported media type (e.g., text/calendar).
-
- Definition:
-
-
-
- Example:
-
-
-
-7.2.4. CALDAV:valid-calendar-data Precondition
-
- Name: valid-calendar-data
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Apply to: POST
-
- Use with: 400 Bad Request
-
- Purpose: (precondition) -- The resource submitted in the POST
- request MUST be valid data for the media type being specified
- (e.g., a valid iCalendar object).
-
- Definition:
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 36]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- Example:
-
-
-
-7.2.5. CALDAV:valid-scheduling-message Precondition
-
- Name: valid-scheduling-message
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Apply to: POST
-
- Use with: 400 Bad Request
-
- Purpose: (precondition) -- The resource submitted in the POST
- request MUST obey all restrictions specified for the POST request
- (e.g., the scheduling message follow the restrictions of iTIP).
-
- Definition:
-
-
-
- Example:
-
-
-
-7.2.6. CALDAV:valid-organizer Precondition
-
- Name: valid-organizer
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Apply to: POST
-
- Use with: 403 Forbidden
-
- Purpose: (precondition) -- The Calendar User identified by the
- "ORGANIZER" property in the POST request's scheduling message MUST
- be the Calendar User (or one of the Calendar Users) associated
- with the scheduling Outbox collection being targeted by the
- request;
-
- Definition:
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 37]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- Example:
-
-
-
-7.2.7. CALDAV:max-resource-size Precondition
-
- Name: max-resource-size
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Apply to: POST
-
- Use with: 403 Forbidden
-
- Purpose: (precondition) -- The resource submitted in the POST
- request MUST have a size in octets less than or equal to the value
- of the CALDAV:max-resource-size property (defined in Section 5.2.5
- of [RFC4791]) specified on the scheduling Outbox collection
- targeted by the request.
-
- Definition:
-
-
-
- Example:
-
-
-
-7.3. Response to a POST request
-
- A POST request can return freebusy information for one or more
- Calendar Users. Thus the response needs to contain separate status
- information for each recipient. This specification defines a new XML
- response body to convey multiple recipient status.
-
- A response to a POST method that indicates status for one or more
- recipients MUST be an XML document with a CALDAV:schedule-response
- XML element as its root element. This element MUST contain one
- CALDAV:response element for each recipient, with each of those
- containing elements that indicate which recipient they correspond to,
- the scheduling status for that recipient, any error codes and an
- optional description. See Section 14.1 for the detail on the child
- elements.
-
- In the case of a successful freebusy request, the CALDAV:response
- elements can also contain CALDAV:calendar-data elements which contain
- freebusy information (e.g., an iCalendar VFREEBUSY component)
- indicating the busy state of the corresponding recipient. See
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 38]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- Appendix B.5 for an example freebusy request and response.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 39]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
-8. Avoiding Conflicts when Updating Scheduling Object Resources
-
- Because replies from Attendees and updates from Organizers are
- automatically processed by the server, clients might be in a
- situation where their copy of a calendar resource is different from
- the one currently on the server. When an Attendee or Organizer makes
- a change to the client's copy of the calendar resource, if the client
- writes the data to the server it could overwrite the changes already
- made there. Typically, clients use the ETag value and If-Match
- request headers to avoid the "lost update problem".
-
- Clients can also use ETag and If-Match to avoid this problem.
- However, when doing so the client will likely have to resolve the
- differences between the new resource and the original one, and the
- changes made by the Attendee or Organizer in the client. This can be
- a complicated comparison particularly when recurring components are
- present.
-
- Additionally, the data on the server may change frequently as
- Attendees change their participation status, triggering updates to
- the Organizer, and consequently other Attendees' copies of the
- scheduling object resource. If the ETag/If-Match behavior were used,
- clients would be forced to reconcile their cached copy of a
- scheduling object resource with the updated one on the server in
- order to attempt to write the user's changes back. This could lead
- to a race condition that can effectively result in a temporary denial
- of service when, for example, there is an event with a large Attendee
- list. A "storm" of updates will occur if Attendees all start
- responding at the same time, and this would prevent Attendees and the
- Organizer from being able to update their own copies of the
- scheduling object resource as the server copy is changing frequently.
-
- A solution is to have the server determine the best way to merge
- changes made on the server with changes being made by the client.
- For example, if an Attendee changes their participation status and
- triggers an update to the Organizer's copy of the event, but the
- Organizer also updates their cached copy of the event and attempts to
- write it back, rather than failing on a conditional If-Match when the
- Organizer writes their data, the server would instead take the
- changes made by the Organizer and apply the Attendee changes and
- store the result. Thus a form of "weak" ETag matching behavior is
- needed such that scheduling changes made automatically on the server
- do not invalidate the tag, so that when clients store data
- conditionally based on the tag value, the server knows it can apply
- the merge behavior.
-
- In order to do that, this specification introduces a new WebDAV
- resource property CALDAV:schedule-tag with a corresponding response
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 40]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- header "Schedule-Tag", and a new "If-Schedule-Tag-Match" request
- header to allow client changes to be appropriately merged with server
- changes in the case where the changes on the server were the result
- of an "inconsequential" scheduling message update. An
- "inconsequential" scheduling message is one which simply updates the
- status information of Attendees due to a reply from an Attendee.
-
- Servers MUST support requests targeted at scheduling object resources
- using the "If-Schedule-Tag-Match" request header. Consequently, the
- server MUST support the "Schedule-Tag" response header and CALDAV:
- schedule-tag property for scheduling object resources. Servers MUST
- automatically resolve conflicts with "inconsequential" changes done
- to scheduling object resources when the "If-Schedule-Tag-Match"
- request header is specified.
-
- The If-Schedule-Tag-Match request header applies only to the Request-
- URI, and not to the Destination of a COPY or MOVE in the same way as
- the If-Match request header.
-
- Clients SHOULD use the If-Schedule-Tag-Match header on requests that
- update scheduling object resources.
-
- A response to any successful GET or PUT request targeting a
- scheduling object resource MUST include a Schedule-Tag response
- header with the value set to the same value as the CALDAV:schedule-
- tag WebDAV property of the resource.
-
- A response to any successful COPY or MOVE request that specifies a
- Destination request header targeting a scheduling object resource
- MUST include a Schedule-Tag response header with the value set to the
- same value as the CALDAV:schedule-tag WebDAV property of the resource
- identified in the Request-URI.
-
- The Schedule-Tag feature is designed to be used to address the
- problem of "inconsequential" changes on the server only. Normal ETag
- operations are used in all other cases, e.g., for synchronization.
-
- The value of the CALDAV:schedule-tag property changes according to
- these rules:
-
- o For an Organizer's copy of a scheduling object resource:
-
- 1. The server MUST NOT change the CALDAV:schedule-tag property
- value when the scheduling object resource is updated as the
- result of automatically processing a scheduling message reply
- from an Attendee. For instance, when an Attendee replies to
- the Organizer, the CALDAV:schedule-tag property is unchanged
- after the Organizer's scheduling object resource has been
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 41]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- automatically updated by the server with the Attendee's new
- participation status.
-
- 2. The server MUST change CALDAV:schedule-tag property value when
- the scheduling object resource is changed directly via an HTTP
- request (e.g., PUT, COPY or MOVE).
-
- o For an Attendee's copy of a scheduling object resource:
-
- 1. The server MUST change the CALDAV:schedule-tag property value
- when the scheduling object resource is changed as the result
- of processing a scheduling message update from an Organizer
- that contains changes other than just the participation status
- of Attendees.
-
- 2. The server MUST NOT change the CALDAV:schedule-tag property
- value when the scheduling object resource is changed as the
- result of processing a scheduling message update from an
- Organizer that only specify changes in the participation
- status of Attendees. For instance, when Attendee "A" replies
- to Organizer "O", and Attendee "B" receives a scheduling
- message update from Organizer "O" with the new participation
- status of Attendee "A", the CALDAV:schedule-tag property of
- Attendee "B"s scheduling object resource MUST NOT be changed.
-
- 3. The server MUST change the CALDAV:schedule-tag property value
- when the scheduling object resource is changed directly via an
- HTTP request (e.g., PUT, COPY or MOVE).
-
-8.1. PUT
-
- Clients can use the If-Schedule-Tag-Match request header to do a PUT
- request that ensures that "inconsequential" changes on the server do
- not result in a precondition error. The value of the request header
- is set to the last Schedule-Tag value received for the resource being
- modified. If the value of the If-Schedule-Tag-Match header matches
- the current value of the CALDAV:schedule-tag property the server MUST
- take any "ATTENDEE" property changes for all Attendees other than the
- owner of the scheduling object resource and apply those to the new
- resource being stored. Otherwise, the server MUST fail the request
- with a 412 Precondition Failed status code.
-
-8.2. DELETE, COPY or MOVE
-
- Clients can use the If-Schedule-Tag-Match request header to do a
- DELETE, COPY or MOVE request that ensures that "inconsequential"
- changes on the server do not result in a precondition error. The
- value of the request header is set to the last Schedule-Tag value
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 42]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- received for the resource being deleted. If the value of the If-
- Schedule-Tag-Match header matches the current value of the CALDAV:
- schedule-tag property the server performs the normal DELETE, COPY or
- MOVE request processing for the resource. Otherwise, the server MUST
- fail the request with a 412 Precondition Failed status code.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 43]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
-9. Other Scheduling Considerations
-
-9.1. Attendee Participation Status
-
- This section specifies additional requirements on the handling of the
- "PARTSTAT" property parameter when the "SCHEDULE-AGENT" property
- parameter on the corresponding "ATTENDEE" property is set to the
- value "SERVER" or is not present.
-
- Clients SHOULD, and servers MUST reset the "PARTSTAT" property
- parameter value of all "ATTENDEE" properties, except the one that
- corresponds to the Organizer, to "NEEDS-ACTION" when the Organizer
- reschedules an event.
-
- A reschedule of an event occurs when any "DTSTART", "DTEND",
- "DURATION", "DUE", "RRULE", "RDATE", or "EXDATE" property changes in
- a calendar component such that existing recurrence instances are
- impacted by the changes, as shown in the table below.
-
- +-----------+-------------------------------------------------------+
- | Property | Server Action |
- +-----------+-------------------------------------------------------+
- | DTSTART, | Any change to these properties MUST result in |
- | DTEND, | "PARTSTAT" being set to "NEEDS-ACTION" |
- | DURATION, | |
- | DUE | |
- | | |
- | | |
- | | |
- | RRULE | A change to or addition of this property that results |
- | | in the addition of new recurring instances or a |
- | | change in time for existing recurring instances MUST |
- | | result in "PARTSTAT" being reset to "NEEDS-ACTION" on |
- | | each affected component. |
- | | |
- | | |
- | | |
- | RDATE | A change to or addition of this property that results |
- | | in the addition of new recurring instances or a |
- | | change in time for existing recurring instances MUST |
- | | result in "PARTSTAT" being reset to "NEEDS-ACTION" on |
- | | each affected component. |
- | | |
- | | |
- | | |
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 44]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- | EXDATE | A change to or removal of this property that results |
- | | in the re-instatement of recurring instances MUST |
- | | result in "PARTSTAT" being set to "NEEDS-ACTION" on |
- | | each affected component. |
- +-----------+-------------------------------------------------------+
-
- The server MAY allow the Organizer's client to change an Attendee's
- "PARTSTAT" property parameter value to "NEEDS-ACTION" at any other
- time (e.g., when the "LOCATION" property value changes, an Organizer
- might wish to re-invite Attendees who may be impacted by the change).
-
-9.2. Schedule Status Values
-
- When scheduling with an Attendee there are two types of status
- information that can be returned during the transaction. The first
- type of status information is a "delivery" status that indicates
- whether the scheduling message from the Organizer to the Attendee was
- delivered or not, or what the current status of delivery is. The
- second type of status information is a "reply" status corresponding
- to the Attendee's own "REQUEST-STATUS" information from the
- scheduling message reply that is sent back to the Organizer.
-
- Similarly, when an Attendee sends a reply back to the Organizer,
- there will be "delivery" status information for the scheduling
- message sent to the Organizer. However, there is no "REQUEST-STATUS"
- sent back by the Organizer, so there is no equivalent of the "reply"
- status as per scheduling messages to Attendees.
-
- The "delivery" status information on an "ORGANIZER" or "ATTENDEE"
- iCalendar property is conveyed in the "SCHEDULE-STATUS" property
- parameter value (Section 10.3). The status code value for "delivery"
- status can be one of the following:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 45]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- +----------+--------------------------------------------------------+
- | Delivery | Description |
- | Status | |
- | Code | |
- +----------+--------------------------------------------------------+
- | 1.0 | The scheduling message is pending. i.e. the server is |
- | | still in the process of sending the message. The |
- | | status code value can be expected to change once the |
- | | server has completed its sending and delivery |
- | | attempts. |
- | | |
- | | |
- | | |
- | 1.1 | The scheduling message has been successfully sent. |
- | | However, the server does not have explicit information |
- | | about whether the scheduling message was successfully |
- | | delivered to the recipient. This state can occur with |
- | | "store and forward" style scheduling protocols such as |
- | | iMIP [RFC6047] (iTIP using email). |
- | | |
- | | |
- | | |
- | 1.2 | The scheduling message has been successfully |
- | | delivered. |
- | | |
- | | |
- | | |
- | 3.7 | The scheduling message was not delivered because the |
- | | server did not recognize the calendar user address as |
- | | a valid calendar user. Note that this code applies to |
- | | both Organizer and Attendee calendar user addresses. |
- | | |
- | | |
- | | |
- | 3.8 | The scheduling message was not delivered due to |
- | | insufficient privileges. Note that this code applies |
- | | to both privileges granted by both the Organizer and |
- | | Attendee calendar users. |
- | | |
- | | |
- | | |
- | 5.1 | The scheduling message was not delivered because the |
- | | server could not complete delivery of the message. |
- | | This is likely due to a temporary failure, and the |
- | | originator can try to send the message again at a |
- | | later time. |
- | | |
- | | |
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 46]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- | 5.2 | The scheduling message was not delivered because the |
- | | server was not able to find a suitable way to deliver |
- | | the message. This is likely a permanent failure, and |
- | | the originator should not try to send the message |
- | | again, at least without verifying/correcting the |
- | | calendar user address of the recipient. |
- | | |
- | | |
- | | |
- | 5.3 | The scheduling message was not delivered and was |
- | | rejected because scheduling with that recipient is not |
- | | allowed. This is likely a permanent failure, and the |
- | | originator should not try to send the message again. |
- +----------+--------------------------------------------------------+
-
- The status code for "reply" status can be any of the valid iTIP
- [RFC5546] "REQUEST-STATUS" values.
-
- The 1.xx "REQUEST-STATUS" codes are new. This specification modifies
- item (2) of Section 3.6 of [RFC5546] by adding the following
- restriction:
-
- For a 1.xx code, all components MUST have exactly the same code.
-
- Definition of the new 1.xx codes is as follows:
-
-9.2.1. Status Code 1.0
-
- Status Code: 1.0
-
- Status Description: Pending.
-
- Status Exception Data: None.
-
- Description: Delivery of the iTIP message is pending.
-
-9.2.2. Status Code 1.1
-
- Status Code: 1.1
-
- Status Description: Sent.
-
- Status Exception Data: None.
-
- Description: The iTIP message has been sent, though no information
- about successful delivery is known.
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 47]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
-9.2.3. Status Code 1.2
-
- Status Code: 1.2
-
- Status Description: Delivered.
-
- Status Exception Data: None.
-
- Description: The iTIP message has been sent and delivered.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 48]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
-10. Additional iCalendar Property Parameters
-
- This specification defines additional iCalendar property parameters
- to support the CalDAV scheduling extensions.
-
-10.1. Schedule Agent Parameter
-
- Parameter Name: SCHEDULE-AGENT
-
- Purpose: To specify the agent expected to deliver scheduling
- messages to the corresponding Organizer or Attendee.
-
- Format Definition: This property parameter is defined by the
- following notation:
-
- scheduleagentparam = "SCHEDULE-AGENT" "="
- ("SERVER" ; The server handles scheduling
- / "CLIENT" ; The client handles scheduling
- / "NONE" ; No scheduling
- / x-name ; Experimental type
- / iana-token) ; Other IANA registered type
- ;
- ; Default is SERVER
-
- Description: This property parameter MAY be specified on "ORGANIZER"
- or "ATTENDEE" iCalendar properties. In the absence of this
- parameter, the value "SERVER" MUST be used for the default
- behavior. The value determines whether or not an automatic
- scheduling transaction on a server will cause a scheduling message
- to be sent to the corresponding Calendar User identified by the
- "ORGANIZER" or "ATTENDEE" property value. When the value "SERVER"
- is specified, or the parameter is absent, then it is the server's
- responsibility to send a scheduling message as part of an
- automatic scheduling transaction. When the value "CLIENT" is
- specified, that indicates that the client is handling scheduling
- messages with the Calendar User itself. When "NONE" is specified,
- no scheduling messages are being sent to the Calendar User.
-
- Servers MUST NOT include this parameter in any scheduling messages
- sent as the result of an automatic scheduling transaction.
-
- Clients MUST NOT include this parameter in any scheduling messages
- that they themselves send.
-
- The parameter value MUST be the same on every "ORGANIZER" property
- in a scheduling object resource.
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 49]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- The parameter value MUST be the same on each "ATTENDEE" property
- whose values match in a scheduling object resource.
-
- Servers and clients MUST treat x-name and iana-token values they
- do not recognize the same way as they would the "NONE" value.
-
- Example:
-
- ORGANIZER;SCHEDULE-AGENT=SERVER:mailto:bernard@example.com
-
- ATTENDEE;SCHEDULE-AGENT=NONE:mailto:cyrus@example.com
-
-10.2. Schedule Force Send Parameter
-
- Parameter Name: SCHEDULE-FORCE-SEND
-
- Purpose: To force a scheduling message to be sent to the Calendar
- User specified by the property.
-
- Format Definition: This property parameter is defined by the
- following notation:
-
- scheduleforcesendparam = "SCHEDULE-FORCE-SEND" "="
- ("REQUEST" ; Force a "REQUEST"
- / "REPLY" ; Force a "REPLY"
- / iana-token) ; IANA registered method
-
- Description: This property parameter MAY be specified on "ATTENDEE"
- and "ORGANIZER" properties on which the "SCHEDULE-AGENT" property
- parameter is set to the value "SERVER" or is not specified. This
- property parameter is used to force a server to send a scheduling
- message to a specific Calendar User in situations where the server
- would not send a scheduling message otherwise (e.g., when no
- change that warrants the delivery of a new scheduling message was
- performed on the scheduling object resource). An Organizer MAY
- specify this parameter on an "ATTENDEE" property with the value
- "REQUEST" to force a "REQUEST" scheduling message to be sent to
- this Attendee. An Attendee MAY specify this parameter on the
- "ORGANIZER" with the value "REPLY" to force a "REPLY" scheduling
- message to be sent to the Organizer.
-
- Servers MUST NOT preserve this property parameter in scheduling
- object resources, nor include it in any scheduling messages sent
- as the result of an automatic scheduling transaction.
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 50]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- Clients MUST NOT include this parameter in any scheduling messages
- that they themselves send.
-
- Servers MUST set the "SCHEDULE-STATUS" parameter of the "ATTENDEE"
- or "ORGANIZER" to 2.3 (i.e., "Success, invalid property parameter
- ignored", see Section 3.6 of [RFC5546]) when the "SCHEDULE-FORCE-
- SEND" parameter is set to a x-name or iana-token value they do not
- recognize.
-
- Example:
-
- ATTENDEE;SCHEDULE-FORCE-SEND=REQUEST:mailto:bernard@example.com
-
- ORGANIZER;SCHEDULE-FORCE-SEND=REPLY:mailto:cyrus@example.com
-
-10.3. Schedule Status Parameter
-
- Parameter Name: SCHEDULE-STATUS
-
- Purpose: To specify the status codes returned from processing of the
- most recent scheduling message sent to the corresponding Attendee,
- or received from the corresponding Organizer.
-
- Format Definition: This property parameter is defined by the
- following notation:
-
- schedulestatusparam = "SCHEDULE-STATUS" "="
- ( statcode
- / DQUOTE statcode *("," statcode) DQUOTE)
- ; "statcode" is defined in Section 3.8.8.3 of
- ; [RFC5545]. Value is a single
- ; "statcode" or a comma-separated list of "statcode" values.
-
- Description: This property parameter MAY be specified on the
- "ATTENDEE" and "ORGANIZER" properties.
-
- Servers MUST add this property parameter to any "ATTENDEE"
- properties corresponding to Calendar Users who were sent a
- scheduling message via an automatic scheduling transaction.
- Clients SHOULD NOT change or remove this parameter if it was
- provided by the server. In the case where the client is handling
- the scheduling, the client MAY add, change or remove this
- parameter to indicate the last scheduling message status it
- received.
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 51]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- Servers MUST add this parameter to any "ORGANIZER" properties
- corresponding to Calendar Users who were sent a scheduling message
- reply by an Attendee via an automatic scheduling transaction.
- Clients SHOULD NOT change or remove this parameter if it was
- provided by the server. In the case where the client is handling
- the scheduling, the client MAY add, change or remove this
- parameter to indicate the last scheduling message status it
- received.
-
- Servers MUST NOT include this parameter in any scheduling messages
- sent as the result of an automatic scheduling transaction.
-
- Clients MUST NOT include this parameter in any scheduling messages
- that they themselves send.
-
- Suitable values for this property parameter are described in
- Section 9.2.
-
- Example:
-
- ATTENDEE;SCHEDULE-STATUS="2.0":mailto:bernard@example.com
-
- ATTENDEE;SCHEDULE-STATUS="2.0,2.4":mailto:cyrus@example.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 52]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
-11. Additional Message Header Fields
-
- This specification defines additional HTTP request and response
- headers for use with CalDAV.
-
-11.1. Schedule-Reply Request Header
-
-
- Schedule-Reply = "Schedule-Reply" ":" ("T" | "F")
-
- Example:
-
- Schedule-Reply: F
-
- When an Attendee removes a scheduling object resource, and the
- Schedule-Reply header is not present, or present and set to the value
- "T", the server MUST send an appropriate reply scheduling message
- with the Attendee's "PARTSTAT" iCalendar property parameter value set
- to "DECLINED" as part of its normal automatic scheduling transaction
- processing.
-
- When the Schedule-Reply header is set to the value "F", the server
- MUST NOT send a scheduling message as part of its normal automatic
- scheduling transaction processing.
-
- The Schedule-Reply request header is used by a client to indicate to
- a server whether or not an automatic scheduling transaction should
- occur when an Attendee deletes a scheduling object resource. In
- particular it controls whether a reply scheduling message is sent to
- the Organizer as a result of the removal. There are situations in
- which unsolicited scheduling messages need to be silently removed (or
- ignored) for security or privacy reasons. This request header allows
- the scheduling object resource to be removed if such a need arises.
-
- All scheduling object resources MUST support the Schedule-Reply
- request header.
-
-11.2. Schedule-Tag Response Header
-
- The Schedule-Tag response header provides the current value of the
- CALDAV:schedule-tag property value. The behavior of this response
- header is described in Section 8.
-
- All scheduling object resources MUST support the Schedule-Tag header.
-
- Schedule-Tag = "Schedule-Tag" ":" opaque-tag
- ; "opaque-tag" is defined in Section 3.11 of [RFC2616]
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 53]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- Example:
-
- Schedule-Tag: "12ab34-cd56ef"
-
-11.3. If-Schedule-Tag-Match Request Header
-
- The If-Schedule-Tag-Match request header field is used with a method
- to make it conditional. Clients can set this header to the value
- returned in the Schedule-Tag response header, or the CALDAV:schedule-
- tag property, of a scheduling object resource previously retrieved
- from the server to avoid overwriting "consequential" changes to the
- scheduling object resource.
-
- All scheduling object resources MUST support the If-Schedule-Tag-
- Match header.
-
- If-Schedule-Tag-Match = "If-Schedule-Tag-Match" ":" opaque-tag
- ; "opaque-tag" is defined in Section 3.11 of [RFC2616]
-
- Example:
-
- If-Schedule-Tag-Match: "12ab34-cd56ef"
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 54]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
-12. Additional WebDAV Properties
-
- This specification defines the following new WebDAV properties for
- use with CalDAV.
-
-12.1. CALDAV:schedule-calendar-transp Property
-
- Name: schedule-calendar-transp
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Purpose: Determines whether the calendar object resources in a
- calendar collection will affect the owner's freebusy.
-
- Protected: This property MAY be protected and SHOULD NOT be returned
- by a PROPFIND allprop request (as defined in Section 14.2 of
- [RFC4918]).
-
- COPY/MOVE behavior: This property value SHOULD be kept during a MOVE
- operation, and SHOULD be copied and preserved in a COPY.
-
- Description: This property SHOULD be defined on all calendar
- collections. If present, it contains one of two XML elements that
- indicate whether the calendar object resources in the calendar
- collection should contribute to the owner's freebusy or not. When
- the CALDAV:opaque element is used, all calendar object resources
- in the corresponding calendar collection MUST contribute to
- freebusy, assuming access privileges and other iCalendar
- properties allow it to. When the CALDAV:transparent XML element
- is used, the calendar object resources in the corresponding
- calendar collection MUST NOT contribute to freebusy.
-
- If this property is not present on a calendar collection, then the
- default value CALDAV:opaque MUST be assumed.
-
- Definition:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 55]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- Example:
-
-
-
-
-
-12.2. CALDAV:schedule-default-calendar-URL Property
-
- Name: schedule-default-calendar-URL
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Purpose: Specifies a default calendar for an Attendee where new
- scheduling object resources are created.
-
- Protected: This property MAY be protected in the case where a server
- does not support changing the default calendar, or does not
- support a default calendar.
-
- COPY/MOVE behavior: This property is only defined on a scheduling
- Inbox collection which cannot be moved or copied.
-
- Description: This property MAY be defined on a scheduling Inbox
- collection. If present, it contains zero or one DAV:href XML
- elements. When a DAV:href element is present, its value indicates
- a URL to a calendar collection that is used as the default
- calendar. When no DAV:href element is present, it indicates that
- there is no default calendar. In the absence of this property
- there is no default calendar. When there is no default calendar
- the server is free to choose the calendar in which a new
- scheduling object resource is created. See Section 6.4.
-
- Definition:
-
-
-
- Example:
-
-
- /home/cyrus/calendars/work/
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 56]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
-12.3. CALDAV:schedule-tag Property
-
- Name: schedule-tag
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Purpose: Indicates whether a scheduling object resource has had a
- "consequential" change made to it.
-
- Value: opaque-tag (defined in Section 3.11 of [RFC2616])
-
- Protected: This property MUST be protected as only the server can
- update the value.
-
- COPY/MOVE behavior: This property is only defined on scheduling
- object resources. It MUST be preserved when a scheduling object
- resource is copied or moved and the resulting resource is also a
- scheduling object resource. If the source resource is not a
- scheduling object resource but the destination resource is, this
- property MUST be added to the destination resource.
-
- Description: The CALDAV:schedule-tag property MUST be defined on all
- scheduling object resources. This property is described in
- Section 8.
-
- Definition:
-
-
-
- Example:
-
- "12345-67890"
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 57]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
-13. Scheduling Access Control
-
-13.1. Scheduling Privileges
-
- CalDAV servers MUST support and adhere to the requirements of WebDAV
- ACL [RFC3744]. Furthermore, CalDAV servers that advertise support
- for the "calendar-auto-schedule" feature MUST also support the
- scheduling privileges defined in this section.
-
- All the scheduling privileges MUST be non-abstract and MUST appear in
- the DAV:supported-privilege-set property of scheduling Outbox and
- Inbox collections on which they are defined.
-
- The tables specified in Appendix A clarify which scheduling methods
- (e.g., "REQUEST", "REPLY", etc.) are controlled by each scheduling
- privilege defined in this section.
-
-13.1.1. Privileges on Scheduling Inbox Collections
-
- This section defines new WebDAV ACL privileges that are for use on
- scheduling Inbox collections. These privileges determine whether
- delivery of scheduling messages from a calendar user is allowed by
- the calendar user who "owns" the scheduling Inbox collection. This
- allows calendar users to choose which other calendar users can
- schedule with them.
-
- Note that when a scheduling message is delivered to a calendar user,
- in addition to a scheduling object resource being created in the
- calendar user's scheduling Inbox collection, a new scheduling object
- resource might be created or an existing one updated in a calendar
- belonging to the calendar user. In that case, the ability to create
- or update the scheduling object resource in the calendar is
- controlled by the privileges assigned to the scheduling Inbox
- collection.
-
- The privileges defined in this section are ignored if applied to a
- resource other than a scheduling Inbox collection.
-
-13.1.1.1. CALDAV:schedule-deliver Privilege
-
- CALDAV:schedule-deliver is an aggregate privilege that contains all
- the scheduling privileges that control the processing and delivery of
- incoming scheduling messages, that is, CALDAV:schedule-deliver-invite
- and CALDAV:schedule-deliver-reply, as well as freebusy requests
- targeted at the owner of the scheduling Inbox collection, that is,
- CALDAV:schedule-query-freebusy.
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 58]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
-13.1.1.2. CALDAV:schedule-deliver-invite Privilege
-
- The CALDAV:schedule-deliver-invite privilege controls the processing
- and delivery of scheduling messages coming from an Organizer.
-
-
-
-13.1.1.3. CALDAV:schedule-deliver-reply Privilege
-
- The CALDAV:schedule-deliver-reply privilege controls the processing
- and delivery of scheduling messages coming from an Attendee.
-
-
-
-13.1.1.4. CALDAV:schedule-query-freebusy Privilege
-
- The CALDAV:schedule-query-freebusy privilege controls freebusy
- requests targeted at the owner of the scheduling Inbox collection.
-
-
-
-13.1.2. Privileges on Scheduling Outbox Collections
-
- This section defines new WebDAV ACL privileges that are defined for
- use on scheduling Outbox collections. These privileges determine
- which calendar users are allowed to send scheduling messages on
- behalf of the calendar user who "owns" the scheduling Outbox
- collection. This allows calendar users to choose other calendar
- users who can act on their behalf to send schedule messages to other
- calendar users (e.g. assistants working on behalf of their boss).
-
- The privileges defined in this section are ignored if applied to a
- resource other than a scheduling Outbox collection.
-
-13.1.2.1. CALDAV:schedule-send Privilege
-
- CALDAV:schedule-send is an aggregate privilege that contains all the
- scheduling privileges that control the use of methods that will cause
- scheduling messages to be delivered to other users, that is, CALDAV:
- schedule-send-invite and CALDAV:schedule-send-reply, as well as
- freebusy requests to be targeted at other users, that is, CALDAV:
- schedule-send-freebusy.
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 59]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
-13.1.2.2. CALDAV:schedule-send-invite Privilege
-
- The CALDAV:schedule-send-invite privilege controls the sending of
- scheduling messages by Organizers.
-
- Users granted the DAV:bind privilege on a calendar collection, or
- DAV:write privilege on scheduling object resources, will also need
- the CALDAV:schedule-send-invite privilege granted on the scheduling
- Outbox collection of the owner of the calendar collection or
- scheduling object resource in order to be allowed to create, modify
- or delete scheduling object resources in a way that will trigger the
- CalDAV server to deliver organizer scheduling messages to other
- calendar users.
-
-
-
-13.1.2.3. CALDAV:schedule-send-reply Privilege
-
- The CALDAV:schedule-send-reply privilege controls the sending of
- scheduling messages by Attendees.
-
- Users granted the DAV:bind privilege on a calendar collection, or
- DAV:write privilege on scheduling object resources, will also need
- the CALDAV:schedule-send-reply privilege granted on the scheduling
- Outbox collection of the owner of the calendar collection or
- scheduling object resource in order to be allowed to create, modify
- or delete scheduling object resources in a way that will trigger the
- CalDAV server to deliver attendee scheduling messages to other
- calendar users.
-
-
-
-13.1.2.4. CALDAV:schedule-send-freebusy Privilege
-
- The CALDAV:schedule-send-freebusy privilege controls the use of the
- POST method to submit scheduling messages that specify the scheduling
- method "REQUEST" with a "VFREEBUSY" calendar component.
-
-
-
-13.1.3. Aggregation of Scheduling Privileges
-
- Server implementations MUST aggregate the scheduling privileges as
- follows:
-
- DAV:all MUST contain CALDAV:schedule-send and CALDAV:schedule-
- deliver;
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 60]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- CALDAV:schedule-send MUST contain CALDAV:schedule-send-invite,
- CALDAV:schedule-send-reply, and CALDAV:schedule-send-freebusy;
-
- CALDAV:schedule-deliver MUST contain CALDAV:schedule-deliver-
- invite, CALDAV:schedule-deliver-reply, and CALDAV:schedule-query-
- freebusy.
-
- The following diagram illustrates how scheduling privileges are
- aggregated according to the above requirements.
-
- [DAV:all] (aggregate)
- |
- +-- [CALDAV:schedule-deliver] (aggregate)
- | |
- | +-- [CALDAV:schedule-deliver-invite]
- | +-- [CALDAV:schedule-deliver-reply]
- | +-- [CALDAV:schedule-query-freebusy]
- |
- +-- [CALDAV:schedule-send] (aggregate)
- |
- +-- [CALDAV:schedule-send-invite]
- +-- [CALDAV:schedule-send-reply]
- +-- [CALDAV:schedule-send-freebusy]
-
-13.2. Additional Principal Properties
-
- This section defines new properties for WebDAV principal resources as
- defined in [RFC3744]. These properties are likely to be protected
- but the server MAY allow them to be written by appropriate users.
-
-13.2.1. CALDAV:schedule-inbox-URL Property
-
- Name: schedule-inbox-URL
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Purpose: Identify the URL of the scheduling Inbox collection owned
- by the associated principal resource.
-
- Protected: This property MAY be protected.
-
- PROPFIND behavior: This property SHOULD NOT be returned by a
- PROPFIND allprop request (as defined in Section 14.2 of
- [RFC4918]).
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 61]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- COPY/MOVE behavior: This property value SHOULD be preserved in COPY
- and MOVE operations.
-
- Description: This property is needed for a client to determine where
- the scheduling Inbox collection of the current user is located so
- that processing of scheduling messages can occur. If not present,
- then the associated calendar user is not enabled for reception of
- scheduling messages on the server.
-
- Definition:
-
-
-
-13.2.2. CALDAV:schedule-outbox-URL Property
-
- Name: schedule-outbox-URL
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Purpose: Identify the URL of the scheduling Outbox collection owned
- by the associated principal resource.
-
- Protected: This property MAY be protected.
-
- PROPFIND behavior: This property SHOULD NOT be returned by a
- PROPFIND allprop request (as defined in Section 14.2 of
- [RFC4918]).
-
- COPY/MOVE behavior: This property value SHOULD be preserved in COPY
- and MOVE operations.
-
- Description: This property is needed for a client to determine where
- the scheduling Outbox collection of the current user is located so
- that sending of scheduling messages can occur. If not present,
- then the associated calendar user is not enabled for the sending
- of scheduling messages on the server.
-
- Definition:
-
-
-
-13.2.3. CALDAV:calendar-user-address-set Property
-
- Name: calendar-user-address-set
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 62]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Purpose: Identify the calendar addresses of the associated principal
- resource.
-
- Protected: This property MAY be protected.
-
- PROPFIND behavior: This property SHOULD NOT be returned by a
- PROPFIND allprop request (as defined in Section 14.2 of
- [RFC4918]).
-
- COPY/MOVE behavior: This property value SHOULD be preserved in COPY
- and MOVE operations.
-
- Description: Support for this property is REQUIRED. This property
- is needed to map calendar user addresses in iCalendar data to
- principal resources and their associated scheduling Inbox and
- Outbox collections. In the event that a user has no well defined
- identifier for their calendar user address, the URI of their
- principal resource can be used. This property SHOULD be
- searchable using the DAV:principal-property-search REPORT. The
- DAV:principal-search-property-set REPORT SHOULD identify this
- property as such. If not present, then the associated calendar
- user is not enabled for scheduling on the server.
-
- Definition:
-
-
-
- Example:
-
-
- mailto:bernard@example.com
- mailto:bernard.desruisseaux@example.com
-
-
-13.2.4. CALDAV:calendar-user-type Property
-
- Name: calendar-user-type
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Purpose: Identifies the calendar user type of the associated
- principal resource.
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 63]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- Value: Same values allowed for the iCalendar "CUTYPE" property
- parameter defined in Section 3.2.3 of [RFC5545].
-
- Protected: This property MAY be protected.
-
- PROPFIND behavior: This property SHOULD NOT be returned by a
- PROPFIND allprop request (as defined in Section 14.2 of
- [RFC4918]).
-
- COPY/MOVE behavior: This property value SHOULD be preserved in COPY
- and MOVE operations.
-
- Description: Clients can query principal resources in order to
- lookup attendees available on the server. When doing this, it is
- useful to know, or restrict the query to, certain types of
- calendar user (e.g., only search for "people", or only search for
- "rooms"). This property MAY be defined on principal resources to
- indicate the type of calendar user associated with the principal
- resource. Its value is the same as the iCalendar "CUTYPE"
- property parameter that can be used on "ATTENDEE" properties.
- This property SHOULD be searchable using the DAV:principal-
- property-search REPORT. The DAV:principal-search-property-set
- REPORT SHOULD identify this property as such.
-
- Definition:
-
-
-
- Example:
-
- INDIVIDUAL<
- /C:calendar-user-type>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 64]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
-14. XML Element Definitions
-
-14.1. CALDAV:schedule-response XML Element
-
- Name: schedule-response
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Purpose: Contains the set of responses for a POST method request.
-
- Description: See Section 7.3.
-
- Definition:
-
-
-
-14.2. CALDAV:response XML Element
-
- Name: response
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Purpose: Contains a single response for a POST method request.
-
- Description: See Section 7.3.
-
- Definition:
-
-
-
-
-
-14.3. CALDAV:recipient XML Element
-
- Name: recipient
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Purpose: The calendar user address that the enclosing response for a
- POST method request is for.
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 65]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- Description: See Section 7.3.
-
- Definition:
-
-
-
-14.4. CALDAV:request-status XML Element
-
- Name: request-status
-
- Namespace: urn:ietf:params:xml:ns:caldav
-
- Purpose: The iTIP "REQUEST-STATUS" property value for this response.
-
- Description: See Section 7.3.
-
- Definition:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 66]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
-15. Security Considerations
-
- The process of scheduling involves the sending and receiving of
- scheduling messages. As a result, the security problems related to
- messaging in general are relevant here. In particular the
- authenticity of the scheduling messages needs to be verified.
- Servers and clients MUST use an HTTP connection protected with TLS as
- defined in [RFC2818] for all scheduling transactions.
-
-15.1. Verifying Scheduling Transactions
-
- When handling a scheduling transaction:
-
- Servers MUST verify that the principal associated with the DAV:
- owner of the calendar collection in which a scheduling object
- resource is being manipulated contains a CALDAV:schedule-outbox-
- URL property value.
-
- Servers MUST verify that the currently authenticated user has the
- CALDAV:schedule-send privilege, or a suitable sub-privilege
- aggregated under this privilege, on the scheduling Outbox
- collection of the DAV:owner of the calendar collection in which a
- scheduling object resource is being manipulated.
-
- Servers MUST only deliver scheduling messages to recipients when
- the CALDAV:schedule-deliver privilege, or a suitable sub-privilege
- aggregated under this privilege, is granted on the recipient's
- scheduling Inbox collection for the principal associated with the
- DAV:owner of the calendar collection in which a scheduling object
- resource is being manipulated.
-
- To prevent impersonation of calendar users, the server MUST verify
- that the "ORGANIZER" property in an organizer scheduling object
- resource matches one of the calendar user addresses of the DAV:
- owner of the calendar collection in which the resource is stored.
-
- To prevent spoofing of an existing scheduling object resource,
- servers MUST verify that the "UID" iCalendar property value in a
- new scheduling object resource does not match that of an existing
- scheduling object resource with a different "ORGANIZER" property
- value.
-
-15.2. Verifying Busy Time Information Requests
-
- When handling a POST request on a scheduling Outbox collection:
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 67]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- Servers MUST verify that the principal associated with the
- calendar user address specified in the "ORGANIZER" property of the
- scheduling message data in the request contains a CALDAV:schedule-
- outbox-URL property value that matches the scheduling Outbox
- collection targeted by the request.
-
- Servers MUST verify that the currently authenticated user has the
- CALDAV:schedule-send privilege, or a sub-privilege aggregated
- under this privilege, on the scheduling Outbox collection targeted
- by the request.
-
- Servers MUST only return valid freebusy information for recipients
- when the CALDAV:schedule-deliver privilege, or a sub-privilege
- aggregated under this privilege, is granted on the recipient's
- scheduling Inbox collection for the principal associated with the
- DAV:owner of the scheduling Outbox collection targeted by the
- request.
-
-15.3. Privacy Issues
-
- As noted in Section 11.1, Attendees can use the Schedule-Reply
- request header with the value set to "F" to prevent notification to
- an Organizer that a scheduling object resource was deleted. This
- allows Attendees to remove unwanted scheduling messages without any
- response to the Organizer.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 68]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
-16. IANA Considerations
-
-16.1. Message Header Field Registrations
-
- The message header fields below should be added to the Permanent
- Message Header Field Registry (see [RFC3864]).
-
-16.1.1. Schedule-Reply
-
- Header field name: Schedule-Reply
-
- Applicable protocol: http
-
- Status: standard
-
- Author/Change controller: IETF
-
- Specification document(s): this specification (Section 11.1)
-
- Related information: none
-
-16.1.2. Schedule-Tag
-
- Header field name: Schedule-Tag
-
- Applicable protocol: http
-
- Status: standard
-
- Author/Change controller: IETF
-
- Specification document(s): this specification (Section 11.2)
-
- Related information: none
-
-16.1.3. If-Schedule-Tag-Match
-
- Header field name: If-Schedule-Tag-Match
-
- Applicable protocol: http
-
- Status: standard
-
- Author/Change controller: IETF
-
- Specification document(s): this specification (Section 11.3)
-
- Related information: none
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 69]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
-16.2. iCalendar Property Parameter Registrations
-
- The following iCalendar property parameters should be added to the
- iCalendar Property Parameter Registry defined in Section 8.3.3 of
- [RFC5545].
-
- +---------------------+---------+-----------------------+
- | Parameter | Status | Reference |
- +---------------------+---------+-----------------------+
- | SCHEDULE-AGENT | Current | RFCXXXX, Section 10.1 |
- | | | |
- | SCHEDULE-STATUS | Current | RFCXXXX, Section 10.3 |
- | | | |
- | SCHEDULE-FORCE-SEND | Current | RFCXXXX, Section 10.2 |
- +---------------------+---------+-----------------------+
-
-16.3. iCalendar REQUEST-STATUS Value Registrations
-
- The following iCalendar "REQUEST-STATUS" values should be added to
- the iCalendar REQUEST-STATUS Value Registry defined in Section 7.3 of
- [RFC5546].
-
- +-------------+---------+-------------------------+
- | Status Code | Status | Reference |
- +-------------+---------+-------------------------+
- | 1.0 | Current | RFC XXXX, Section 9.2.1 |
- | | | |
- | 1.1 | Current | RFC XXXX, Section 9.2.2 |
- | | | |
- | 1.2 | Current | RFC XXXX, Section 9.2.3 |
- +-------------+---------+-------------------------+
-
-16.4. Additional iCalendar Elements Registries
-
- This specification adds two new IANA registries for iCalendar
- elements. Additional codes MAY be used, provided the process
- described in Section 8.2.1 of [RFC5545] is used to register them.
-
-16.4.1. Schedule Agent Values Registry
-
- The following table has been used to initialize the schedule agent
- values registry.
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 70]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- +----------------+---------+------------------------+
- | Schedule Agent | Status | Reference |
- +----------------+---------+------------------------+
- | SERVER | Current | RFC XXXX, Section 10.1 |
- | | | |
- | CLIENT | Current | RFC XXXX, Section 10.1 |
- | | | |
- | NONE | Current | RFC XXXX, Section 10.1 |
- +----------------+---------+------------------------+
-
-16.4.2. Schedule Force Send Values Registry
-
- The following table has been used to initialize the schedule send
- values registry.
-
- +---------------------+---------+------------------------+
- | Schedule Force Send | Status | Reference |
- +---------------------+---------+------------------------+
- | REQUEST | Current | RFC XXXX, Section 10.2 |
- | | | |
- | REPLY | Current | RFC XXXX, Section 10.2 |
- +---------------------+---------+------------------------+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 71]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
-17. Acknowledgements
-
- The authors would like to thank the following individuals for
- contributing their ideas and support for writing this specification:
- Mike Douglass, Lisa Dusseault, Helge Hess, Arnaud Quillaud, Julian F.
- Reschke, Wilfredo Sanchez Vega, Simon Vaillancourt, and Jim
- Whitehead.
-
- The authors would also like to thank the Calendaring and Scheduling
- Consortium for advice with this specification, and for organizing
- interoperability testing events to help refine it.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 72]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
-18. References
-
-18.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to
- Indicate Requirement Levels", BCP 14,
- RFC 2119, March 1997.
-
- [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk,
- H., Masinter, L., Leach, P., and T. Berners-
- Lee, "Hypertext Transfer Protocol --
- HTTP/1.1", RFC 2616, June 1999.
-
- [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
- May 2000.
-
- [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J.
- Whitehead, "Web Distributed Authoring and
- Versioning (WebDAV) Access Control Protocol",
- RFC 3744, May 2004.
-
- [RFC3864] Klyne, G., Nottingham, M., and J. Mogul,
- "Registration Procedures for Message Header
- Fields", BCP 90, RFC 3864, September 2004.
-
- [RFC4791] Daboo, C., Desruisseaux, B., and L.
- Dusseault, "Calendaring Extensions to WebDAV
- (CalDAV)", RFC 4791, March 2007.
-
- [RFC4918] Dusseault, L., "HTTP Extensions for Web
- Distributed Authoring and Versioning
- (WebDAV)", RFC 4918, June 2007.
-
- [RFC5234] Crocker, D. and P. Overell, "Augmented BNF
- for Syntax Specifications: ABNF", STD 68,
- RFC 5234, January 2008.
-
- [RFC5545] Desruisseaux, B., "Internet Calendaring and
- Scheduling Core Object Specification
- (iCalendar)", RFC 5545, September 2009.
-
- [RFC5546] Daboo, C., "iCalendar Transport-Independent
- Interoperability Protocol (iTIP)", RFC 5546,
- December 2009.
-
- [W3C.REC-xml-20081126] Paoli, J., Yergeau, F., Bray, T., Sperberg-
- McQueen, C., and E. Maler, "Extensible Markup
- Language (XML) 1.0 (Fifth Edition)", World
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 73]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- Wide Web Consortium Recommendation REC-xml-
- 20081126, November 2008,
- .
-
-18.2. Informative References
-
- [RFC3283] Mahoney, B., Babics, G., and A. Taler, "Guide
- to Internet Calendaring", RFC 3283,
- June 2002.
-
- [RFC6047] Melnikov, A., "iCalendar Message-Based
- Interoperability Protocol (iMIP)", RFC 6047,
- December 2010.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 74]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
-Appendix A. Scheduling Privileges Summary
-
-A.1. Scheduling Inbox Privileges
-
- The following tables specify which scheduling privileges grant the
- right to a calendar user to deliver a scheduling message to the
- scheduling Inbox collection of another calendar user. The
- appropriate behavior depends on the calendar component type as well
- as the scheduling "METHOD" specified in the scheduling message.
-
- +--------------------------------+
- | METHOD for VEVENT and VTODO |
- +-----------------------------+---------+-------+-----+--------+
- | Scheduling Inbox Privilege | REQUEST | REPLY | ADD | CANCEL |
- +-----------------------------+---------+-------+-----+--------+
- | schedule-deliver | * | * | * | * |
- | schedule-deliver-invite | * | | * | * |
- | schedule-deliver-reply | | * | | |
- | schedule-query-freebusy | | | | |
- +-----------------------------+---------+-------+-----+--------+
-
-
- +----------------------+
- | METHOD for VFREEBUSY |
- +-----------------------------+----------------------+
- | Scheduling Inbox Privilege | REQUEST |
- +-----------------------------+----------------------+
- | schedule-deliver | * |
- | schedule-deliver-invite | |
- | schedule-deliver-reply | |
- | schedule-query-freebusy | * |
- +-----------------------------+----------------------+
-
-A.2. Scheduling Outbox Privileges
-
- The following tables specify which scheduling privileges grant the
- right to a Calendar User to perform busy time information requests
- and to submit scheduling messages to other Calendar Users as the
- result of a scheduling transaction. The appropriate behavior depends
- on the calendar component type as well as the scheduling "METHOD"
- specified in the scheduling message.
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 75]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- +--------------------------------+
- | METHOD for VEVENT and VTODO |
- +-----------------------------+---------+-------+-----+--------+
- | Scheduling Outbox Privilege | REQUEST | REPLY | ADD | CANCEL |
- +-----------------------------+---------+-------+-----+--------+
- | schedule-send | * | * | * | * |
- | schedule-send-invite | * | | * | * |
- | schedule-send-reply | | * | | |
- | schedule-send-freebusy | | | | |
- +-----------------------------+---------+-------+-----+--------+
-
-
- +----------------------+
- | METHOD for VFREEBUSY |
- +-----------------------------+----------------------+
- | Scheduling Outbox Privilege | REQUEST |
- +-----------------------------+----------------------+
- | schedule-send | * |
- | schedule-send-invite | |
- | schedule-send-reply | |
- | schedule-send-freebusy | * |
- +-----------------------------+----------------------+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 76]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
-Appendix B. Example Scheduling Transactions
-
- This section describes some example scheduling transactions that give
- a general idea of how scheduling is carried out between CalDAV
- clients and servers from the perspective of meeting Organizers and
- Attendees.
-
- In the following examples the requests and responses are incomplete
- and are only for illustrative purposes. In particular, HTTP
- authentication headers and behaviors are not shown, even though they
- are required in normal operation.
-
-B.1. Example: Organizer Inviting Multiple Attendees
-
- In the following example, Cyrus invites Wilfredo, Bernard and Mike to
- a single instance event by simply creating a new scheduling object
- resource in one of his calendar collection by using the PUT method.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 77]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- >> Request <<
-
- PUT /home/cyrus/calendars/work/9263504FD3AD.ics HTTP/1.1
- Host: cal.example.com
- Content-Type: text/calendar; charset="utf-8"
- Content-Length: xxxx
- If-None-Match: *
-
- BEGIN:VCALENDAR
- VERSION:2.0
- PRODID:-//Example Corp.//CalDAV Client//EN
- BEGIN:VEVENT
- UID:9263504FD3AD
- SEQUENCE:0
- DTSTAMP:20090602T185254Z
- DTSTART:20090602T160000Z
- DTEND:20090602T170000Z
- TRANSP:OPAQUE
- SUMMARY:Lunch
- ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com
- ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:
- mailto:cyrus@example.com
- ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT
- =NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:wilfredo@
- example.com
- ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT=
- NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@ex
- ample.net
- ATTENDEE;CN="Mike Douglass";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-A
- CTION;RSVP=TRUE:mailto:mike@example.org
- END:VEVENT
- END:VCALENDAR
-
- >> Response <<
-
- HTTP/1.1 201 Created
- Content-Length: 0
- Date: Tue, 02 Jun 2009 18:52:54 GMT
- Last-Modified: Tue, 02 Jun 2009 18:52:54 GMT
- ETag: "d85561cfe74a4e785eb4639451b434fb"
- Schedule-Tag: "488177c8-2ea7-4176-a6cb-fab8cfccdea2"
-
- Once the event creation has been completed, Cyrus's client will
- retrieve the event back from the server to get the schedule status of
- each Attendee. In this example, the server reports that a scheduling
- message was delivered to Wilfredo, a scheduling message is still
- pending for Bernard, and the server was unable to deliver a
- scheduling message to Mike.
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 78]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- >> Request <<
-
- GET /home/cyrus/calendars/work/9263504FD3AD.ics HTTP/1.1
- Host: cal.example.com
-
- >> Response <<
-
- HTTP/1.1 200 OK
- Date: Tue, 02 Jun 2009 18:52:58 GMT
- Last-Modified: Tue, 02 Jun 2009 18:52:58 GMT
- ETag: "eb897deabc8939589da116714bc99265"
- Schedule-Tag: "488177c8-2ea7-4176-a6cb-fab8cfccdea2"
- Content-Type: text/calendar; charset="utf-8"
- Content-Length: xxxx
-
- BEGIN:VCALENDAR
- VERSION:2.0
- PRODID:-//Example Corp.//CalDAV Server//EN
- BEGIN:VEVENT
- UID:9263504FD3AD
- SEQUENCE:0
- DTSTAMP:20090602T185300Z
- DTSTART:20090602T160000Z
- DTEND:20090602T170000Z
- TRANSP:OPAQUE
- SUMMARY:Lunch
- ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com
- ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:
- mailto:cyrus@example.com
- ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT
- =NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE;SCHEDULE-STATUS=
- 1.2:mailto:wilfredo@e
- xample.com
- ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT=
- NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE;SCHEDULE-STATUS=
- 1.0:mailto:bernard@example.net
- ATTENDEE;CN="Mike Douglass";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-A
- CTION;RSVP=TRUE;SCHEDULE-STATUS=3.7:mailto:mike@example.org
- END:VEVENT
- END:VCALENDAR
-
-B.2. Example: Attendee Receiving an Invitation
-
- In the following example, Wilfredo's client retrieves and deletes the
- new scheduling message that appeared in his scheduling Inbox
- collection after the server automatically processed it and created a
- new scheduling object resource in his default calendar collection.
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 79]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- >> Request <<
-
- GET /home/wilfredo/calendars/inbox/27d93fc0a58c.ics HTTP/1.1
- Host: cal.example.com
-
- >> Response <<
-
- HTTP/1.1 200 OK
- Date: Tue, 02 Jun 2009 18:59:58 GMT
- Last-Modified: Tue, 02 Jun 2009 18:59:58 GMT
- ETag: "da116714bc9926c89395895eb897deab"
- Content-Type: text/calendar; charset="utf-8"
- Content-Length: xxxx
-
- BEGIN:VCALENDAR
- VERSION:2.0
- PRODID:-//Example Corp.//CalDAV Server//EN
- METHOD:REQUEST
- BEGIN:VEVENT
- UID:9263504FD3AD
- SEQUENCE:0
- DTSTAMP:20090602T185254Z
- DTSTART:20090602T160000Z
- DTEND:20090602T170000Z
- TRANSP:OPAQUE
- SUMMARY:Lunch
- ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com
- ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:
- mailto:cyrus@example.com
- ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT
- =NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:wilfredo@
- example.com
- ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT=
- NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@ex
- ample.net
- ATTENDEE;CN="Mike Douglass";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-A
- CTION;RSVP=TRUE:mailto:mike@example.org
- END:VEVENT
- END:VCALENDAR
-
- >> Request <<
-
- DELETE /home/wilfredo/calendars/inbox/27d93fc0a58c.ics HTTP/1.1
- Host: cal.example.com
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 80]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- >> Response <<
-
- HTTP/1.1 204 No Content
- Date: Tue, 02 Jun 2009 20:40:36 GMT
-
-B.3. Example: Attendee Replying to an Invitation
-
- In the following example, Wilfredo's accepts Cyrus's invitation and
- sets a reminder on the event.
-
- >> Request <<
-
- PUT /home/wilfredo/calendars/work/BB64861C2228.ics HTTP/1.1
- Host: cal.example.com
- If-Schedule-Tag-Match: "e78f23ed-0188-4bab-938d-2aeb3324c7e8"
- Content-Type: text/calendar; charset="utf-8"
- Content-Length: xxxx
-
- BEGIN:VCALENDAR
- VERSION:2.0
- PRODID:-//Example Corp.//CalDAV Client//EN
- BEGIN:VEVENT
- UID:9263504FD3AD
- SEQUENCE:0
- DTSTAMP:20090602T185254Z
- DTSTART:20090602T160000Z
- DTEND:20090602T170000Z
- TRANSP:OPAQUE
- SUMMARY:Lunch
- ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com
- ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:
- mailto:cyrus@example.com
- ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT
- =ACCEPTED;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:wilfredo@exam
- ple.com
- ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT=
- NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@ex
- ample.net
- ATTENDEE;CN="Mike Douglass";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-A
- CTION;RSVP=TRUE:mailto:mike@example.org
- BEGIN:VALARM
- TRIGGER:-PT15M
- ACTION:DISPLAY
- DESCRIPTION:Reminder
- END:VALARM
- END:VEVENT
- END:VCALENDAR
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 81]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- >> Response <<
-
- HTTP/1.1 200 OK
- Content-Length: 0
- Date: Tue, 02 Jun 2009 18:57:54 GMT
- Last-Modified: Tue, 02 Jun 2009 18:57:54 GMT
- ETag: "eb4639451b434fbd85561cfe74a4e785"
- Schedule-Tag: "8893ee45-eb9d-428f-b53c-c777daf19e41"
-
- Once the event modification has been completed, Wilfredo's client
- will retrieve the event back from the server to get the schedule
- status of the Organizer.
-
- >> Request <<
-
- GET /home/wilfredo/calendars/work/BB64861C2228.ics HTTP/1.1
- Host: cal.example.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 82]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- >> Response <<
-
- HTTP/1.1 200 OK
- Date: Tue, 02 Jun 2009 19:03:03 GMT
- Last-Modified: Tue, 02 Jun 2009 19:02:21 GMT
- ETag: "5eb897deabda116714bc9926c8939589"
- Schedule-Tag: "8893ee45-eb9d-428f-b53c-c777daf19e41"
- Content-Type: text/calendar; charset="utf-8"
- Content-Length: xxxx
-
- BEGIN:VCALENDAR
- VERSION:2.0
- PRODID:-//Example Corp.//CalDAV Client//EN
- BEGIN:VEVENT
- UID:9263504FD3AD
- SEQUENCE:0
- DTSTAMP:20090602T190221Z
- DTSTART:20090602T160000Z
- DTEND:20090602T170000Z
- TRANSP:OPAQUE
- SUMMARY:Lunch
- ORGANIZER;CN="Cyrus Daboo";SCHEDULE-STATUS=1.2:mailto:cyrus@ex
- ample.com
- ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:
- mailto:cyrus@example.com
- ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT
- =ACCEPTED;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:wilfredo@exam
- ple.com
- ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT=
- NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@ex
- ample.net
- ATTENDEE;CN="Mike Douglass";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-A
- CTION;RSVP=TRUE:mailto:mike@example.org
- BEGIN:VALARM
- TRIGGER:-PT15M
- ACTION:DISPLAY
- DESCRIPTION:Reminder
- END:VALARM
- END:VEVENT
- END:VCALENDAR
-
-B.4. Example: Organizer Receiving a Reply to an Invitation
-
- On reception of Wilfredo's reply, Cyrus's server will automatically
- update Cyrus's scheduling object resource, make Wilfredo's scheduling
- message available in Cyrus's scheduling Inbox collection, and deliver
- an updated scheduling message to Bernard to share Wilfredo's updated
- participation status. In this example, Cyrus's client retrieves and
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 83]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- deletes this scheduling message in his scheduling Inbox collection.
-
- >> Request <<
-
- GET /home/cyrus/calendars/inbox/c0a58c27d93f.ics HTTP/1.1
- Host: cal.example.com
-
- >> Response <<
-
- HTTP/1.1 200 OK
- Date: Tue, 02 Jun 2009 19:05:02 GMT
- Last-Modified: Tue, 02 Jun 2009 19:04:20 GMT
- ETag: "9265eb897deabc8939589da116714bc9"
- Content-Type: text/calendar; charset="utf-8"
- Content-Length: xxxx
-
- BEGIN:VCALENDAR
- VERSION:2.0
- PRODID:-//Example Corp.//CalDAV Server//EN
- METHOD:REPLY
- BEGIN:VEVENT
- UID:9263504FD3AD
- SEQUENCE:0
- DTSTAMP:20090602T185754Z
- DTSTART:20090602T160000Z
- DTEND:20090602T170000Z
- ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com
- ATTENDEE;CN="Wilfredo Sanchez Vega";PARTSTAT=ACCEPTED:mailto:w
- ilfredo@example.com
- REQUEST-STATUS:2.0;Success
- END:VEVENT
- END:VCALENDAR
-
- >> Request <<
-
- DELETE /home/cyrus/calendars/inbox/c0a58c27d93f.ics HTTP/1.1
- Host: cal.example.com
-
- >> Response <<
-
- HTTP/1.1 204 No Content
- Date: Tue, 02 Jun 2009 19:05:05 GMT
-
- Cyrus's client then retrieves the event back from the server with
- Wilfredo's updated participation status.
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 84]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- >> Request <<
-
- GET /home/cyrus/calendars/work/9263504FD3AD.ics HTTP/1.1
- Host: cal.example.com
-
- >> Response <<
-
- HTTP/1.1 200 OK
- Date: Tue, 02 Jun 2009 19:05:02 GMT
- Last-Modified: Tue, 02 Jun 2009 19:04:20 GMT
- ETag: "eb897deabc8939589da116714bc99265"
- Schedule-Tag: "132cab27-1fe3-67ab-de13-abd348d1dee3"
- Content-Type: text/calendar; charset="utf-8"
- Content-Length: xxxx
-
- BEGIN:VCALENDAR
- VERSION:2.0
- PRODID:-//Example Corp.//CalDAV Server//EN
- BEGIN:VEVENT
- UID:9263504FD3AD
- SEQUENCE:0
- DTSTAMP:20090602T190420Z
- DTSTART:20090602T160000Z
- DTEND:20090602T170000Z
- TRANSP:OPAQUE
- SUMMARY:Lunch
- ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com
- ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:
- mailto:cyrus@example.com
- ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT
- =ACCEPTED;ROLE=REQ-PARTICIPANT;RSVP=TRUE;SCHEDULE-STATUS=2.0:
- mailto:wilfredo@example.com
- ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT=
- NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE;SCHEDULE-STATUS=1
- .0:mailto:bernard@example.net
- ATTENDEE;CN="Mike Douglass";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-A
- CTION;RSVP=TRUE;SCHEDULE-STATUS=3.7:mailto:mike@example.org
- END:VEVENT
- END:VCALENDAR
-
-B.5. Example: Organizer Requesting Busy Time Information
-
- In this example, Cyrus requests the busy time information of
- Wilfredo, Bernard and Mike.
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 85]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- >> Request <<
-
- POST /home/cyrus/calendars/outbox/ HTTP/1.1
- Host: cal.example.com
- Content-Type: text/calendar; charset="utf-8"
- Content-Length: xxxx
-
- BEGIN:VCALENDAR
- VERSION:2.0
- PRODID:-//Example Corp.//CalDAV Client//EN
- METHOD:REQUEST
- BEGIN:VFREEBUSY
- UID:4FD3AD926350
- DTSTAMP:20090602T190420Z
- DTSTART:20090602T000000Z
- DTEND:20090604T000000Z
- ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com
- ATTENDEE;CN="Wilfredo Sanchez Vega":mailto:wilfredo@example.com
- ATTENDEE;CN="Bernard Desruisseaux":mailto:bernard@example.net
- ATTENDEE;CN="Mike Douglass":mailto:mike@example.org
- END:VFREEBUSY
- END:VCALENDAR
-
- >> Response <<
-
- HTTP/1.1 200 OK
- Date: Tue, 02 Jun 2009 20:07:34 GMT
- Content-Type: application/xml; charset="utf-8"
- Content-Length: xxxx
-
-
-
-
-
- mailto:wilfredo@example.com
-
- 2.0;Success
- BEGIN:VCALENDAR
- VERSION:2.0
- PRODID:-//Example Corp.//CalDAV Server//EN
- METHOD:REPLY
- BEGIN:VFREEBUSY
- UID:4FD3AD926350
- DTSTAMP:20090602T200733Z
- DTSTART:20090602T000000Z
- DTEND:20090604T000000Z
- ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 86]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- ATTENDEE;CN="Wilfredo Sanchez Vega":mailto:wilfredo@example.com
- FREEBUSY;FBTYPE=BUSY:20090602T110000Z/20090602T120000Z
- FREEBUSY;FBTYPE=BUSY:20090603T170000Z/20090603T180000Z
- END:VFREEBUSY
- END:VCALENDAR
-
-
-
-
- mailto:bernard@example.net
-
- 2.0;Success
- BEGIN:VCALENDAR
- VERSION:2.0
- PRODID:-//Example Corp.//CalDAV Server//EN
- METHOD:REPLY
- BEGIN:VFREEBUSY
- UID:4FD3AD926350
- DTSTAMP:20090602T200733Z
- DTSTART:20090602T000000Z
- DTEND:20090604T000000Z
- ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com
- ATTENDEE;CN="Bernard Desruisseaux":mailto:bernard@example.net
- FREEBUSY;FBTYPE=BUSY:20090602T150000Z/20090602T160000Z
- FREEBUSY;FBTYPE=BUSY:20090603T090000Z/20090603T100000Z
- FREEBUSY;FBTYPE=BUSY:20090603T180000Z/20090603T190000Z
- END:VFREEBUSY
- END:VCALENDAR
-
-
-
-
- mailto:mike@example.org
-
- 3.7;Invalid calendar user
-
-
-
-B.6. Example: User Attempting to Invite Attendee on behalf of Organizer
-
- In the following example, Cyrus attempts to create, on behalf of
- Wilfredo, an event with Bernard specified as an Attendee. The
- request fails since Wilfredo didn't grant Cyrus the right to invite
- other Calendar Users on his behalf.
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 87]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- >> Request <<
-
- PUT /home/wilfredo/calendars/work/def456.ics HTTP/1.1
- Host: cal.example.com
- Content-Type: text/calendar; charset="utf-8"
- Content-Length: xxxx
- If-None-Match: *
-
- BEGIN:VCALENDAR
- VERSION:2.0
- PRODID:-//Example Corp.//CalDAV Client//EN
- BEGIN:VEVENT
- UID:3504F926D3AD
- SEQUENCE:0
- DTSTAMP:20090602T190221Z
- DTSTART:20090602T230000Z
- DTEND:20090603T000000Z
- TRANSP:OPAQUE
- SUMMARY:Dinner
- ORGANIZER;CN="Wilfredo Sanchez Vega":mailto:wilfredo@example.com
- ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT=A
- CCEPTED:mailto:wilfredo@example.com
- ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT=NE
- EDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@exampl
- e.net
- END:VEVENT
- END:VCALENDAR
-
- >> Response <<
-
- HTTP/1.1 403 Forbidden
- Content-Type: application/xml; charset="utf-8"
- Content-Length: xxxx
-
-
-
-
- /home/wilfredo/calendars/outbox/
-
-
-
-
-
-B.7. Example: Attendee Declining an Instance of a Recurring Event
-
- In the following example, Bernard declines the second recurrence
- instance of a daily recurring event he's been invited to by Cyrus.
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 88]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- >> Request <<
-
- PUT /home/bernard/calendars/work/4FD3AD926350.ics HTTP/1.1
- Host: cal.example.com
- Content-Type: text/calendar; charset="utf-8"
- Content-Length: xxxx
- If-Schedule-Tag-Match: "7775FB30-7534-489E-A79A-0EA147B933EB"
-
- BEGIN:VCALENDAR
- VERSION:2.0
- PRODID:-//Example Corp.//CalDAV Client//EN
- BEGIN:VTIMEZONE
- TZID:America/Montreal
- BEGIN:STANDARD
- DTSTART:20071104T020000
- RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
- TZNAME:EST
- TZOFFSETFROM:-0400
- TZOFFSETTO:-0500
- END:STANDARD
- BEGIN:DAYLIGHT
- DTSTART:20070311T020000
- RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
- TZNAME:EDT
- TZOFFSETFROM:-0500
- TZOFFSETTO:-0400
- END:DAYLIGHT
- END:VTIMEZONE
- BEGIN:VEVENT
- UID:9263504FD3AD
- SEQUENCE:0
- DTSTAMP:20090602T185254Z
- DTSTART;TZID=America/Montreal:20090601T150000
- DTEND;TZID=America/Montreal:20090601T160000
- RRULE:FREQ=DAILY;INTERVAL=1;COUNT=5
- TRANSP:OPAQUE
- SUMMARY:Review Internet-Draft
- ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com
- ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:
- mailto:cyrus@example.com
- ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT=
- ACCEPTED;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@exampl
- e.net
- END:VEVENT
- BEGIN:VEVENT
- UID:9263504FD3AD
- SEQUENCE:0
- DTSTAMP:20090603T183823Z
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 89]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- RECURRENCE-ID;TZID=America/Montreal:20090602T150000
- DTSTART;TZID=America/Montreal:20090602T150000
- DTEND;TZID=America/Montreal:20090602T160000
- TRANSP:TRANSPARENT
- SUMMARY:Review Internet-Draft
- ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com
- ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:
- mailto:cyrus@example.com
- ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT=
- DECLINED;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@exampl
- e.net
- END:VEVENT
- END:VCALENDAR
-
- >> Response <<
-
- HTTP/1.1 200 OK
- Content-Length: 0
- Date: Tue, 02 Jun 2009 18:52:54 GMT
- Last-Modified: Tue, 02 Jun 2009 18:52:54 GMT
- ETag: "d85561cfe74a4e785eb4639451b434fb"
- Schedule-Tag: "488177c8-2ea7-4176-a6cb-fab8cfccdea2"
-
- Bernard's participation status update will cause his server to
- deliver a scheduling message to Cyrus. Cyrus's client will find the
- following reply message from Bernard in Cyrus's scheduling Inbox
- collection:
-
- >> Request <<
-
- GET /home/cyrus/calendars/inbox/9263504FD3AD.ics HTTP/1.1
- Host: cal.example.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 90]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- >> Response <<
-
- HTTP/1.1 200 OK
- Date: Tue, 02 Jun 2009 18:52:58 GMT
- Last-Modified: Tue, 02 Jun 2009 18:52:58 GMT
- ETag: "eb897deabc8939589da116714bc99265"
- Content-Type: text/calendar; charset="utf-8"
- Content-Length: xxxx
-
- BEGIN:VCALENDAR
- VERSION:2.0
- PRODID:-//Example Corp.//CalDAV Client//EN
- METHOD:REPLY
- BEGIN:VTIMEZONE
- TZID:America/Montreal
- BEGIN:STANDARD
- DTSTART:20071104T020000
- RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
- TZNAME:EST
- TZOFFSETFROM:-0400
- TZOFFSETTO:-0500
- END:STANDARD
- BEGIN:DAYLIGHT
- DTSTART:20070311T020000
- RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
- TZNAME:EDT
- TZOFFSETFROM:-0500
- TZOFFSETTO:-0400
- END:DAYLIGHT
- END:VTIMEZONE
- BEGIN:VEVENT
- UID:9263504FD3AD
- SEQUENCE:0
- DTSTAMP:20090603T183823Z
- RECURRENCE-ID;TZID=America/Montreal:20090602T150000
- DTSTART;TZID=America/Montreal:20090602T150000
- DTEND;TZID=America/Montreal:20090602T160000
- SUMMARY:Review Internet-Draft
- ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com
- ATTENDEE;CN="Bernard Desruisseaux";PARTSTAT=DECLINED:
- mailto:bernard@example.net
- REQUEST-STATUS:2.0;Success
- END:VEVENT
- END:VCALENDAR
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 91]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
-B.8. Example: Attendee Removing an Instance of a Recurring Event
-
- In the following example, Bernard removes from his calendar the third
- recurrence instance of a daily recurring event he's been invited to
- by Cyrus. This is accomplished by the addition of an "EXDATE"
- property to the scheduling object resource stored by Bernard.
-
- >> Request <<
-
- PUT /home/bernard/calendars/work/4FD3AD926350.ics HTTP/1.1
- Host: cal.example.com
- Content-Type: text/calendar; charset="utf-8"
- Content-Length: xxxx
- If-Schedule-Tag-Match: "488177c8-2ea7-4176-a6cb-fab8cfccdea2"
-
- BEGIN:VCALENDAR
- VERSION:2.0
- PRODID:-//Example Corp.//CalDAV Client//EN
- BEGIN:VTIMEZONE
- TZID:America/Montreal
- BEGIN:STANDARD
- DTSTART:20071104T020000
- RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
- TZNAME:EST
- TZOFFSETFROM:-0400
- TZOFFSETTO:-0500
- END:STANDARD
- BEGIN:DAYLIGHT
- DTSTART:20070311T020000
- RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
- TZNAME:EDT
- TZOFFSETFROM:-0500
- TZOFFSETTO:-0400
- END:DAYLIGHT
- END:VTIMEZONE
- BEGIN:VEVENT
- UID:9263504FD3AD
- SEQUENCE:0
- DTSTAMP:20090602T185254Z
- DTSTART;TZID=America/Montreal:20090601T150000
- DTEND;TZID=America/Montreal:20090601T160000
- RRULE:FREQ=DAILY;INTERVAL=1;COUNT=5
- EXDATE;TZID=America/Montreal:20090603T150000
- TRANSP:OPAQUE
- SUMMARY:Review Internet-Draft
- ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com
- ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:
- mailto:cyrus@example.com
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 92]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT=
- ACCEPTED;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@exampl
- e.net
- END:VEVENT
- BEGIN:VEVENT
- UID:9263504FD3AD
- SEQUENCE:0
- DTSTAMP:20090603T183823Z
- RECURRENCE-ID;TZID=America/Montreal:20090602T150000
- DTSTART;TZID=America/Montreal:20090602T150000
- DTEND;TZID=America/Montreal:20090602T160000
- TRANSP:TRANSPARENT
- SUMMARY:Review Internet-Draft
- ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com
- ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:
- mailto:cyrus@example.com
- ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT=
- DECLINED;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@exampl
- e.net
- END:VEVENT
- END:VCALENDAR
-
- Bernard's deletion of a recurrence instance will cause his server to
- deliver a scheduling message to Cyrus. Cyrus's client will find the
- following reply message from Bernard in Cyrus's scheduling Inbox
- collection:
-
- >> Request <<
-
- GET /home/cyrus/calendars/inbox/6504923FD3AD.ics HTTP/1.1
- Host: cal.example.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 93]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- >> Response <<
-
- HTTP/1.1 200 OK
- Date: Tue, 02 Jun 2009 18:52:58 GMT
- Last-Modified: Tue, 02 Jun 2009 18:52:58 GMT
- ETag: "eb897deabc8939589da116714bc99265"
- Content-Type: text/calendar; charset="utf-8"
- Content-Length: xxxx
-
- BEGIN:VCALENDAR
- VERSION:2.0
- PRODID:-//Example Corp.//CalDAV Client//EN
- METHOD:REPLY
- BEGIN:VTIMEZONE
- TZID:America/Montreal
- BEGIN:STANDARD
- DTSTART:20071104T020000
- RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
- TZNAME:EST
- TZOFFSETFROM:-0400
- TZOFFSETTO:-0500
- END:STANDARD
- BEGIN:DAYLIGHT
- DTSTART:20070311T020000
- RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
- TZNAME:EDT
- TZOFFSETFROM:-0500
- TZOFFSETTO:-0400
- END:DAYLIGHT
- END:VTIMEZONE
- BEGIN:VEVENT
- UID:9263504FD3AD
- SEQUENCE:0
- DTSTAMP:20090603T183823Z
- RECURRENCE-ID;TZID=America/Montreal:20090603T150000
- DTSTART;TZID=America/Montreal:20090603T150000
- DTEND;TZID=America/Montreal:20090603T160000
- SUMMARY:Review Internet-Draft
- ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com
- ATTENDEE;CN="Bernard Desruisseaux";PARTSTAT=DECLINED:
- mailto:bernard@example.net
- REQUEST-STATUS:2.0;Success
- END:VEVENT
- END:VCALENDAR
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 94]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
-Appendix C. Changes (to be removed by RFC Editor prior to publication)
-
-C.1. Changes in -10
-
- a. Updated to RFC 6047 reference.
-
- b. Various minor clarifications to behavior and terminology done.
-
- c. Clarified that Inbox/Outbox are the server's responsibility to
- create.
-
- d. Changed MAY to SHOULD for server rejecting organizer PARTSTAT
- changes of attendees.
-
- e. Allow COMPLETED as a valid attendee change.
-
- f. Allow SCHEDULE-STATUS as a valid attendee change on SCHEDULE-
- AGENT=CLIENT attendee properties.
-
- g. COPY or MOVE on a calendar collection now declared to be
- undefined.
-
- h. Changed pre-condition error codes from 409 to 403.
-
- i. Clarified that rules 5546 must be used when server processes
- incoming scheduling messages.
-
- j. default-calendar-delete-allowed -> default-calendar-needed.
-
- k. Clarified that SCHEDULE-AGENT must be the same on all matching
- properties.
-
- l. Added more text justifying the need for calendar-user-type
- property.
-
-C.2. Changes in -09
-
- a. Fixed some examples.
-
- b. Tweaked XML conventions.
-
- c. Removed description in SCHEDULE-STATUS example values.
-
- d. Tweaked 3.7 and 3.8 SCHEDULE-STATUS description to indicate it
- applies to the Organizer as well as Attendee.
-
- e. Updated to RFC 5545 reference.
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 95]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- f. AD Review: clarified text about inbox resource deletion being
- acknowledgment of change.
-
- g. AD Review: clarified description of freebusy Outbox POST.
-
- h. AD Review: registered new 1.xx request-status codes and added new
- restriction on usage as per iTIP.
-
- i. AD Review: changes SHOULD NOT to MUST NOT for new property
- parameters when clients send scheduling messages.
-
- j. AD Review: CALDAV:schedule-calendar-transp now preserved during
- COPY.
-
- k. AD Review: changed CALDAV- to CALDAV: in acl descriptions.
-
- l. AD Review: fixed various minor typos.
-
- m. AD Review: Added text to new principal properties to indicate
- that if they are not present, then the user is not enabled for
- the various scheduling operations.
-
- n. AD Review: clarified use of CALDAV:calendar-data element in
- CALDAV:response element.
-
- o. AD Review: made reference to 5545 IANA registry procedures for
- the two new element registries.
-
- p. AD Review: Fixed description of B5. example.
-
- q. Fixed SCHEDULE-AGENT/SCHEDULE-STATUS behavior for Attendee
- replies.
-
-C.3. Changes in -08
-
- a. Added "Updates 4791".
-
- b. XML conventions changed to match that in CardDAV spec.
-
- c. Reworded child response behavior for Outbox.
-
- d. Reworded "octet size".
-
- e. If-Schedule-Match descriptions changed to remove implication that
- it is purely a conditional operation.
-
- f. Schedule-Reply header descriptions generalized to resource
- removal rather than just HTTP DELETE.
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 96]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- g. Fixed various examples.
-
-C.4. Changes in -07
-
- a. Restructured document.
-
- b. Clarified that CALDAV:schedule-calendar-transp only applies to
- calendar collection.
-
- c. Removed CALDAV:schedule-state property on scheduling messages in
- the scheduling Inbox collection.
-
- d. Added conditional requests on scheduling object resources.
-
- e. Added section on handling of PARTSTAT.
-
- f. Added SCHEDULE-FORCE-SEND iCalendar property parameter.
-
- g. Added clarification on child resources in scheduling Outbox
- collections.
-
- h. Clarified Attendee changes that server MUST allow, and removed
- restrictions on changes that Attendee MUST NOT do.
-
- i. Added Example Scheduling Transactions appendix.
-
- j. Scheduling privileges are no longer required to be non-abstract.
-
- k. Removed handling of REFRESH requests.
-
- l. Removed handling of VJOURNAL components.
-
- m. Completed IANA Considerations section.
-
- n. Added references to RFC3283 and RFC5234.
-
- o. Updated references to iCalendar, iTIP and iMIP.
-
-C.5. Changes in -06
-
- a. Removed distinction between scheduling calendar collections and
- basic calendar collections - now just have calendar collections.
-
- b. Clients now "MAY" reload data rather than "SHOULD" reload data.
-
- c. Fixed in examples.
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 97]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
- d. Removed CALDAV:attachments-allowed precondition on POST to Outbox
- as that is no longer relevant.
-
- e. Added CALDAV:default-calendar-delete-allowed precondition for
- DELETE.
-
- f. Relaxed MUST->MAY for Organizer setting PARTSTAT value.
-
- g. Tweaked restrictions on Create/Modify to emphasize that 4791
- restrictions also apply.
-
- h. Added comment that 'opaque' is the default when the CALDAV:
- schedule-calendar-transp property is not present.
-
- i. Description of Schedule-Reply header changed to reflect that it
- is only relevant for Attendees.
-
- j. Minor typos fixed.
-
-C.6. Changes in -05
-
- This draft has changed substantially since the -04 version. The
- primary reason for this change was implementation experience from a
- number of vendors who implemented products based on the earlier
- drafts. Experience showed that the client/server interaction was not
- reliable in keeping scheduling messages synchronized between
- organizer and attendees. In addition the latency in updates due to
- clients being offline proved unacceptable to users. These issues led
- to the redesign of this specification to support a server-based
- processing model that eliminates all the problems seen previously.
- Whilst this adds significant complexity to the server in that it
- needs to be a full blown iTIP processing agent, it does remove a lot
- of the same complexity from clients, opening up the possibility of
- supporting complex scheduling behaviors even with "thin" clients.
-
- In the judgement of the authors, we consider this new specification
- to be a substantial improvement over the old one and believe it
- represents a stronger protocol that will lead to better
- interoperability.
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 98]
-
-Internet-Draft CalDAV Scheduling Extensions September 2011
-
-
-Authors' Addresses
-
- Cyrus Daboo
- Apple Inc.
- 1 Infinite Loop
- Cupertino, CA 95014
- USA
-
- EMail: cyrus@daboo.name
- URI: http://www.apple.com/
-
-
- Bernard Desruisseaux
- Oracle Corporation
- 600 Blvd. de Maisonneuve West
- Suite 1900
- Montreal, QC H3A 3J2
- CANADA
-
- EMail: bernard.desruisseaux@oracle.com
- URI: http://www.oracle.com/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo & Desruisseaux Expires March 10, 2012 [Page 99]
-
diff --git a/vendor/sabre/dav/docs/draft-ietf-httpbis-p1-messaging-11.txt b/vendor/sabre/dav/docs/draft-ietf-httpbis-p1-messaging-11.txt
deleted file mode 100644
index c0d449877..000000000
--- a/vendor/sabre/dav/docs/draft-ietf-httpbis-p1-messaging-11.txt
+++ /dev/null
@@ -1,5152 +0,0 @@
-
-
-
-HTTPbis Working Group R. Fielding, Ed.
-Internet-Draft Day Software
-Obsoletes: 2616 (if approved) J. Gettys
-Updates: 2817 (if approved) Alcatel-Lucent
-Intended status: Standards Track J. Mogul
-Expires: February 5, 2011 HP
- H. Frystyk
- Microsoft
- L. Masinter
- Adobe Systems
- P. Leach
- Microsoft
- T. Berners-Lee
- W3C/MIT
- Y. Lafon, Ed.
- W3C
- J. Reschke, Ed.
- greenbytes
- August 4, 2010
-
-
- HTTP/1.1, part 1: URIs, Connections, and Message Parsing
- draft-ietf-httpbis-p1-messaging-11
-
-Abstract
-
- The Hypertext Transfer Protocol (HTTP) is an application-level
- protocol for distributed, collaborative, hypertext information
- systems. HTTP has been in use by the World Wide Web global
- information initiative since 1990. This document is Part 1 of the
- seven-part specification that defines the protocol referred to as
- "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides
- an overview of HTTP and its associated terminology, defines the
- "http" and "https" Uniform Resource Identifier (URI) schemes, defines
- the generic message syntax and parsing requirements for HTTP message
- frames, and describes general security concerns for implementations.
-
-Editorial Note (To be removed by RFC Editor)
-
- Discussion of this draft should take place on the HTTPBIS working
- group mailing list (ietf-http-wg@w3.org). The current issues list is
- at and related
- documents (including fancy diffs) can be found at
- .
-
- The changes in this draft are summarized in Appendix D.12.
-
-Status of This Memo
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 1]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- This Internet-Draft is submitted in full conformance with the
- provisions of BCP 78 and BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF). Note that other groups may also distribute
- working documents as Internet-Drafts. The list of current Internet-
- Drafts is at http://datatracker.ietf.org/drafts/current/.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- This Internet-Draft will expire on February 5, 2011.
-
-Copyright Notice
-
- Copyright (c) 2010 IETF Trust and the persons identified as the
- document authors. All rights reserved.
-
- This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents
- (http://trustee.ietf.org/license-info) in effect on the date of
- publication of this document. Please review these documents
- carefully, as they describe your rights and restrictions with respect
- to this document. Code Components extracted from this document must
- include Simplified BSD License text as described in Section 4.e of
- the Trust Legal Provisions and are provided without warranty as
- described in the Simplified BSD License.
-
- This document may contain material from IETF Documents or IETF
- Contributions published or made publicly available before November
- 10, 2008. The person(s) controlling the copyright in some of this
- material may not have granted the IETF Trust the right to allow
- modifications of such material outside the IETF Standards Process.
- Without obtaining an adequate license from the person(s) controlling
- the copyright in such materials, this document may not be modified
- outside the IETF Standards Process, and derivative works of it may
- not be created outside the IETF Standards Process, except to format
- it for publication as an RFC or to translate it into languages other
- than English.
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7
- 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7
- 1.2.1. ABNF Extension: #rule . . . . . . . . . . . . . . . . 7
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 2]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- 1.2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . 8
- 1.2.3. ABNF Rules defined in other Parts of the
- Specification . . . . . . . . . . . . . . . . . . . . 10
- 2. HTTP-related architecture . . . . . . . . . . . . . . . . . . 10
- 2.1. Client/Server Messaging . . . . . . . . . . . . . . . . . 10
- 2.2. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 12
- 2.3. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 13
- 2.4. Transport Independence . . . . . . . . . . . . . . . . . . 14
- 2.5. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 14
- 2.6. Uniform Resource Identifiers . . . . . . . . . . . . . . . 16
- 2.6.1. http URI scheme . . . . . . . . . . . . . . . . . . . 16
- 2.6.2. https URI scheme . . . . . . . . . . . . . . . . . . . 18
- 2.6.3. http and https URI Normalization and Comparison . . . 18
- 3. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 19
- 3.1. Message Parsing Robustness . . . . . . . . . . . . . . . . 20
- 3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 20
- 3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 22
- 3.4. General Header Fields . . . . . . . . . . . . . . . . . . 25
- 4. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
- 4.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 26
- 4.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 26
- 4.1.2. request-target . . . . . . . . . . . . . . . . . . . . 27
- 4.2. The Resource Identified by a Request . . . . . . . . . . . 29
- 4.3. Effective Request URI . . . . . . . . . . . . . . . . . . 29
- 5. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
- 5.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 31
- 5.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 31
- 6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 32
- 6.1. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 32
- 6.2. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 34
- 6.2.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 35
- 6.2.2. Compression Codings . . . . . . . . . . . . . . . . . 37
- 6.2.3. Transfer Coding Registry . . . . . . . . . . . . . . . 38
- 6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 39
- 6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 39
- 7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 39
- 7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 39
- 7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 40
- 7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 40
- 7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 42
- 7.1.4. Practical Considerations . . . . . . . . . . . . . . . 44
- 7.2. Message Transmission Requirements . . . . . . . . . . . . 45
- 7.2.1. Persistent Connections and Flow Control . . . . . . . 45
- 7.2.2. Monitoring Connections for Error Status Messages . . . 45
- 7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 46
- 7.2.4. Client Behavior if Server Prematurely Closes
- Connection . . . . . . . . . . . . . . . . . . . . . . 48
- 8. Miscellaneous notes that might disappear . . . . . . . . . . . 49
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 3]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- 8.1. Scheme aliases considered harmful . . . . . . . . . . . . 49
- 8.2. Use of HTTP for proxy communication . . . . . . . . . . . 49
- 8.3. Interception of HTTP for access control . . . . . . . . . 49
- 8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 49
- 8.5. Use of HTTP by media type specification . . . . . . . . . 49
- 9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 49
- 9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 49
- 9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 50
- 9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
- 9.3.1. Clockless Origin Server Operation . . . . . . . . . . 52
- 9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
- 9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
- 9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 54
- 9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 55
- 9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 55
- 9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 56
- 9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
- 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59
- 10.1. Header Field Registration . . . . . . . . . . . . . . . . 59
- 10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 59
- 10.3. Internet Media Type Registrations . . . . . . . . . . . . 59
- 10.3.1. Internet Media Type message/http . . . . . . . . . . . 59
- 10.3.2. Internet Media Type application/http . . . . . . . . . 61
- 10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 62
- 10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 62
- 11. Security Considerations . . . . . . . . . . . . . . . . . . . 62
- 11.1. Personal Information . . . . . . . . . . . . . . . . . . . 63
- 11.2. Abuse of Server Log Information . . . . . . . . . . . . . 63
- 11.3. Attacks Based On File and Path Names . . . . . . . . . . . 63
- 11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 63
- 11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 64
- 11.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 65
- 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 65
- 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66
- 13.1. Normative References . . . . . . . . . . . . . . . . . . . 66
- 13.2. Informative References . . . . . . . . . . . . . . . . . . 68
- Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 70
- Appendix B. Compatibility with Previous Versions . . . . . . . . 71
- B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 71
- B.1.1. Changes to Simplify Multi-homed Web Servers and
- Conserve IP Addresses . . . . . . . . . . . . . . . . 72
- B.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 72
- B.3. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 73
- Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 74
- Appendix D. Change Log (to be removed by RFC Editor before
- publication) . . . . . . . . . . . . . . . . . . . . 78
- D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 78
- D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 78
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 4]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 80
- D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 81
- D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 81
- D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 82
- D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 82
- D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 83
- D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 84
- D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 84
- D.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 85
- D.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 85
- Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 5]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
-1. Introduction
-
- The Hypertext Transfer Protocol (HTTP) is an application-level
- request/response protocol that uses extensible semantics and MIME-
- like message payloads for flexible interaction with network-based
- hypertext information systems. HTTP relies upon the Uniform Resource
- Identifier (URI) standard [RFC3986] to indicate request targets and
- relationships between resources. Messages are passed in a format
- similar to that used by Internet mail [RFC5322] and the Multipurpose
- Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of [Part3]
- for the differences between HTTP and MIME messages).
-
- HTTP is a generic interface protocol for information systems. It is
- designed to hide the details of how a service is implemented by
- presenting a uniform interface to clients that is independent of the
- types of resources provided. Likewise, servers do not need to be
- aware of each client's purpose: an HTTP request can be considered in
- isolation rather than being associated with a specific type of client
- or a predetermined sequence of application steps. The result is a
- protocol that can be used effectively in many different contexts and
- for which implementations can evolve independently over time.
-
- HTTP is also designed for use as an intermediation protocol for
- translating communication to and from non-HTTP information systems.
- HTTP proxies and gateways can provide access to alternative
- information services by translating their diverse protocols into a
- hypertext format that can be viewed and manipulated by clients in the
- same way as HTTP services.
-
- One consequence of HTTP flexibility is that the protocol cannot be
- defined in terms of what occurs behind the interface. Instead, we
- are limited to defining the syntax of communication, the intent of
- received communication, and the expected behavior of recipients. If
- the communication is considered in isolation, then successful actions
- ought to be reflected in corresponding changes to the observable
- interface provided by servers. However, since multiple clients might
- act in parallel and perhaps at cross-purposes, we cannot require that
- such changes be observable beyond the scope of a single response.
-
- This document is Part 1 of the seven-part specification of HTTP,
- defining the protocol referred to as "HTTP/1.1" and obsoleting
- [RFC2616]. Part 1 describes the architectural elements that are used
- or referred to in HTTP, defines the "http" and "https" URI schemes,
- describes overall network operation and connection management, and
- defines HTTP message framing and forwarding requirements. Our goal
- is to define all of the mechanisms necessary for HTTP message
- handling that are independent of message semantics, thereby defining
- the complete set of requirements for message parsers and message-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 6]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- forwarding intermediaries.
-
-1.1. Requirements
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
- An implementation is not compliant if it fails to satisfy one or more
- of the "MUST" or "REQUIRED" level requirements for the protocols it
- implements. An implementation that satisfies all the "MUST" or
- "REQUIRED" level and all the "SHOULD" level requirements for its
- protocols is said to be "unconditionally compliant"; one that
- satisfies all the "MUST" level requirements but not all the "SHOULD"
- level requirements for its protocols is said to be "conditionally
- compliant".
-
-1.2. Syntax Notation
-
- This specification uses the Augmented Backus-Naur Form (ABNF)
- notation of [RFC5234].
-
- The following core rules are included by reference, as defined in
- [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
- (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
- HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
- sequence of data), SP (space), VCHAR (any visible [USASCII]
- character), and WSP (whitespace).
-
- As a syntactic convention, ABNF rule names prefixed with "obs-"
- denote "obsolete" grammar rules that appear for historical reasons.
-
-1.2.1. ABNF Extension: #rule
-
- The #rule extension to the ABNF rules of [RFC5234] is used to improve
- readability.
-
- A construct "#" is defined, similar to "*", for defining comma-
- delimited lists of elements. The full form is "#element"
- indicating at least and at most elements, each separated by a
- single comma (",") and optional whitespace (OWS, Section 1.2.2).
-
- Thus,
-
- 1#element => element *( OWS "," OWS element )
-
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 7]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- and:
-
- #element => [ 1#element ]
-
- and for n >= 1 and m > 1:
-
- #element => element *( OWS "," OWS element )
-
- For compatibility with legacy list rules, recipients SHOULD accept
- empty list elements. In other words, consumers would follow the list
- productions:
-
- #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]
-
- 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )
-
- Note that empty elements do not contribute to the count of elements
- present, though.
-
- For example, given these ABNF productions:
-
- example-list = 1#example-list-elmt
- example-list-elmt = token ; see Section 1.2.2
-
- Then these are valid values for example-list (not including the
- double quotes, which are present for delimitation only):
-
- "foo,bar"
- " foo ,bar,"
- " foo , ,bar,charlie "
- "foo ,bar, charlie "
-
- But these values would be invalid, as at least one non-empty element
- is required:
-
- ""
- ","
- ", ,"
-
- Appendix C shows the collected ABNF, with the list rules expanded as
- explained above.
-
-1.2.2. Basic Rules
-
- HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
- protocol elements other than the message-body (see Appendix A for
- tolerant applications).
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 8]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- This specification uses three rules to denote the use of linear
- whitespace: OWS (optional whitespace), RWS (required whitespace), and
- BWS ("bad" whitespace).
-
- The OWS rule is used where zero or more linear whitespace characters
- might appear. OWS SHOULD either not be produced or be produced as a
- single SP character. Multiple OWS characters that occur within
- field-content SHOULD be replaced with a single SP before interpreting
- the field value or forwarding the message downstream.
-
- RWS is used when at least one linear whitespace character is required
- to separate field tokens. RWS SHOULD be produced as a single SP
- character. Multiple RWS characters that occur within field-content
- SHOULD be replaced with a single SP before interpreting the field
- value or forwarding the message downstream.
-
- BWS is used where the grammar allows optional whitespace for
- historical reasons but senders SHOULD NOT produce it in messages.
- HTTP/1.1 recipients MUST accept such bad optional whitespace and
- remove it before interpreting the field value or forwarding the
- message downstream.
-
-
- OWS = *( [ obs-fold ] WSP )
- ; "optional" whitespace
- RWS = 1*( [ obs-fold ] WSP )
- ; "required" whitespace
- BWS = OWS
- ; "bad" whitespace
- obs-fold = CRLF
- ; see Section 3.2
-
- Many HTTP/1.1 header field values consist of words (token or quoted-
- string) separated by whitespace or special characters. These special
- characters MUST be in a quoted string to be used within a parameter
- value (as defined in Section 6.2).
-
- word = token / quoted-string
-
- token = 1*tchar
-
- tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
- / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
- / DIGIT / ALPHA
- ; any VCHAR, except special
-
- special = "(" / ")" / "<" / ">" / "@" / ","
- / ";" / ":" / "\" / DQUOTE / "/" / "["
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 9]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- / "]" / "?" / "=" / "{" / "}"
-
- A string of text is parsed as a single word if it is quoted using
- double-quote marks.
-
- quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
- qdtext = OWS / %x21 / %x23-5B / %x5D-7E / obs-text
- ; OWS / / obs-text
- obs-text = %x80-FF
-
- The backslash character ("\") can be used as a single-character
- quoting mechanism within quoted-string constructs:
-
- quoted-pair = "\" ( WSP / VCHAR / obs-text )
-
- Producers SHOULD NOT escape characters that do not require escaping
- (i.e., other than DQUOTE and the backslash character).
-
-1.2.3. ABNF Rules defined in other Parts of the Specification
-
- The ABNF rules below are defined in other parts:
-
- request-header =
- response-header =
-
-
- MIME-Version =
-
-
- Cache-Control =
- Pragma =
- Warning =
-
-2. HTTP-related architecture
-
- HTTP was created for the World Wide Web architecture and has evolved
- over time to support the scalability needs of a worldwide hypertext
- system. Much of that architecture is reflected in the terminology
- and syntax productions used to define HTTP.
-
-2.1. Client/Server Messaging
-
- HTTP is a stateless request/response protocol that operates by
- exchanging messages across a reliable transport or session-layer
- connection. An HTTP "client" is a program that establishes a
- connection to a server for the purpose of sending one or more HTTP
- requests. An HTTP "server" is a program that accepts connections in
- order to service HTTP requests by sending HTTP responses.
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 10]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- Note that the terms client and server refer only to the roles that
- these programs perform for a particular connection. The same program
- might act as a client on some connections and a server on others. We
- use the term "user agent" to refer to the program that initiates a
- request, such as a WWW browser, editor, or spider (web-traversing
- robot), and the term "origin server" to refer to the program that can
- originate authoritative responses to a request. For general
- requirements, we use the term "sender" to refer to whichever
- component sent a given message and the term "recipient" to refer to
- any component that receives the message.
-
- Most HTTP communication consists of a retrieval request (GET) for a
- representation of some resource identified by a URI. In the simplest
- case, this might be accomplished via a single bidirectional
- connection (===) between the user agent (UA) and the origin server
- (O).
-
- request >
- UA ======================================= O
- < response
-
- A client sends an HTTP request to the server in the form of a request
- message (Section 4), beginning with a method, URI, and protocol
- version, followed by MIME-like header fields containing request
- modifiers, client information, and payload metadata, an empty line to
- indicate the end of the header section, and finally the payload body
- (if any).
-
- A server responds to the client's request by sending an HTTP response
- message (Section 5), beginning with a status line that includes the
- protocol version, a success or error code, and textual reason phrase,
- followed by MIME-like header fields containing server information,
- resource metadata, and payload metadata, an empty line to indicate
- the end of the header section, and finally the payload body (if any).
-
- The following example illustrates a typical message exchange for a
- GET request on the URI "http://www.example.com/hello.txt":
-
- client request:
-
- GET /hello.txt HTTP/1.1
- User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
- Host: www.example.com
- Accept: */*
-
-
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 11]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- server response:
-
- HTTP/1.1 200 OK
- Date: Mon, 27 Jul 2009 12:28:53 GMT
- Server: Apache
- Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
- ETag: "34aa387-d-1568eb00"
- Accept-Ranges: bytes
- Content-Length: 14
- Vary: Accept-Encoding
- Content-Type: text/plain
-
- Hello World!
-
-2.2. Intermediaries
-
- A more complicated situation occurs when one or more intermediaries
- are present in the request/response chain. There are three common
- forms of intermediary: proxy, gateway, and tunnel. In some cases, a
- single intermediary might act as an origin server, proxy, gateway, or
- tunnel, switching behavior based on the nature of each request.
-
- > > > >
- UA =========== A =========== B =========== C =========== O
- < < < <
-
- The figure above shows three intermediaries (A, B, and C) between the
- user agent and origin server. A request or response message that
- travels the whole chain will pass through four separate connections.
- Some HTTP communication options might apply only to the connection
- with the nearest, non-tunnel neighbor, only to the end-points of the
- chain, or to all connections along the chain. Although the diagram
- is linear, each participant might be engaged in multiple,
- simultaneous communications. For example, B might be receiving
- requests from many clients other than A, and/or forwarding requests
- to servers other than C, at the same time that it is handling A's
- request.
-
- We use the terms "upstream" and "downstream" to describe various
- requirements in relation to the directional flow of a message: all
- messages flow from upstream to downstream. Likewise, we use the
- terms "inbound" and "outbound" to refer to directions in relation to
- the request path: "inbound" means toward the origin server and
- "outbound" means toward the user agent.
-
- A "proxy" is a message forwarding agent that is selected by the
- client, usually via local configuration rules, to receive requests
- for some type(s) of absolute URI and attempt to satisfy those
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 12]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- requests via translation through the HTTP interface. Some
- translations are minimal, such as for proxy requests for "http" URIs,
- whereas other requests might require translation to and from entirely
- different application-layer protocols. Proxies are often used to
- group an organization's HTTP requests through a common intermediary
- for the sake of security, annotation services, or shared caching.
-
- A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts
- as a layer above some other server(s) and translates the received
- requests to the underlying server's protocol. Gateways are often
- used for load balancing or partitioning HTTP services across multiple
- machines. Unlike a proxy, a gateway receives requests as if it were
- the origin server for the target resource; the requesting client will
- not be aware that it is communicating with a gateway. A gateway
- communicates with the client as if the gateway is the origin server
- and thus is subject to all of the requirements on origin servers for
- that connection. A gateway communicates with inbound servers using
- any protocol it desires, including private extensions to HTTP that
- are outside the scope of this specification.
-
- A "tunnel" acts as a blind relay between two connections without
- changing the messages. Once active, a tunnel is not considered a
- party to the HTTP communication, though the tunnel might have been
- initiated by an HTTP request. A tunnel ceases to exist when both
- ends of the relayed connection are closed. Tunnels are used to
- extend a virtual connection through an intermediary, such as when
- transport-layer security is used to establish private communication
- through a shared firewall proxy.
-
-2.3. Caches
-
- A "cache" is a local store of previous response messages and the
- subsystem that controls its message storage, retrieval, and deletion.
- A cache stores cacheable responses in order to reduce the response
- time and network bandwidth consumption on future, equivalent
- requests. Any client or server MAY employ a cache, though a cache
- cannot be used by a server while it is acting as a tunnel.
-
- The effect of a cache is that the request/response chain is shortened
- if one of the participants along the chain has a cached response
- applicable to that request. The following illustrates the resulting
- chain if B has a cached copy of an earlier response from O (via C)
- for a request which has not been cached by UA or A.
-
- > >
- UA =========== A =========== B - - - - - - C - - - - - - O
- < <
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 13]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- A response is "cacheable" if a cache is allowed to store a copy of
- the response message for use in answering subsequent requests. Even
- when a response is cacheable, there might be additional constraints
- placed by the client or by the origin server on when that cached
- response can be used for a particular request. HTTP requirements for
- cache behavior and cacheable responses are defined in Section 2 of
- [Part6].
-
- There are a wide variety of architectures and configurations of
- caches and proxies deployed across the World Wide Web and inside
- large organizations. These systems include national hierarchies of
- proxy caches to save transoceanic bandwidth, systems that broadcast
- or multicast cache entries, organizations that distribute subsets of
- cached data via optical media, and so on.
-
-2.4. Transport Independence
-
- HTTP systems are used in a wide variety of environments, from
- corporate intranets with high-bandwidth links to long-distance
- communication over low-power radio links and intermittent
- connectivity.
-
- HTTP communication usually takes place over TCP/IP connections. The
- default port is TCP 80
- (), but other ports can
- be used. This does not preclude HTTP from being implemented on top
- of any other protocol on the Internet, or on other networks. HTTP
- only presumes a reliable transport; any protocol that provides such
- guarantees can be used; the mapping of the HTTP/1.1 request and
- response structures onto the transport data units of the protocol in
- question is outside the scope of this specification.
-
- In HTTP/1.0, most implementations used a new connection for each
- request/response exchange. In HTTP/1.1, a connection might be used
- for one or more request/response exchanges, although connections
- might be closed for a variety of reasons (see Section 7.1).
-
-2.5. HTTP Version
-
- HTTP uses a "." numbering scheme to indicate versions
- of the protocol. The protocol versioning policy is intended to allow
- the sender to indicate the format of a message and its capacity for
- understanding further HTTP communication, rather than the features
- obtained via that communication. No change is made to the version
- number for the addition of message components which do not affect
- communication behavior or which only add to extensible field values.
- The number is incremented when the changes made to the
- protocol add features which do not change the general message parsing
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 14]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- algorithm, but which might add to the message semantics and imply
- additional capabilities of the sender. The number is
- incremented when the format of a message within the protocol is
- changed. See [RFC2145] for a fuller explanation.
-
- The version of an HTTP message is indicated by an HTTP-Version field
- in the first line of the message. HTTP-Version is case-sensitive.
-
- HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT
- HTTP-Prot-Name = %x48.54.54.50 ; "HTTP", case-sensitive
-
- Note that the major and minor numbers MUST be treated as separate
- integers and that each MAY be incremented higher than a single digit.
- Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
- lower than HTTP/12.3. Leading zeros MUST be ignored by recipients
- and MUST NOT be sent.
-
- An application that sends a request or response message that includes
- HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant
- with this specification. Applications that are at least
- conditionally compliant with this specification SHOULD use an HTTP-
- Version of "HTTP/1.1" in their messages, and MUST do so for any
- message that is not compatible with HTTP/1.0. For more details on
- when to send specific HTTP-Version values, see [RFC2145].
-
- The HTTP version of an application is the highest HTTP version for
- which the application is at least conditionally compliant.
-
- Proxy and gateway applications need to be careful when forwarding
- messages in protocol versions different from that of the application.
- Since the protocol version indicates the protocol capability of the
- sender, a proxy/gateway MUST NOT send a message with a version
- indicator which is greater than its actual version. If a higher
- version request is received, the proxy/gateway MUST either downgrade
- the request version, or respond with an error, or switch to tunnel
- behavior.
-
- Due to interoperability problems with HTTP/1.0 proxies discovered
- since the publication of [RFC2068], caching proxies MUST, gateways
- MAY, and tunnels MUST NOT upgrade the request to the highest version
- they support. The proxy/gateway's response to that request MUST be
- in the same major version as the request.
-
- Note: Converting between versions of HTTP might involve
- modification of header fields required or forbidden by the
- versions involved.
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 15]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
-2.6. Uniform Resource Identifiers
-
- Uniform Resource Identifiers (URIs) [RFC3986] are used throughout
- HTTP as the means for identifying resources. URI references are used
- to target requests, indicate redirects, and define relationships.
- HTTP does not limit what a resource might be; it merely defines an
- interface that can be used to interact with a resource via HTTP.
- More information on the scope of URIs and resources can be found in
- [RFC3986].
-
- This specification adopts the definitions of "URI-reference",
- "absolute-URI", "relative-part", "port", "host", "path-abempty",
- "path-absolute", "query", and "authority" from [RFC3986]. In
- addition, we define a partial-URI rule for protocol elements that
- allow a relative URI without a fragment.
-
- URI-reference =
- absolute-URI =
- relative-part =
- authority =
- path-abempty =
- path-absolute =
- port =
- query =
- uri-host =
-
- partial-URI = relative-part [ "?" query ]
-
- Each protocol element in HTTP that allows a URI reference will
- indicate in its ABNF production whether the element allows only a URI
- in absolute form (absolute-URI), any relative reference (relative-
- ref), or some other subset of the URI-reference grammar. Unless
- otherwise indicated, URI references are parsed relative to the
- request target (the default base URI for both the request and its
- corresponding response).
-
-2.6.1. http URI scheme
-
- The "http" URI scheme is hereby defined for the purpose of minting
- identifiers according to their association with the hierarchical
- namespace governed by a potential HTTP origin server listening for
- TCP connections on a given port. The HTTP server is identified via
- the generic syntax's authority component, which includes a host
- identifier and optional TCP port, and the remainder of the URI is
- considered to be identifying data corresponding to a resource for
- which that server might provide an HTTP interface.
-
- http-URI = "http:" "//" authority path-abempty [ "?" query ]
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 16]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- The host identifier within an authority component is defined in
- [RFC3986], Section 3.2.2. If host is provided as an IP literal or
- IPv4 address, then the HTTP server is any listener on the indicated
- TCP port at that IP address. If host is a registered name, then that
- name is considered an indirect identifier and the recipient might use
- a name resolution service, such as DNS, to find the address of a
- listener for that host. The host MUST NOT be empty; if an "http" URI
- is received with an empty host, then it MUST be rejected as invalid.
- If the port subcomponent is empty or not given, then TCP port 80 is
- assumed (the default reserved port for WWW services).
-
- Regardless of the form of host identifier, access to that host is not
- implied by the mere presence of its name or address. The host might
- or might not exist and, even when it does exist, might or might not
- be running an HTTP server or listening to the indicated port. The
- "http" URI scheme makes use of the delegated nature of Internet names
- and addresses to establish a naming authority (whatever entity has
- the ability to place an HTTP server at that Internet name or address)
- and allows that authority to determine which names are valid and how
- they might be used.
-
- When an "http" URI is used within a context that calls for access to
- the indicated resource, a client MAY attempt access by resolving the
- host to an IP address, establishing a TCP connection to that address
- on the indicated port, and sending an HTTP request message to the
- server containing the URI's identifying data as described in
- Section 4. If the server responds to that request with a non-interim
- HTTP response message, as described in Section 5, then that response
- is considered an authoritative answer to the client's request.
-
- Although HTTP is independent of the transport protocol, the "http"
- scheme is specific to TCP-based services because the name delegation
- process depends on TCP for establishing authority. An HTTP service
- based on some other underlying connection protocol would presumably
- be identified using a different URI scheme, just as the "https"
- scheme (below) is used for servers that require an SSL/TLS transport
- layer on a connection. Other protocols might also be used to provide
- access to "http" identified resources --- it is only the
- authoritative interface used for mapping the namespace that is
- specific to TCP.
-
- The URI generic syntax for authority also includes a deprecated
- userinfo subcomponent ([RFC3986], Section 3.2.1) for including user
- authentication information in the URI. The userinfo subcomponent
- (and its "@" delimiter) MUST NOT be used in an "http" URI. URI
- reference recipients SHOULD parse for the existence of userinfo and
- treat its presence as an error, likely indicating that the deprecated
- subcomponent is being used to obscure the authority for the sake of
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 17]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- phishing attacks.
-
-2.6.2. https URI scheme
-
- The "https" URI scheme is hereby defined for the purpose of minting
- identifiers according to their association with the hierarchical
- namespace governed by a potential HTTP origin server listening for
- SSL/TLS-secured connections on a given TCP port.
-
- All of the requirements listed above for the "http" scheme are also
- requirements for the "https" scheme, except that a default TCP port
- of 443 is assumed if the port subcomponent is empty or not given, and
- the TCP connection MUST be secured for privacy through the use of
- strong encryption prior to sending the first HTTP request.
-
- https-URI = "https:" "//" authority path-abempty [ "?" query ]
-
- Unlike the "http" scheme, responses to "https" identified requests
- are never "public" and thus are ineligible for shared caching. Their
- default is "private" and might be further constrained via use of the
- Cache-Control header field.
-
- Resources made available via the "https" scheme have no shared
- identity with the "http" scheme even if their resource identifiers
- only differ by the single "s" in the scheme name. They are different
- services governed by different authorities. However, some extensions
- to HTTP that apply to entire host domains, such as the Cookie
- protocol, do allow one service to effect communication with the other
- services based on host domain matching.
-
- The process for authoritative access to an "https" identified
- resource is defined in [RFC2818].
-
-2.6.3. http and https URI Normalization and Comparison
-
- Since the "http" and "https" schemes conform to the URI generic
- syntax, such URIs are normalized and compared according to the
- algorithm defined in [RFC3986], Section 6, using the defaults
- described above for each scheme.
-
- If the port is equal to the default port for a scheme, the normal
- form is to elide the port subcomponent. Likewise, an empty path
- component is equivalent to an absolute path of "/", so the normal
- form is to provide a path of "/" instead. The scheme and host are
- case-insensitive and normally provided in lowercase; all other
- components are compared in a case-sensitive manner. Characters other
- than those in the "reserved" set are equivalent to their percent-
- encoded octets (see [RFC3986], Section 2.1): the normal form is to
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 18]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- not encode them.
-
- For example, the following three URIs are equivalent:
-
- http://example.com:80/~smith/home.html
- http://EXAMPLE.com/%7Esmith/home.html
- http://EXAMPLE.com:/%7esmith/home.html
-
- [[TODO-not-here: This paragraph does not belong here. --roy]] If
- path-abempty is the empty string (i.e., there is no slash "/" path
- separator following the authority), then the "http" URI MUST be given
- as "/" when used as a request-target (Section 4.1.2). If a proxy
- receives a host name which is not a fully qualified domain name, it
- MAY add its domain to the host name it received. If a proxy receives
- a fully qualified domain name, the proxy MUST NOT change the host
- name.
-
-3. HTTP Message
-
- All HTTP/1.1 messages consist of a start-line followed by a sequence
- of characters in a format similar to the Internet Message Format
- [RFC5322]: zero or more header fields (collectively referred to as
- the "headers" or the "header section"), an empty line indicating the
- end of the header section, and an optional message-body.
-
- An HTTP message can either be a request from client to server or a
- response from server to client. Syntactically, the two types of
- message differ only in the start-line, which is either a Request-Line
- (for requests) or a Status-Line (for responses), and in the algorithm
- for determining the length of the message-body (Section 3.3). In
- theory, a client could receive requests and a server could receive
- responses, distinguishing them by their different start-line formats,
- but in practice servers are implemented to only expect a request (a
- response is interpreted as an unknown or invalid request method) and
- clients are implemented to only expect a response.
-
- HTTP-message = start-line
- *( header-field CRLF )
- CRLF
- [ message-body ]
- start-line = Request-Line / Status-Line
-
- Whitespace (WSP) MUST NOT be sent between the start-line and the
- first header field. The presence of whitespace might be an attempt
- to trick a noncompliant implementation of HTTP into ignoring that
- field or processing the next line as a new request, either of which
- might result in security issues when implementations within the
- request chain interpret the same message differently. HTTP/1.1
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 19]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- servers MUST reject such a message with a 400 (Bad Request) response.
-
-3.1. Message Parsing Robustness
-
- In the interest of robustness, servers SHOULD ignore at least one
- empty line received where a Request-Line is expected. In other
- words, if the server is reading the protocol stream at the beginning
- of a message and receives a CRLF first, it SHOULD ignore the CRLF.
-
- Some old HTTP/1.0 client implementations generate an extra CRLF after
- a POST request as a lame workaround for some early server
- applications that failed to read message-body content that was not
- terminated by a line-ending. An HTTP/1.1 client MUST NOT preface or
- follow a request with an extra CRLF. If terminating the request
- message-body with a line-ending is desired, then the client MUST
- include the terminating CRLF octets as part of the message-body
- length.
-
- The normal procedure for parsing an HTTP message is to read the
- start-line into a structure, read each header field into a hash table
- by field name until the empty line, and then use the parsed data to
- determine if a message-body is expected. If a message-body has been
- indicated, then it is read as a stream until an amount of octets
- equal to the message-body length is read or the connection is closed.
- Care must be taken to parse an HTTP message as a sequence of octets
- in an encoding that is a superset of US-ASCII. Attempting to parse
- HTTP as a stream of Unicode characters in a character encoding like
- UTF-16 might introduce security flaws due to the differing ways that
- such parsers interpret invalid characters.
-
- HTTP allows the set of defined header fields to be extended without
- changing the protocol version (see Section 10.1). However, such
- fields might not be recognized by a downstream recipient and might be
- stripped by non-transparent intermediaries. Unrecognized header
- fields MUST be forwarded by transparent proxies and SHOULD be ignored
- by a recipient.
-
-3.2. Header Fields
-
- Each HTTP header field consists of a case-insensitive field name
- followed by a colon (":"), optional whitespace, and the field value.
-
- header-field = field-name ":" OWS [ field-value ] OWS
- field-name = token
- field-value = *( field-content / OWS )
- field-content = *( WSP / VCHAR / obs-text )
-
- No whitespace is allowed between the header field name and colon.
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 20]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- For security reasons, any request message received containing such
- whitespace MUST be rejected with a response code of 400 (Bad
- Request). A proxy MUST remove any such whitespace from a response
- message before forwarding the message downstream.
-
- A field value MAY be preceded by optional whitespace (OWS); a single
- SP is preferred. The field value does not include any leading or
- trailing white space: OWS occurring before the first non-whitespace
- character of the field value or after the last non-whitespace
- character of the field value is ignored and SHOULD be removed before
- further processing (as this does not change the meaning of the header
- field).
-
- The order in which header fields with differing field names are
- received is not significant. However, it is "good practice" to send
- header fields that contain control data first, such as Host on
- requests and Date on responses, so that implementations can decide
- when not to handle a message as early as possible. A server MUST
- wait until the entire header section is received before interpreting
- a request message, since later header fields might include
- conditionals, authentication credentials, or deliberately misleading
- duplicate header fields that would impact request processing.
-
- Multiple header fields with the same field name MUST NOT be sent in a
- message unless the entire field value for that header field is
- defined as a comma-separated list [i.e., #(values)]. Multiple header
- fields with the same field name can be combined into one "field-name:
- field-value" pair, without changing the semantics of the message, by
- appending each subsequent field value to the combined field value in
- order, separated by a comma. The order in which header fields with
- the same field name are received is therefore significant to the
- interpretation of the combined field value; a proxy MUST NOT change
- the order of these field values when forwarding a message.
-
- Note: The "Set-Cookie" header as implemented in practice (as
- opposed to how it is specified in [RFC2109]) can occur multiple
- times, but does not use the list syntax, and thus cannot be
- combined into a single line. (See Appendix A.2.3 of [Kri2001] for
- details.) Also note that the Set-Cookie2 header specified in
- [RFC2965] does not share this problem.
-
- Historically, HTTP header field values could be extended over
- multiple lines by preceding each extra line with at least one space
- or horizontal tab character (line folding). This specification
- deprecates such line folding except within the message/http media
- type (Section 10.3.1). HTTP/1.1 senders MUST NOT produce messages
- that include line folding (i.e., that contain any field-content that
- matches the obs-fold rule) unless the message is intended for
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 21]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- packaging within the message/http media type. HTTP/1.1 recipients
- SHOULD accept line folding and replace any embedded obs-fold
- whitespace with a single SP prior to interpreting the field value or
- forwarding the message downstream.
-
- Historically, HTTP has allowed field content with text in the ISO-
- 8859-1 [ISO-8859-1] character encoding and supported other character
- sets only through use of [RFC2047] encoding. In practice, most HTTP
- header field values use only a subset of the US-ASCII character
- encoding [USASCII]. Newly defined header fields SHOULD limit their
- field values to US-ASCII characters. Recipients SHOULD treat other
- (obs-text) octets in field content as opaque data.
-
- Comments can be included in some HTTP header fields by surrounding
- the comment text with parentheses. Comments are only allowed in
- fields containing "comment" as part of their field value definition.
-
- comment = "(" *( ctext / quoted-cpair / comment ) ")"
- ctext = OWS / %x21-27 / %x2A-5B / %x5D-7E / obs-text
- ; OWS / / obs-text
-
- The backslash character ("\") can be used as a single-character
- quoting mechanism within comment constructs:
-
- quoted-cpair = "\" ( WSP / VCHAR / obs-text )
-
- Producers SHOULD NOT escape characters that do not require escaping
- (i.e., other than the backslash character "\" and the parentheses "("
- and ")").
-
-3.3. Message Body
-
- The message-body (if any) of an HTTP message is used to carry the
- payload body associated with the request or response.
-
- message-body = *OCTET
-
- The message-body differs from the payload body only when a transfer-
- coding has been applied, as indicated by the Transfer-Encoding header
- field (Section 9.7). When one or more transfer-codings are applied
- to a payload in order to form the message-body, the Transfer-Encoding
- header field MUST contain the list of transfer-codings applied.
- Transfer-Encoding is a property of the message, not of the payload,
- and thus MAY be added or removed by any implementation along the
- request/response chain under the constraints found in Section 6.2.
-
- The rules for when a message-body is allowed in a message differ for
- requests and responses.
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 22]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- The presence of a message-body in a request is signaled by the
- inclusion of a Content-Length or Transfer-Encoding header field in
- the request's header fields, even if the request method does not
- define any use for a message-body. This allows the request message
- framing algorithm to be independent of method semantics.
-
- For response messages, whether or not a message-body is included with
- a message is dependent on both the request method and the response
- status code (Section 5.1.1). Responses to the HEAD request method
- never include a message-body because the associated response header
- fields (e.g., Transfer-Encoding, Content-Length, etc.) only indicate
- what their values would have been if the method had been GET. All
- 1xx (Informational), 204 (No Content), and 304 (Not Modified)
- responses MUST NOT include a message-body. All other responses do
- include a message-body, although the body MAY be of zero length.
-
- The length of the message-body is determined by one of the following
- (in order of precedence):
-
- 1. Any response to a HEAD request and any response with a status
- code of 100-199, 204, or 304 is always terminated by the first
- empty line after the header fields, regardless of the header
- fields present in the message, and thus cannot contain a message-
- body.
-
- 2. If a Transfer-Encoding header field (Section 9.7) is present and
- the "chunked" transfer-coding (Section 6.2) is the final
- encoding, the message-body length is determined by reading and
- decoding the chunked data until the transfer-coding indicates the
- data is complete.
-
- If a Transfer-Encoding header field is present in a response and
- the "chunked" transfer-coding is not the final encoding, the
- message-body length is determined by reading the connection until
- it is closed by the server. If a Transfer-Encoding header field
- is present in a request and the "chunked" transfer-coding is not
- the final encoding, the message-body length cannot be determined
- reliably; the server MUST respond with the 400 (Bad Request)
- status code and then close the connection.
-
- If a message is received with both a Transfer-Encoding header
- field and a Content-Length header field, the Transfer-Encoding
- overrides the Content-Length. Such a message might indicate an
- attempt to perform request or response smuggling (bypass of
- security-related checks on message routing or content) and thus
- ought to be handled as an error. The provided Content-Length
- MUST be removed, prior to forwarding the message downstream, or
- replaced with the real message-body length after the transfer-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 23]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- coding is decoded.
-
- 3. If a message is received without Transfer-Encoding and with
- either multiple Content-Length header fields or a single Content-
- Length header field with an invalid value, then the message
- framing is invalid and MUST be treated as an error to prevent
- request or response smuggling. If this is a request message, the
- server MUST respond with a 400 (Bad Request) status code and then
- close the connection. If this is a response message received by
- a proxy or gateway, the proxy or gateway MUST discard the
- received response, send a 502 (Bad Gateway) status code as its
- downstream response, and then close the connection. If this is a
- response message received by a user-agent, the message-body
- length is determined by reading the connection until it is
- closed; an error SHOULD be indicated to the user.
-
- 4. If a valid Content-Length header field (Section 9.2) is present
- without Transfer-Encoding, its decimal value defines the message-
- body length in octets. If the actual number of octets sent in
- the message is less than the indicated Content-Length, the
- recipient MUST consider the message to be incomplete and treat
- the connection as no longer usable. If the actual number of
- octets sent in the message is more than the indicated Content-
- Length, the recipient MUST only process the message-body up to
- the field value's number of octets; the remainder of the message
- MUST either be discarded or treated as the next message in a
- pipeline. For the sake of robustness, a user-agent MAY attempt
- to detect and correct such an error in message framing if it is
- parsing the response to the last request on on a connection and
- the connection has been closed by the server.
-
- 5. If this is a request message and none of the above are true, then
- the message-body length is zero (no message-body is present).
-
- 6. Otherwise, this is a response message without a declared message-
- body length, so the message-body length is determined by the
- number of octets received prior to the server closing the
- connection.
-
- Since there is no way to distinguish a successfully completed, close-
- delimited message from a partially-received message interrupted by
- network failure, implementations SHOULD use encoding or length-
- delimited messages whenever possible. The close-delimiting feature
- exists primarily for backwards compatibility with HTTP/1.0.
-
- A server MAY reject a request that contains a message-body but not a
- Content-Length by responding with 411 (Length Required).
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 24]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- Unless a transfer-coding other than "chunked" has been applied, a
- client that sends a request containing a message-body SHOULD use a
- valid Content-Length header field if the message-body length is known
- in advance, rather than the "chunked" encoding, since some existing
- services respond to "chunked" with a 411 (Length Required) status
- code even though they understand the chunked encoding. This is
- typically because such services are implemented via a gateway that
- requires a content-length in advance of being called and the server
- is unable or unwilling to buffer the entire request before
- processing.
-
- A client that sends a request containing a message-body MUST include
- a valid Content-Length header field if it does not know the server
- will handle HTTP/1.1 (or later) requests; such knowledge can be in
- the form of specific user configuration or by remembering the version
- of a prior received response.
-
- Request messages that are prematurely terminated, possibly due to a
- cancelled connection or a server-imposed time-out exception, MUST
- result in closure of the connection; sending an HTTP/1.1 error
- response prior to closing the connection is OPTIONAL. Response
- messages that are prematurely terminated, usually by closure of the
- connection prior to receiving the expected number of octets or by
- failure to decode a transfer-encoded message-body, MUST be recorded
- as incomplete. A user agent MUST NOT render an incomplete response
- message-body as if it were complete (i.e., some indication must be
- given to the user that an error occurred). Cache requirements for
- incomplete responses are defined in Section 2.1.1 of [Part6].
-
- A server MUST read the entire request message-body or close the
- connection after sending its response, since otherwise the remaining
- data on a persistent connection would be misinterpreted as the next
- request. Likewise, a client MUST read the entire response message-
- body if it intends to reuse the same connection for a subsequent
- request. Pipelining multiple requests on a connection is described
- in Section 7.1.2.2.
-
-3.4. General Header Fields
-
- There are a few header fields which have general applicability for
- both request and response messages, but which do not apply to the
- payload being transferred. These header fields apply only to the
- message being transmitted.
-
-
-
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 25]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- general-header = Cache-Control ; [Part6], Section 3.2
- / Connection ; Section 9.1
- / Date ; Section 9.3
- / Pragma ; [Part6], Section 3.4
- / Trailer ; Section 9.6
- / Transfer-Encoding ; Section 9.7
- / Upgrade ; Section 9.8
- / Via ; Section 9.9
- / Warning ; [Part6], Section 3.6
- / MIME-Version ; [Part3], Appendix A.1
-
- General-header field names can be extended reliably only in
- combination with a change in the protocol version. However, new or
- experimental header fields might be given the semantics of general
- header fields if all parties in the communication recognize them to
- be general-header fields.
-
-4. Request
-
- A request message from a client to a server includes, within the
- first line of that message, the method to be applied to the resource,
- the identifier of the resource, and the protocol version in use.
-
- Request = Request-Line ; Section 4.1
- *( header-field CRLF ) ; Section 3.2
- CRLF
- [ message-body ] ; Section 3.3
-
-4.1. Request-Line
-
- The Request-Line begins with a method token, followed by the request-
- target and the protocol version, and ending with CRLF. The elements
- are separated by SP characters. No CR or LF is allowed except in the
- final CRLF sequence.
-
- Request-Line = Method SP request-target SP HTTP-Version CRLF
-
-4.1.1. Method
-
- The Method token indicates the method to be performed on the resource
- identified by the request-target. The method is case-sensitive.
-
- Method = token
-
-
-
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 26]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
-4.1.2. request-target
-
- The request-target identifies the resource upon which to apply the
- request.
-
- request-target = "*"
- / absolute-URI
- / ( path-absolute [ "?" query ] )
- / authority
-
- The four options for request-target are dependent on the nature of
- the request.
-
- The asterisk "*" means that the request does not apply to a
- particular resource, but to the server itself, and is only allowed
- when the method used does not necessarily apply to a resource. One
- example would be
-
- OPTIONS * HTTP/1.1
-
- The absolute-URI form is REQUIRED when the request is being made to a
- proxy. The proxy is requested to forward the request or service it
- from a valid cache, and return the response. Note that the proxy MAY
- forward the request on to another proxy or directly to the server
- specified by the absolute-URI. In order to avoid request loops, a
- proxy MUST be able to recognize all of its server names, including
- any aliases, local variations, and the numeric IP address. An
- example Request-Line would be:
-
- GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
-
- To allow for transition to absolute-URIs in all requests in future
- versions of HTTP, all HTTP/1.1 servers MUST accept the absolute-URI
- form in requests, even though HTTP/1.1 clients will only generate
- them in requests to proxies.
-
- The authority form is only used by the CONNECT method (Section 7.9 of
- [Part2]).
-
- The most common form of request-target is that used to identify a
- resource on an origin server or gateway. In this case the absolute
- path of the URI MUST be transmitted (see Section 2.6.1, path-
- absolute) as the request-target, and the network location of the URI
- (authority) MUST be transmitted in a Host header field. For example,
- a client wishing to retrieve the resource above directly from the
- origin server would create a TCP connection to port 80 of the host
- "www.example.org" and send the lines:
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 27]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- GET /pub/WWW/TheProject.html HTTP/1.1
- Host: www.example.org
-
- followed by the remainder of the Request. Note that the absolute
- path cannot be empty; if none is present in the original URI, it MUST
- be given as "/" (the server root).
-
- If a proxy receives a request without any path in the request-target
- and the method specified is capable of supporting the asterisk form
- of request-target, then the last proxy on the request chain MUST
- forward the request with "*" as the final request-target.
-
- For example, the request
-
- OPTIONS http://www.example.org:8001 HTTP/1.1
-
- would be forwarded by the proxy as
-
- OPTIONS * HTTP/1.1
- Host: www.example.org:8001
-
- after connecting to port 8001 of host "www.example.org".
-
- The request-target is transmitted in the format specified in
- Section 2.6.1. If the request-target is percent-encoded ([RFC3986],
- Section 2.1), the origin server MUST decode the request-target in
- order to properly interpret the request. Servers SHOULD respond to
- invalid request-targets with an appropriate status code.
-
- A transparent proxy MUST NOT rewrite the "path-absolute" part of the
- received request-target when forwarding it to the next inbound
- server, except as noted above to replace a null path-absolute with
- "/" or "*".
-
- Note: The "no rewrite" rule prevents the proxy from changing the
- meaning of the request when the origin server is improperly using
- a non-reserved URI character for a reserved purpose. Implementors
- need to be aware that some pre-HTTP/1.1 proxies have been known to
- rewrite the request-target.
-
- HTTP does not place a pre-defined limit on the length of a request-
- target. A server MUST be prepared to receive URIs of unbounded
- length and respond with the 414 (URI Too Long) status code if the
- received request-target would be longer than the server wishes to
- handle (see Section 8.4.15 of [Part2]).
-
- Various ad-hoc limitations on request-target length are found in
- practice. It is RECOMMENDED that all HTTP senders and recipients
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 28]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- support request-target lengths of 8000 or more octets.
-
- Note: Fragments ([RFC3986], Section 3.5) are not part of the
- request-target and thus will not be transmitted in an HTTP
- request.
-
-4.2. The Resource Identified by a Request
-
- The exact resource identified by an Internet request is determined by
- examining both the request-target and the Host header field.
-
- An origin server that does not allow resources to differ by the
- requested host MAY ignore the Host header field value when
- determining the resource identified by an HTTP/1.1 request. (But see
- Appendix B.1.1 for other requirements on Host support in HTTP/1.1.)
-
- An origin server that does differentiate resources based on the host
- requested (sometimes referred to as virtual hosts or vanity host
- names) MUST use the following rules for determining the requested
- resource on an HTTP/1.1 request:
-
- 1. If request-target is an absolute-URI, the host is part of the
- request-target. Any Host header field value in the request MUST
- be ignored.
-
- 2. If the request-target is not an absolute-URI, and the request
- includes a Host header field, the host is determined by the Host
- header field value.
-
- 3. If the host as determined by rule 1 or 2 is not a valid host on
- the server, the response MUST be a 400 (Bad Request) error
- message.
-
- Recipients of an HTTP/1.0 request that lacks a Host header field MAY
- attempt to use heuristics (e.g., examination of the URI path for
- something unique to a particular host) in order to determine what
- exact resource is being requested.
-
-4.3. Effective Request URI
-
- HTTP requests often do not carry the absolute URI ([RFC3986], Section
- 4.3) for the target resource; instead, the URI needs to be inferred
- from the request-target, Host header field, and connection context.
- The result of this process is called the "effective request URI".
- The "target resource" is the resource identified by the effective
- request URI.
-
- If the request-target is an absolute-URI, then the effective request
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 29]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- URI is the request-target.
-
- If the request-target uses the path-absolute (plus optional query)
- syntax or if it is just the asterisk "*", then the effective request
- URI is constructed by concatenating
-
- o the scheme name: "http" if the request was received over an
- insecure TCP connection, or "https" when received over a SSL/
- TLS-secured TCP connection,
-
- o the character sequence "://",
-
- o the authority component, as specified in the Host header
- (Section 9.4) and determined by the rules in Section 4.2,
- [[effrequri-nohost: Do we need to include the handling of missing
- hosts in HTTP/1.0 messages, as described in Section 4.2? -- See
- --jre]] and
-
- o the request-target obtained from the Request-Line, unless the
- request-target is just the asterisk "*".
-
- Otherwise, when request-target uses the authority form, the effective
- Request URI is undefined.
-
- Example 1: the effective request URI for the message
-
- GET /pub/WWW/TheProject.html HTTP/1.1
- Host: www.example.org:8080
-
- (received over an insecure TCP connection) is "http", plus "://",
- plus the authority component "www.example.org:8080", plus the
- request-target "/pub/WWW/TheProject.html", thus
- "http://www.example.org:8080/pub/WWW/TheProject.html".
-
- Example 2: the effective request URI for the message
-
- GET * HTTP/1.1
- Host: www.example.org
-
- (received over an SSL/TLS secured TCP connection) is "https", plus
- "://", plus the authority component "www.example.org", thus
- "https://www.example.org".
-
- Effective request URIs are compared using the rules described in
- Section 2.6.3, except that empty path components MUST NOT be treated
- as equivalent to an absolute path of "/".
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 30]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
-5. Response
-
- After receiving and interpreting a request message, a server responds
- with an HTTP response message.
-
- Response = Status-Line ; Section 5.1
- *( header-field CRLF ) ; Section 3.2
- CRLF
- [ message-body ] ; Section 3.3
-
-5.1. Status-Line
-
- The first line of a Response message is the Status-Line, consisting
- of the protocol version followed by a numeric status code and its
- associated textual phrase, with each element separated by SP
- characters. No CR or LF is allowed except in the final CRLF
- sequence.
-
- Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
-
-5.1.1. Status Code and Reason Phrase
-
- The Status-Code element is a 3-digit integer result code of the
- attempt to understand and satisfy the request. These codes are fully
- defined in Section 8 of [Part2]. The Reason Phrase exists for the
- sole purpose of providing a textual description associated with the
- numeric status code, out of deference to earlier Internet application
- protocols that were more frequently used with interactive text
- clients. A client SHOULD ignore the content of the Reason Phrase.
-
- The first digit of the Status-Code defines the class of response.
- The last two digits do not have any categorization role. There are 5
- values for the first digit:
-
- o 1xx: Informational - Request received, continuing process
-
- o 2xx: Success - The action was successfully received, understood,
- and accepted
-
- o 3xx: Redirection - Further action must be taken in order to
- complete the request
-
- o 4xx: Client Error - The request contains bad syntax or cannot be
- fulfilled
-
- o 5xx: Server Error - The server failed to fulfill an apparently
- valid request
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 31]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- Status-Code = 3DIGIT
- Reason-Phrase = *( WSP / VCHAR / obs-text )
-
-6. Protocol Parameters
-
-6.1. Date/Time Formats: Full Date
-
- HTTP applications have historically allowed three different formats
- for date/time stamps. However, the preferred format is a fixed-
- length subset of that defined by [RFC1123]:
-
- Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123
-
- The other formats are described here only for compatibility with
- obsolete implementations.
-
- Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
- Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
-
- HTTP/1.1 clients and servers that parse a date value MUST accept all
- three formats (for compatibility with HTTP/1.0), though they MUST
- only generate the RFC 1123 format for representing HTTP-date values
- in header fields. See Appendix A for further information.
-
- All HTTP date/time stamps MUST be represented in Greenwich Mean Time
- (GMT), without exception. For the purposes of HTTP, GMT is exactly
- equal to UTC (Coordinated Universal Time). This is indicated in the
- first two formats by the inclusion of "GMT" as the three-letter
- abbreviation for time zone, and MUST be assumed when reading the
- asctime format. HTTP-date is case sensitive and MUST NOT include
- additional whitespace beyond that specifically included as SP in the
- grammar.
-
- HTTP-date = rfc1123-date / obs-date
-
- Preferred format:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 32]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT
-
- day-name = %x4D.6F.6E ; "Mon", case-sensitive
- / %x54.75.65 ; "Tue", case-sensitive
- / %x57.65.64 ; "Wed", case-sensitive
- / %x54.68.75 ; "Thu", case-sensitive
- / %x46.72.69 ; "Fri", case-sensitive
- / %x53.61.74 ; "Sat", case-sensitive
- / %x53.75.6E ; "Sun", case-sensitive
-
- date1 = day SP month SP year
- ; e.g., 02 Jun 1982
-
- day = 2DIGIT
- month = %x4A.61.6E ; "Jan", case-sensitive
- / %x46.65.62 ; "Feb", case-sensitive
- / %x4D.61.72 ; "Mar", case-sensitive
- / %x41.70.72 ; "Apr", case-sensitive
- / %x4D.61.79 ; "May", case-sensitive
- / %x4A.75.6E ; "Jun", case-sensitive
- / %x4A.75.6C ; "Jul", case-sensitive
- / %x41.75.67 ; "Aug", case-sensitive
- / %x53.65.70 ; "Sep", case-sensitive
- / %x4F.63.74 ; "Oct", case-sensitive
- / %x4E.6F.76 ; "Nov", case-sensitive
- / %x44.65.63 ; "Dec", case-sensitive
- year = 4DIGIT
-
- GMT = %x47.4D.54 ; "GMT", case-sensitive
-
- time-of-day = hour ":" minute ":" second
- ; 00:00:00 - 23:59:59
-
- hour = 2DIGIT
- minute = 2DIGIT
- second = 2DIGIT
-
- The semantics of day-name, day, month, year, and time-of-day are the
- same as those defined for the RFC 5322 constructs with the
- corresponding name ([RFC5322], Section 3.3).
-
- Obsolete formats:
-
- obs-date = rfc850-date / asctime-date
-
-
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 33]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
- date2 = day "-" month "-" 2DIGIT
- ; day-month-year (e.g., 02-Jun-82)
-
- day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive
- / %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive
- / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
- / %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive
- / %x46.72.69.64.61.79 ; "Friday", case-sensitive
- / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive
- / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive
-
-
- asctime-date = day-name SP date3 SP time-of-day SP year
- date3 = month SP ( 2DIGIT / ( SP 1DIGIT ))
- ; month day (e.g., Jun 2)
-
- Note: Recipients of date values are encouraged to be robust in
- accepting date values that might have been sent by non-HTTP
- applications, as is sometimes the case when retrieving or posting
- messages via proxies/gateways to SMTP or NNTP.
-
- Note: HTTP requirements for the date/time stamp format apply only
- to their usage within the protocol stream. Clients and servers
- are not required to use these formats for user presentation,
- request logging, etc.
-
-6.2. Transfer Codings
-
- Transfer-coding values are used to indicate an encoding
- transformation that has been, can be, or might need to be applied to
- a payload body in order to ensure "safe transport" through the
- network. This differs from a content coding in that the transfer-
- coding is a property of the message rather than a property of the
- representation that is being transferred.
-
- transfer-coding = "chunked" ; Section 6.2.1
- / "compress" ; Section 6.2.2.1
- / "deflate" ; Section 6.2.2.2
- / "gzip" ; Section 6.2.2.3
- / transfer-extension
- transfer-extension = token *( OWS ";" OWS transfer-parameter )
-
- Parameters are in the form of attribute/value pairs.
-
- transfer-parameter = attribute BWS "=" BWS value
- attribute = token
- value = word
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 34]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- All transfer-coding values are case-insensitive. HTTP/1.1 uses
- transfer-coding values in the TE header field (Section 9.5) and in
- the Transfer-Encoding header field (Section 9.7).
-
- Transfer-codings are analogous to the Content-Transfer-Encoding
- values of MIME, which were designed to enable safe transport of
- binary data over a 7-bit transport service ([RFC2045], Section 6).
- However, safe transport has a different focus for an 8bit-clean
- transfer protocol. In HTTP, the only unsafe characteristic of
- message-bodies is the difficulty in determining the exact message
- body length (Section 3.3), or the desire to encrypt data over a
- shared transport.
-
- A server that receives a request message with a transfer-coding it
- does not understand SHOULD respond with 501 (Not Implemented) and
- then close the connection. A server MUST NOT send transfer-codings
- to an HTTP/1.0 client.
-
-6.2.1. Chunked Transfer Coding
-
- The chunked encoding modifies the body of a message in order to
- transfer it as a series of chunks, each with its own size indicator,
- followed by an OPTIONAL trailer containing header fields. This
- allows dynamically produced content to be transferred along with the
- information necessary for the recipient to verify that it has
- received the full message.
-
- Chunked-Body = *chunk
- last-chunk
- trailer-part
- CRLF
-
- chunk = chunk-size *WSP [ chunk-ext ] CRLF
- chunk-data CRLF
- chunk-size = 1*HEXDIG
- last-chunk = 1*("0") *WSP [ chunk-ext ] CRLF
-
- chunk-ext = *( ";" *WSP chunk-ext-name
- [ "=" chunk-ext-val ] *WSP )
- chunk-ext-name = token
- chunk-ext-val = token / quoted-str-nf
- chunk-data = 1*OCTET ; a sequence of chunk-size octets
- trailer-part = *( header-field CRLF )
-
- quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE
- ; like quoted-string, but disallowing line folding
- qdtext-nf = WSP / %x21 / %x23-5B / %x5D-7E / obs-text
- ; WSP / / obs-text
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 35]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- The chunk-size field is a string of hex digits indicating the size of
- the chunk-data in octets. The chunked encoding is ended by any chunk
- whose size is zero, followed by the trailer, which is terminated by
- an empty line.
-
- The trailer allows the sender to include additional HTTP header
- fields at the end of the message. The Trailer header field can be
- used to indicate which header fields are included in a trailer (see
- Section 9.6).
-
- A server using chunked transfer-coding in a response MUST NOT use the
- trailer for any header fields unless at least one of the following is
- true:
-
- 1. the request included a TE header field that indicates "trailers"
- is acceptable in the transfer-coding of the response, as
- described in Section 9.5; or,
-
- 2. the server is the origin server for the response, the trailer
- fields consist entirely of optional metadata, and the recipient
- could use the message (in a manner acceptable to the origin
- server) without receiving this metadata. In other words, the
- origin server is willing to accept the possibility that the
- trailer fields might be silently discarded along the path to the
- client.
-
- This requirement prevents an interoperability failure when the
- message is being received by an HTTP/1.1 (or later) proxy and
- forwarded to an HTTP/1.0 recipient. It avoids a situation where
- compliance with the protocol would have necessitated a possibly
- infinite buffer on the proxy.
-
- A process for decoding the "chunked" transfer-coding can be
- represented in pseudo-code as:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 36]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- length := 0
- read chunk-size, chunk-ext (if any) and CRLF
- while (chunk-size > 0) {
- read chunk-data and CRLF
- append chunk-data to decoded-body
- length := length + chunk-size
- read chunk-size and CRLF
- }
- read header-field
- while (header-field not empty) {
- append header-field to existing header fields
- read header-field
- }
- Content-Length := length
- Remove "chunked" from Transfer-Encoding
-
- All HTTP/1.1 applications MUST be able to receive and decode the
- "chunked" transfer-coding and MUST ignore chunk-ext extensions they
- do not understand.
-
- Since "chunked" is the only transfer-coding required to be understood
- by HTTP/1.1 recipients, it plays a crucial role in delimiting
- messages on a persistent connection. Whenever a transfer-coding is
- applied to a payload body in a request, the final transfer-coding
- applied MUST be "chunked". If a transfer-coding is applied to a
- response payload body, then either the final transfer-coding applied
- MUST be "chunked" or the message MUST be terminated by closing the
- connection. When the "chunked" transfer-coding is used, it MUST be
- the last transfer-coding applied to form the message-body. The
- "chunked" transfer-coding MUST NOT be applied more than once in a
- message-body.
-
-6.2.2. Compression Codings
-
- The codings defined below can be used to compress the payload of a
- message.
-
- Note: Use of program names for the identification of encoding
- formats is not desirable and is discouraged for future encodings.
- Their use here is representative of historical practice, not good
- design.
-
- Note: For compatibility with previous implementations of HTTP,
- applications SHOULD consider "x-gzip" and "x-compress" to be
- equivalent to "gzip" and "compress" respectively.
-
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 37]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
-6.2.2.1. Compress Coding
-
- The "compress" format is produced by the common UNIX file compression
- program "compress". This format is an adaptive Lempel-Ziv-Welch
- coding (LZW).
-
-6.2.2.2. Deflate Coding
-
- The "deflate" format is defined as the "deflate" compression
- mechanism (described in [RFC1951]) used inside the "zlib" data format
- ([RFC1950]).
-
- Note: Some incorrect implementations send the "deflate" compressed
- data without the zlib wrapper.
-
-6.2.2.3. Gzip Coding
-
- The "gzip" format is produced by the file compression program "gzip"
- (GNU zip), as described in [RFC1952]. This format is a Lempel-Ziv
- coding (LZ77) with a 32 bit CRC.
-
-6.2.3. Transfer Coding Registry
-
- The HTTP Transfer Coding Registry defines the name space for the
- transfer coding names.
-
- Registrations MUST include the following fields:
-
- o Name
-
- o Description
-
- o Pointer to specification text
-
- Names of transfer codings MUST NOT overlap with names of content
- codings (Section 2.2 of [Part3]), unless the encoding transformation
- is identical (as it is the case for the compression codings defined
- in Section 6.2.2).
-
- Values to be added to this name space require a specification (see
- "Specification Required" in Section 4.1 of [RFC5226]), and MUST
- conform to the purpose of transfer coding defined in this section.
-
- The registry itself is maintained at
- .
-
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 38]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
-6.3. Product Tokens
-
- Product tokens are used to allow communicating applications to
- identify themselves by software name and version. Most fields using
- product tokens also allow sub-products which form a significant part
- of the application to be listed, separated by whitespace. By
- convention, the products are listed in order of their significance
- for identifying the application.
-
- product = token ["/" product-version]
- product-version = token
-
- Examples:
-
- User-Agent: CERN-LineMode/2.15 libwww/2.17b3
- Server: Apache/0.8.4
-
- Product tokens SHOULD be short and to the point. They MUST NOT be
- used for advertising or other non-essential information. Although
- any token character MAY appear in a product-version, this token
- SHOULD only be used for a version identifier (i.e., successive
- versions of the same product SHOULD only differ in the product-
- version portion of the product value).
-
-6.4. Quality Values
-
- Both transfer codings (TE request header, Section 9.5) and content
- negotiation (Section 5 of [Part3]) use short "floating point" numbers
- to indicate the relative importance ("weight") of various negotiable
- parameters. A weight is normalized to a real number in the range 0
- through 1, where 0 is the minimum and 1 the maximum value. If a
- parameter has a quality value of 0, then content with this parameter
- is "not acceptable" for the client. HTTP/1.1 applications MUST NOT
- generate more than three digits after the decimal point. User
- configuration of these values SHOULD also be limited in this fashion.
-
- qvalue = ( "0" [ "." 0*3DIGIT ] )
- / ( "1" [ "." 0*3("0") ] )
-
- Note: "Quality values" is a misnomer, since these values merely
- represent relative degradation in desired quality.
-
-7. Connections
-
-7.1. Persistent Connections
-
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 39]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
-7.1.1. Purpose
-
- Prior to persistent connections, a separate TCP connection was
- established to fetch each URL, increasing the load on HTTP servers
- and causing congestion on the Internet. The use of inline images and
- other associated data often requires a client to make multiple
- requests of the same server in a short amount of time. Analysis of
- these performance problems and results from a prototype
- implementation are available [Pad1995] [Spe]. Implementation
- experience and measurements of actual HTTP/1.1 implementations show
- good results [Nie1997]. Alternatives have also been explored, for
- example, T/TCP [Tou1998].
-
- Persistent HTTP connections have a number of advantages:
-
- o By opening and closing fewer TCP connections, CPU time is saved in
- routers and hosts (clients, servers, proxies, gateways, tunnels,
- or caches), and memory used for TCP protocol control blocks can be
- saved in hosts.
-
- o HTTP requests and responses can be pipelined on a connection.
- Pipelining allows a client to make multiple requests without
- waiting for each response, allowing a single TCP connection to be
- used much more efficiently, with much lower elapsed time.
-
- o Network congestion is reduced by reducing the number of packets
- caused by TCP opens, and by allowing TCP sufficient time to
- determine the congestion state of the network.
-
- o Latency on subsequent requests is reduced since there is no time
- spent in TCP's connection opening handshake.
-
- o HTTP can evolve more gracefully, since errors can be reported
- without the penalty of closing the TCP connection. Clients using
- future versions of HTTP might optimistically try a new feature,
- but if communicating with an older server, retry with old
- semantics after an error is reported.
-
- HTTP implementations SHOULD implement persistent connections.
-
-7.1.2. Overall Operation
-
- A significant difference between HTTP/1.1 and earlier versions of
- HTTP is that persistent connections are the default behavior of any
- HTTP connection. That is, unless otherwise indicated, the client
- SHOULD assume that the server will maintain a persistent connection,
- even after error responses from the server.
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 40]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- Persistent connections provide a mechanism by which a client and a
- server can signal the close of a TCP connection. This signaling
- takes place using the Connection header field (Section 9.1). Once a
- close has been signaled, the client MUST NOT send any more requests
- on that connection.
-
-7.1.2.1. Negotiation
-
- An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
- maintain a persistent connection unless a Connection header including
- the connection-token "close" was sent in the request. If the server
- chooses to close the connection immediately after sending the
- response, it SHOULD send a Connection header including the
- connection-token "close".
-
- An HTTP/1.1 client MAY expect a connection to remain open, but would
- decide to keep it open based on whether the response from a server
- contains a Connection header with the connection-token close. In
- case the client does not want to maintain a connection for more than
- that request, it SHOULD send a Connection header including the
- connection-token close.
-
- If either the client or the server sends the close token in the
- Connection header, that request becomes the last one for the
- connection.
-
- Clients and servers SHOULD NOT assume that a persistent connection is
- maintained for HTTP versions less than 1.1 unless it is explicitly
- signaled. See Appendix B.2 for more information on backward
- compatibility with HTTP/1.0 clients.
-
- In order to remain persistent, all messages on the connection MUST
- have a self-defined message length (i.e., one not defined by closure
- of the connection), as described in Section 3.3.
-
-7.1.2.2. Pipelining
-
- A client that supports persistent connections MAY "pipeline" its
- requests (i.e., send multiple requests without waiting for each
- response). A server MUST send its responses to those requests in the
- same order that the requests were received.
-
- Clients which assume persistent connections and pipeline immediately
- after connection establishment SHOULD be prepared to retry their
- connection if the first pipelined attempt fails. If a client does
- such a retry, it MUST NOT pipeline before it knows the connection is
- persistent. Clients MUST also be prepared to resend their requests
- if the server closes the connection before sending all of the
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 41]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- corresponding responses.
-
- Clients SHOULD NOT pipeline requests using non-idempotent methods or
- non-idempotent sequences of methods (see Section 7.1.2 of [Part2]).
- Otherwise, a premature termination of the transport connection could
- lead to indeterminate results. A client wishing to send a non-
- idempotent request SHOULD wait to send that request until it has
- received the response status line for the previous request.
-
-7.1.3. Proxy Servers
-
- It is especially important that proxies correctly implement the
- properties of the Connection header field as specified in
- Section 9.1.
-
- The proxy server MUST signal persistent connections separately with
- its clients and the origin servers (or other proxy servers) that it
- connects to. Each persistent connection applies to only one
- transport link.
-
- A proxy server MUST NOT establish a HTTP/1.1 persistent connection
- with an HTTP/1.0 client (but see Section 19.7.1 of [RFC2068] for
- information and discussion of the problems with the Keep-Alive header
- implemented by many HTTP/1.0 clients).
-
-7.1.3.1. End-to-end and Hop-by-hop Headers
-
- For the purpose of defining the behavior of caches and non-caching
- proxies, we divide HTTP headers into two categories:
-
- o End-to-end headers, which are transmitted to the ultimate
- recipient of a request or response. End-to-end headers in
- responses MUST be stored as part of a cache entry and MUST be
- transmitted in any response formed from a cache entry.
-
- o Hop-by-hop headers, which are meaningful only for a single
- transport-level connection, and are not stored by caches or
- forwarded by proxies.
-
- The following HTTP/1.1 headers are hop-by-hop headers:
-
- o Connection
-
- o Keep-Alive
-
- o Proxy-Authenticate
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 42]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- o Proxy-Authorization
-
- o TE
-
- o Trailer
-
- o Transfer-Encoding
-
- o Upgrade
-
- All other headers defined by HTTP/1.1 are end-to-end headers.
-
- Other hop-by-hop headers MUST be listed in a Connection header
- (Section 9.1).
-
-7.1.3.2. Non-modifiable Headers
-
- Some features of HTTP/1.1, such as Digest Authentication, depend on
- the value of certain end-to-end headers. A transparent proxy SHOULD
- NOT modify an end-to-end header unless the definition of that header
- requires or specifically allows that.
-
- A transparent proxy MUST NOT modify any of the following fields in a
- request or response, and it MUST NOT add any of these fields if not
- already present:
-
- o Content-Location
-
- o Content-MD5
-
- o ETag
-
- o Last-Modified
-
- A transparent proxy MUST NOT modify any of the following fields in a
- response:
-
- o Expires
-
- but it MAY add any of these fields if not already present. If an
- Expires header is added, it MUST be given a field-value identical to
- that of the Date header in that response.
-
- A proxy MUST NOT modify or add any of the following fields in a
- message that contains the no-transform cache-control directive, or in
- any request:
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 43]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- o Content-Encoding
-
- o Content-Range
-
- o Content-Type
-
- A non-transparent proxy MAY modify or add these fields to a message
- that does not include no-transform, but if it does so, it MUST add a
- Warning 214 (Transformation applied) if one does not already appear
- in the message (see Section 3.6 of [Part6]).
-
- Warning: Unnecessary modification of end-to-end headers might
- cause authentication failures if stronger authentication
- mechanisms are introduced in later versions of HTTP. Such
- authentication mechanisms MAY rely on the values of header fields
- not listed here.
-
- A transparent proxy MUST preserve the message payload ([Part3]),
- though it MAY change the message-body through application or removal
- of a transfer-coding (Section 6.2).
-
-7.1.4. Practical Considerations
-
- Servers will usually have some time-out value beyond which they will
- no longer maintain an inactive connection. Proxy servers might make
- this a higher value since it is likely that the client will be making
- more connections through the same server. The use of persistent
- connections places no requirements on the length (or existence) of
- this time-out for either the client or the server.
-
- When a client or server wishes to time-out it SHOULD issue a graceful
- close on the transport connection. Clients and servers SHOULD both
- constantly watch for the other side of the transport close, and
- respond to it as appropriate. If a client or server does not detect
- the other side's close promptly it could cause unnecessary resource
- drain on the network.
-
- A client, server, or proxy MAY close the transport connection at any
- time. For example, a client might have started to send a new request
- at the same time that the server has decided to close the "idle"
- connection. From the server's point of view, the connection is being
- closed while it was idle, but from the client's point of view, a
- request is in progress.
-
- This means that clients, servers, and proxies MUST be able to recover
- from asynchronous close events. Client software SHOULD reopen the
- transport connection and retransmit the aborted sequence of requests
- without user interaction so long as the request sequence is
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 44]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- idempotent (see Section 7.1.2 of [Part2]). Non-idempotent methods or
- sequences MUST NOT be automatically retried, although user agents MAY
- offer a human operator the choice of retrying the request(s).
- Confirmation by user-agent software with semantic understanding of
- the application MAY substitute for user confirmation. The automatic
- retry SHOULD NOT be repeated if the second sequence of requests
- fails.
-
- Servers SHOULD always respond to at least one request per connection,
- if at all possible. Servers SHOULD NOT close a connection in the
- middle of transmitting a response, unless a network or client failure
- is suspected.
-
- Clients (including proxies) SHOULD limit the number of simultaneous
- connections that they maintain to a given server (including proxies).
-
- Previous revisions of HTTP gave a specific number of connections as a
- ceiling, but this was found to be impractical for many applications.
- As a result, this specification does not mandate a particular maximum
- number of connections, but instead encourages clients to be
- conservative when opening multiple connections.
-
- In particular, while using multiple connections avoids the "head-of-
- line blocking" problem (whereby a request that takes significant
- server-side processing and/or has a large payload can block
- subsequent requests on the same connection), each connection used
- consumes server resources (sometimes significantly), and furthermore
- using multiple connections can cause undesirable side effects in
- congested networks.
-
- Note that servers might reject traffic that they deem abusive,
- including an excessive number of connections from a client.
-
-7.2. Message Transmission Requirements
-
-7.2.1. Persistent Connections and Flow Control
-
- HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's
- flow control mechanisms to resolve temporary overloads, rather than
- terminating connections with the expectation that clients will retry.
- The latter technique can exacerbate network congestion.
-
-7.2.2. Monitoring Connections for Error Status Messages
-
- An HTTP/1.1 (or later) client sending a message-body SHOULD monitor
- the network connection for an error status code while it is
- transmitting the request. If the client sees an error status code,
- it SHOULD immediately cease transmitting the body. If the body is
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 45]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- being sent using a "chunked" encoding (Section 6.2), a zero length
- chunk and empty trailer MAY be used to prematurely mark the end of
- the message. If the body was preceded by a Content-Length header,
- the client MUST close the connection.
-
-7.2.3. Use of the 100 (Continue) Status
-
- The purpose of the 100 (Continue) status code (see Section 8.1.1 of
- [Part2]) is to allow a client that is sending a request message with
- a request body to determine if the origin server is willing to accept
- the request (based on the request headers) before the client sends
- the request body. In some cases, it might either be inappropriate or
- highly inefficient for the client to send the body if the server will
- reject the message without looking at the body.
-
- Requirements for HTTP/1.1 clients:
-
- o If a client will wait for a 100 (Continue) response before sending
- the request body, it MUST send an Expect request-header field
- (Section 9.2 of [Part2]) with the "100-continue" expectation.
-
- o A client MUST NOT send an Expect request-header field (Section 9.2
- of [Part2]) with the "100-continue" expectation if it does not
- intend to send a request body.
-
- Because of the presence of older implementations, the protocol allows
- ambiguous situations in which a client might send "Expect: 100-
- continue" without receiving either a 417 (Expectation Failed) or a
- 100 (Continue) status code. Therefore, when a client sends this
- header field to an origin server (possibly via a proxy) from which it
- has never seen a 100 (Continue) status code, the client SHOULD NOT
- wait for an indefinite period before sending the request body.
-
- Requirements for HTTP/1.1 origin servers:
-
- o Upon receiving a request which includes an Expect request-header
- field with the "100-continue" expectation, an origin server MUST
- either respond with 100 (Continue) status code and continue to
- read from the input stream, or respond with a final status code.
- The origin server MUST NOT wait for the request body before
- sending the 100 (Continue) response. If it responds with a final
- status code, it MAY close the transport connection or it MAY
- continue to read and discard the rest of the request. It MUST NOT
- perform the requested method if it returns a final status code.
-
- o An origin server SHOULD NOT send a 100 (Continue) response if the
- request message does not include an Expect request-header field
- with the "100-continue" expectation, and MUST NOT send a 100
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 46]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- (Continue) response if such a request comes from an HTTP/1.0 (or
- earlier) client. There is an exception to this rule: for
- compatibility with [RFC2068], a server MAY send a 100 (Continue)
- status code in response to an HTTP/1.1 PUT or POST request that
- does not include an Expect request-header field with the "100-
- continue" expectation. This exception, the purpose of which is to
- minimize any client processing delays associated with an
- undeclared wait for 100 (Continue) status code, applies only to
- HTTP/1.1 requests, and not to requests with any other HTTP-version
- value.
-
- o An origin server MAY omit a 100 (Continue) response if it has
- already received some or all of the request body for the
- corresponding request.
-
- o An origin server that sends a 100 (Continue) response MUST
- ultimately send a final status code, once the request body is
- received and processed, unless it terminates the transport
- connection prematurely.
-
- o If an origin server receives a request that does not include an
- Expect request-header field with the "100-continue" expectation,
- the request includes a request body, and the server responds with
- a final status code before reading the entire request body from
- the transport connection, then the server SHOULD NOT close the
- transport connection until it has read the entire request, or
- until the client closes the connection. Otherwise, the client
- might not reliably receive the response message. However, this
- requirement is not be construed as preventing a server from
- defending itself against denial-of-service attacks, or from badly
- broken client implementations.
-
- Requirements for HTTP/1.1 proxies:
-
- o If a proxy receives a request that includes an Expect request-
- header field with the "100-continue" expectation, and the proxy
- either knows that the next-hop server complies with HTTP/1.1 or
- higher, or does not know the HTTP version of the next-hop server,
- it MUST forward the request, including the Expect header field.
-
- o If the proxy knows that the version of the next-hop server is
- HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST
- respond with a 417 (Expectation Failed) status code.
-
- o Proxies SHOULD maintain a cache recording the HTTP version numbers
- received from recently-referenced next-hop servers.
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 47]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- o A proxy MUST NOT forward a 100 (Continue) response if the request
- message was received from an HTTP/1.0 (or earlier) client and did
- not include an Expect request-header field with the "100-continue"
- expectation. This requirement overrides the general rule for
- forwarding of 1xx responses (see Section 8.1 of [Part2]).
-
-7.2.4. Client Behavior if Server Prematurely Closes Connection
-
- If an HTTP/1.1 client sends a request which includes a request body,
- but which does not include an Expect request-header field with the
- "100-continue" expectation, and if the client is not directly
- connected to an HTTP/1.1 origin server, and if the client sees the
- connection close before receiving a status line from the server, the
- client SHOULD retry the request. If the client does retry this
- request, it MAY use the following "binary exponential backoff"
- algorithm to be assured of obtaining a reliable response:
-
- 1. Initiate a new connection to the server
-
- 2. Transmit the request-headers
-
- 3. Initialize a variable R to the estimated round-trip time to the
- server (e.g., based on the time it took to establish the
- connection), or to a constant value of 5 seconds if the round-
- trip time is not available.
-
- 4. Compute T = R * (2**N), where N is the number of previous retries
- of this request.
-
- 5. Wait either for an error response from the server, or for T
- seconds (whichever comes first)
-
- 6. If no error response is received, after T seconds transmit the
- body of the request.
-
- 7. If client sees that the connection is closed prematurely, repeat
- from step 1 until the request is accepted, an error response is
- received, or the user becomes impatient and terminates the retry
- process.
-
- If at any point an error status code is received, the client
-
- o SHOULD NOT continue and
-
- o SHOULD close the connection if it has not completed sending the
- request message.
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 48]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
-8. Miscellaneous notes that might disappear
-
-8.1. Scheme aliases considered harmful
-
- [[TBD-aliases-harmful: describe why aliases like webcal are
- harmful.]]
-
-8.2. Use of HTTP for proxy communication
-
- [[TBD-proxy-other: Configured to use HTTP to proxy HTTP or other
- protocols.]]
-
-8.3. Interception of HTTP for access control
-
- [[TBD-intercept: Interception of HTTP traffic for initiating access
- control.]]
-
-8.4. Use of HTTP by other protocols
-
- [[TBD-profiles: Profiles of HTTP defined by other protocol.
- Extensions of HTTP like WebDAV.]]
-
-8.5. Use of HTTP by media type specification
-
- [[TBD-hypertext: Instructions on composing HTTP requests via
- hypertext formats.]]
-
-9. Header Field Definitions
-
- This section defines the syntax and semantics of HTTP/1.1 header
- fields related to message framing and transport protocols.
-
-9.1. Connection
-
- The "Connection" general-header field allows the sender to specify
- options that are desired for that particular connection and MUST NOT
- be communicated by proxies over further connections.
-
- The Connection header's value has the following grammar:
-
- Connection = "Connection" ":" OWS Connection-v
- Connection-v = 1#connection-token
- connection-token = token
-
- HTTP/1.1 proxies MUST parse the Connection header field before a
- message is forwarded and, for each connection-token in this field,
- remove any header field(s) from the message with the same name as the
- connection-token. Connection options are signaled by the presence of
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 49]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- a connection-token in the Connection header field, not by any
- corresponding additional header field(s), since the additional header
- field might not be sent if there are no parameters associated with
- that connection option.
-
- Message headers listed in the Connection header MUST NOT include end-
- to-end headers, such as Cache-Control.
-
- HTTP/1.1 defines the "close" connection option for the sender to
- signal that the connection will be closed after completion of the
- response. For example,
-
- Connection: close
-
- in either the request or the response header fields indicates that
- the connection SHOULD NOT be considered "persistent" (Section 7.1)
- after the current request/response is complete.
-
- An HTTP/1.1 client that does not support persistent connections MUST
- include the "close" connection option in every request message.
-
- An HTTP/1.1 server that does not support persistent connections MUST
- include the "close" connection option in every response message that
- does not have a 1xx (Informational) status code.
-
- A system receiving an HTTP/1.0 (or lower-version) message that
- includes a Connection header MUST, for each connection-token in this
- field, remove and ignore any header field(s) from the message with
- the same name as the connection-token. This protects against
- mistaken forwarding of such header fields by pre-HTTP/1.1 proxies.
- See Appendix B.2.
-
-9.2. Content-Length
-
- The "Content-Length" header field indicates the size of the message-
- body, in decimal number of octets, for any message other than a
- response to the HEAD method or a response with a status code of 304.
- In the case of responses to the HEAD method, it indicates the size of
- the payload body (not including any potential transfer-coding) that
- would have been sent had the request been a GET. In the case of the
- 304 (Not Modified) response, it indicates the size of the payload
- body (not including any potential transfer-coding) that would have
- been sent in a 200 (OK) response.
-
- Content-Length = "Content-Length" ":" OWS 1*Content-Length-v
- Content-Length-v = 1*DIGIT
-
- An example is
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 50]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- Content-Length: 3495
-
- Implementations SHOULD use this field to indicate the message-body
- length when no transfer-coding is being applied and the payload's
- body length can be determined prior to being transferred.
- Section 3.3 describes how recipients determine the length of a
- message-body.
-
- Any Content-Length greater than or equal to zero is a valid value.
-
- Note that the use of this field in HTTP is significantly different
- from the corresponding definition in MIME, where it is an optional
- field used within the "message/external-body" content-type.
-
-9.3. Date
-
- The "Date" general-header field represents the date and time at which
- the message was originated, having the same semantics as the
- Origination Date Field (orig-date) defined in Section 3.6.1 of
- [RFC5322]. The field value is an HTTP-date, as described in
- Section 6.1; it MUST be sent in rfc1123-date format.
-
- Date = "Date" ":" OWS Date-v
- Date-v = HTTP-date
-
- An example is
-
- Date: Tue, 15 Nov 1994 08:12:31 GMT
-
- Origin servers MUST include a Date header field in all responses,
- except in these cases:
-
- 1. If the response status code is 100 (Continue) or 101 (Switching
- Protocols), the response MAY include a Date header field, at the
- server's option.
-
- 2. If the response status code conveys a server error, e.g., 500
- (Internal Server Error) or 503 (Service Unavailable), and it is
- inconvenient or impossible to generate a valid Date.
-
- 3. If the server does not have a clock that can provide a reasonable
- approximation of the current time, its responses MUST NOT include
- a Date header field. In this case, the rules in Section 9.3.1
- MUST be followed.
-
- A received message that does not have a Date header field MUST be
- assigned one by the recipient if the message will be cached by that
- recipient or gatewayed via a protocol which requires a Date. An HTTP
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 51]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- implementation without a clock MUST NOT cache responses without
- revalidating them on every use. An HTTP cache, especially a shared
- cache, SHOULD use a mechanism, such as NTP [RFC1305], to synchronize
- its clock with a reliable external standard.
-
- Clients SHOULD only send a Date header field in messages that include
- a payload, as is usually the case for PUT and POST requests, and even
- then it is optional. A client without a clock MUST NOT send a Date
- header field in a request.
-
- The HTTP-date sent in a Date header SHOULD NOT represent a date and
- time subsequent to the generation of the message. It SHOULD
- represent the best available approximation of the date and time of
- message generation, unless the implementation has no means of
- generating a reasonably accurate date and time. In theory, the date
- ought to represent the moment just before the payload is generated.
- In practice, the date can be generated at any time during the message
- origination without affecting its semantic value.
-
-9.3.1. Clockless Origin Server Operation
-
- Some origin server implementations might not have a clock available.
- An origin server without a clock MUST NOT assign Expires or Last-
- Modified values to a response, unless these values were associated
- with the resource by a system or user with a reliable clock. It MAY
- assign an Expires value that is known, at or before server
- configuration time, to be in the past (this allows "pre-expiration"
- of responses without storing separate Expires values for each
- resource).
-
-9.4. Host
-
- The "Host" request-header field specifies the Internet host and port
- number of the resource being requested, allowing the origin server or
- gateway to differentiate between internally-ambiguous URLs, such as
- the root "/" URL of a server for multiple host names on a single IP
- address.
-
- The Host field value MUST represent the naming authority of the
- origin server or gateway given by the original URL obtained from the
- user or referring resource (generally an http URI, as described in
- Section 2.6.1).
-
- Host = "Host" ":" OWS Host-v
- Host-v = uri-host [ ":" port ] ; Section 2.6.1
-
- A "host" without any trailing port information implies the default
- port for the service requested (e.g., "80" for an HTTP URL). For
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 52]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- example, a request on the origin server for
- would properly include:
-
- GET /pub/WWW/ HTTP/1.1
- Host: www.example.org
-
- A client MUST include a Host header field in all HTTP/1.1 request
- messages. If the requested URI does not include an Internet host
- name for the service being requested, then the Host header field MUST
- be given with an empty value. An HTTP/1.1 proxy MUST ensure that any
- request message it forwards does contain an appropriate Host header
- field that identifies the service being requested by the proxy. All
- Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request)
- status code to any HTTP/1.1 request message which lacks a Host header
- field.
-
- See Sections 4.2 and B.1.1 for other requirements relating to Host.
-
-9.5. TE
-
- The "TE" request-header field indicates what extension transfer-
- codings it is willing to accept in the response, and whether or not
- it is willing to accept trailer fields in a chunked transfer-coding.
-
- Its value consists of the keyword "trailers" and/or a comma-separated
- list of extension transfer-coding names with optional accept
- parameters (as described in Section 6.2).
-
- TE = "TE" ":" OWS TE-v
- TE-v = #t-codings
- t-codings = "trailers" / ( transfer-extension [ te-params ] )
- te-params = OWS ";" OWS "q=" qvalue *( te-ext )
- te-ext = OWS ";" OWS token [ "=" word ]
-
- The presence of the keyword "trailers" indicates that the client is
- willing to accept trailer fields in a chunked transfer-coding, as
- defined in Section 6.2.1. This keyword is reserved for use with
- transfer-coding values even though it does not itself represent a
- transfer-coding.
-
- Examples of its use are:
-
- TE: deflate
- TE:
- TE: trailers, deflate;q=0.5
-
- The TE header field only applies to the immediate connection.
- Therefore, the keyword MUST be supplied within a Connection header
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 53]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- field (Section 9.1) whenever TE is present in an HTTP/1.1 message.
-
- A server tests whether a transfer-coding is acceptable, according to
- a TE field, using these rules:
-
- 1. The "chunked" transfer-coding is always acceptable. If the
- keyword "trailers" is listed, the client indicates that it is
- willing to accept trailer fields in the chunked response on
- behalf of itself and any downstream clients. The implication is
- that, if given, the client is stating that either all downstream
- clients are willing to accept trailer fields in the forwarded
- response, or that it will attempt to buffer the response on
- behalf of downstream recipients.
-
- Note: HTTP/1.1 does not define any means to limit the size of a
- chunked response such that a client can be assured of buffering
- the entire response.
-
- 2. If the transfer-coding being tested is one of the transfer-
- codings listed in the TE field, then it is acceptable unless it
- is accompanied by a qvalue of 0. (As defined in Section 6.4, a
- qvalue of 0 means "not acceptable".)
-
- 3. If multiple transfer-codings are acceptable, then the acceptable
- transfer-coding with the highest non-zero qvalue is preferred.
- The "chunked" transfer-coding always has a qvalue of 1.
-
- If the TE field-value is empty or if no TE field is present, the only
- transfer-coding is "chunked". A message with no transfer-coding is
- always acceptable.
-
-9.6. Trailer
-
- The "Trailer" general-header field indicates that the given set of
- header fields is present in the trailer of a message encoded with
- chunked transfer-coding.
-
- Trailer = "Trailer" ":" OWS Trailer-v
- Trailer-v = 1#field-name
-
- An HTTP/1.1 message SHOULD include a Trailer header field in a
- message using chunked transfer-coding with a non-empty trailer.
- Doing so allows the recipient to know which header fields to expect
- in the trailer.
-
- If no Trailer header field is present, the trailer SHOULD NOT include
- any header fields. See Section 6.2.1 for restrictions on the use of
- trailer fields in a "chunked" transfer-coding.
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 54]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- Message header fields listed in the Trailer header field MUST NOT
- include the following header fields:
-
- o Transfer-Encoding
-
- o Content-Length
-
- o Trailer
-
-9.7. Transfer-Encoding
-
- The "Transfer-Encoding" general-header field indicates what transfer-
- codings (if any) have been applied to the message body. It differs
- from Content-Encoding (Section 2.2 of [Part3]) in that transfer-
- codings are a property of the message (and therefore are removed by
- intermediaries), whereas content-codings are not.
-
- Transfer-Encoding = "Transfer-Encoding" ":" OWS
- Transfer-Encoding-v
- Transfer-Encoding-v = 1#transfer-coding
-
- Transfer-codings are defined in Section 6.2. An example is:
-
- Transfer-Encoding: chunked
-
- If multiple encodings have been applied to a representation, the
- transfer-codings MUST be listed in the order in which they were
- applied. Additional information about the encoding parameters MAY be
- provided by other header fields not defined by this specification.
-
- Many older HTTP/1.0 applications do not understand the Transfer-
- Encoding header.
-
-9.8. Upgrade
-
- The "Upgrade" general-header field allows the client to specify what
- additional communication protocols it would like to use, if the
- server chooses to switch protocols. Additionally, the server MUST
- use the Upgrade header field within a 101 (Switching Protocols)
- response to indicate which protocol(s) are being switched to.
-
- Upgrade = "Upgrade" ":" OWS Upgrade-v
- Upgrade-v = 1#product
-
- For example,
-
- Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 55]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- The Upgrade header field is intended to provide a simple mechanism
- for transition from HTTP/1.1 to some other, incompatible protocol.
- It does so by allowing the client to advertise its desire to use
- another protocol, such as a later version of HTTP with a higher major
- version number, even though the current request has been made using
- HTTP/1.1. This eases the difficult transition between incompatible
- protocols by allowing the client to initiate a request in the more
- commonly supported protocol while indicating to the server that it
- would like to use a "better" protocol if available (where "better" is
- determined by the server, possibly according to the nature of the
- method and/or resource being requested).
-
- The Upgrade header field only applies to switching application-layer
- protocols upon the existing transport-layer connection. Upgrade
- cannot be used to insist on a protocol change; its acceptance and use
- by the server is optional. The capabilities and nature of the
- application-layer communication after the protocol change is entirely
- dependent upon the new protocol chosen, although the first action
- after changing the protocol MUST be a response to the initial HTTP
- request containing the Upgrade header field.
-
- The Upgrade header field only applies to the immediate connection.
- Therefore, the upgrade keyword MUST be supplied within a Connection
- header field (Section 9.1) whenever Upgrade is present in an HTTP/1.1
- message.
-
- The Upgrade header field cannot be used to indicate a switch to a
- protocol on a different connection. For that purpose, it is more
- appropriate to use a 301, 302, 303, or 305 redirection response.
-
- This specification only defines the protocol name "HTTP" for use by
- the family of Hypertext Transfer Protocols, as defined by the HTTP
- version rules of Section 2.5 and future updates to this
- specification. Additional tokens can be registered with IANA using
- the registration procedure defined below.
-
-9.8.1. Upgrade Token Registry
-
- The HTTP Upgrade Token Registry defines the name space for product
- tokens used to identify protocols in the Upgrade header field. Each
- registered token is associated with contact information and an
- optional set of specifications that details how the connection will
- be processed after it has been upgraded.
-
- Registrations are allowed on a First Come First Served basis as
- described in Section 4.1 of [RFC5226]. The specifications need not
- be IETF documents or be subject to IESG review. Registrations are
- subject to the following rules:
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 56]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- 1. A token, once registered, stays registered forever.
-
- 2. The registration MUST name a responsible party for the
- registration.
-
- 3. The registration MUST name a point of contact.
-
- 4. The registration MAY name a set of specifications associated with
- that token. Such specifications need not be publicly available.
-
- 5. The responsible party MAY change the registration at any time.
- The IANA will keep a record of all such changes, and make them
- available upon request.
-
- 6. The responsible party for the first registration of a "product"
- token MUST approve later registrations of a "version" token
- together with that "product" token before they can be registered.
-
- 7. If absolutely required, the IESG MAY reassign the responsibility
- for a token. This will normally only be used in the case when a
- responsible party cannot be contacted.
-
-9.9. Via
-
- The "Via" general-header field MUST be used by gateways and proxies
- to indicate the intermediate protocols and recipients between the
- user agent and the server on requests, and between the origin server
- and the client on responses. It is analogous to the "Received" field
- defined in Section 3.6.7 of [RFC5322] and is intended to be used for
- tracking message forwards, avoiding request loops, and identifying
- the protocol capabilities of all senders along the request/response
- chain.
-
- Via = "Via" ":" OWS Via-v
- Via-v = 1#( received-protocol RWS received-by
- [ RWS comment ] )
- received-protocol = [ protocol-name "/" ] protocol-version
- protocol-name = token
- protocol-version = token
- received-by = ( uri-host [ ":" port ] ) / pseudonym
- pseudonym = token
-
- The received-protocol indicates the protocol version of the message
- received by the server or client along each segment of the request/
- response chain. The received-protocol version is appended to the Via
- field value when the message is forwarded so that information about
- the protocol capabilities of upstream applications remains visible to
- all recipients.
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 57]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- The protocol-name is optional if and only if it would be "HTTP". The
- received-by field is normally the host and optional port number of a
- recipient server or client that subsequently forwarded the message.
- However, if the real host is considered to be sensitive information,
- it MAY be replaced by a pseudonym. If the port is not given, it MAY
- be assumed to be the default port of the received-protocol.
-
- Multiple Via field values represent each proxy or gateway that has
- forwarded the message. Each recipient MUST append its information
- such that the end result is ordered according to the sequence of
- forwarding applications.
-
- Comments MAY be used in the Via header field to identify the software
- of the recipient proxy or gateway, analogous to the User-Agent and
- Server header fields. However, all comments in the Via field are
- optional and MAY be removed by any recipient prior to forwarding the
- message.
-
- For example, a request message could be sent from an HTTP/1.0 user
- agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
- forward the request to a public proxy at p.example.net, which
- completes the request by forwarding it to the origin server at
- www.example.com. The request received by www.example.com would then
- have the following Via header field:
-
- Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
-
- Proxies and gateways used as a portal through a network firewall
- SHOULD NOT, by default, forward the names and ports of hosts within
- the firewall region. This information SHOULD only be propagated if
- explicitly enabled. If not enabled, the received-by host of any host
- behind the firewall SHOULD be replaced by an appropriate pseudonym
- for that host.
-
- For organizations that have strong privacy requirements for hiding
- internal structures, a proxy MAY combine an ordered subsequence of
- Via header field entries with identical received-protocol values into
- a single such entry. For example,
-
- Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
-
- could be collapsed to
-
- Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
-
- Applications SHOULD NOT combine multiple entries unless they are all
- under the same organizational control and the hosts have already been
- replaced by pseudonyms. Applications MUST NOT combine entries which
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 58]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- have different received-protocol values.
-
-10. IANA Considerations
-
-10.1. Header Field Registration
-
- The Message Header Field Registry located at shall be
- updated with the permanent registrations below (see [RFC3864]):
-
- +-------------------+----------+----------+-------------+
- | Header Field Name | Protocol | Status | Reference |
- +-------------------+----------+----------+-------------+
- | Connection | http | standard | Section 9.1 |
- | Content-Length | http | standard | Section 9.2 |
- | Date | http | standard | Section 9.3 |
- | Host | http | standard | Section 9.4 |
- | TE | http | standard | Section 9.5 |
- | Trailer | http | standard | Section 9.6 |
- | Transfer-Encoding | http | standard | Section 9.7 |
- | Upgrade | http | standard | Section 9.8 |
- | Via | http | standard | Section 9.9 |
- +-------------------+----------+----------+-------------+
-
- The change controller is: "IETF (iesg@ietf.org) - Internet
- Engineering Task Force".
-
-10.2. URI Scheme Registration
-
- The entries for the "http" and "https" URI Schemes in the registry
- located at shall
- be updated to point to Sections 2.6.1 and 2.6.2 of this document (see
- [RFC4395]).
-
-10.3. Internet Media Type Registrations
-
- This document serves as the specification for the Internet media
- types "message/http" and "application/http". The following is to be
- registered with IANA (see [RFC4288]).
-
-10.3.1. Internet Media Type message/http
-
- The message/http type can be used to enclose a single HTTP request or
- response message, provided that it obeys the MIME restrictions for
- all "message" types regarding line length and encodings.
-
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 59]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- Type name: message
-
- Subtype name: http
-
- Required parameters: none
-
- Optional parameters: version, msgtype
-
- version: The HTTP-Version number of the enclosed message (e.g.,
- "1.1"). If not present, the version can be determined from the
- first line of the body.
-
- msgtype: The message type -- "request" or "response". If not
- present, the type can be determined from the first line of the
- body.
-
- Encoding considerations: only "7bit", "8bit", or "binary" are
- permitted
-
- Security considerations: none
-
- Interoperability considerations: none
-
- Published specification: This specification (see Section 10.3.1).
-
- Applications that use this media type:
-
- Additional information:
-
- Magic number(s): none
-
- File extension(s): none
-
- Macintosh file type code(s): none
-
- Person and email address to contact for further information: See
- Authors Section.
-
- Intended usage: COMMON
-
- Restrictions on usage: none
-
- Author/Change controller: IESG
-
-
-
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 60]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
-10.3.2. Internet Media Type application/http
-
- The application/http type can be used to enclose a pipeline of one or
- more HTTP request or response messages (not intermixed).
-
- Type name: application
-
- Subtype name: http
-
- Required parameters: none
-
- Optional parameters: version, msgtype
-
- version: The HTTP-Version number of the enclosed messages (e.g.,
- "1.1"). If not present, the version can be determined from the
- first line of the body.
-
- msgtype: The message type -- "request" or "response". If not
- present, the type can be determined from the first line of the
- body.
-
- Encoding considerations: HTTP messages enclosed by this type are in
- "binary" format; use of an appropriate Content-Transfer-Encoding
- is required when transmitted via E-mail.
-
- Security considerations: none
-
- Interoperability considerations: none
-
- Published specification: This specification (see Section 10.3.2).
-
- Applications that use this media type:
-
- Additional information:
-
- Magic number(s): none
-
- File extension(s): none
-
- Macintosh file type code(s): none
-
- Person and email address to contact for further information: See
- Authors Section.
-
- Intended usage: COMMON
-
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 61]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- Restrictions on usage: none
-
- Author/Change controller: IESG
-
-10.4. Transfer Coding Registry
-
- The registration procedure for HTTP Transfer Codings is now defined
- by Section 6.2.3 of this document.
-
- The HTTP Transfer Codings Registry located at
- shall be updated
- with the registrations below:
-
- +----------+--------------------------------------+-----------------+
- | Name | Description | Reference |
- +----------+--------------------------------------+-----------------+
- | chunked | Transfer in a series of chunks | Section 6.2.1 |
- | compress | UNIX "compress" program method | Section 6.2.2.1 |
- | deflate | "deflate" compression mechanism | Section 6.2.2.2 |
- | | ([RFC1951]) used inside the "zlib" | |
- | | data format ([RFC1950]) | |
- | gzip | Same as GNU zip [RFC1952] | Section 6.2.2.3 |
- +----------+--------------------------------------+-----------------+
-
-10.5. Upgrade Token Registration
-
- The registration procedure for HTTP Upgrade Tokens -- previously
- defined in Section 7.2 of [RFC2817] -- is now defined by
- Section 9.8.1 of this document.
-
- The HTTP Status Code Registry located at
- shall be
- updated with the registration below:
-
- +-------+---------------------------+-------------------------------+
- | Value | Description | Reference |
- +-------+---------------------------+-------------------------------+
- | HTTP | Hypertext Transfer | Section 2.5 of this |
- | | Protocol | specification |
- +-------+---------------------------+-------------------------------+
-
-11. Security Considerations
-
- This section is meant to inform application developers, information
- providers, and users of the security limitations in HTTP/1.1 as
- described by this document. The discussion does not include
- definitive solutions to the problems revealed, though it does make
- some suggestions for reducing security risks.
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 62]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
-11.1. Personal Information
-
- HTTP clients are often privy to large amounts of personal information
- (e.g., the user's name, location, mail address, passwords, encryption
- keys, etc.), and SHOULD be very careful to prevent unintentional
- leakage of this information. We very strongly recommend that a
- convenient interface be provided for the user to control
- dissemination of such information, and that designers and
- implementors be particularly careful in this area. History shows
- that errors in this area often create serious security and/or privacy
- problems and generate highly adverse publicity for the implementor's
- company.
-
-11.2. Abuse of Server Log Information
-
- A server is in the position to save personal data about a user's
- requests which might identify their reading patterns or subjects of
- interest. This information is clearly confidential in nature and its
- handling can be constrained by law in certain countries. People
- using HTTP to provide data are responsible for ensuring that such
- material is not distributed without the permission of any individuals
- that are identifiable by the published results.
-
-11.3. Attacks Based On File and Path Names
-
- Implementations of HTTP origin servers SHOULD be careful to restrict
- the documents returned by HTTP requests to be only those that were
- intended by the server administrators. If an HTTP server translates
- HTTP URIs directly into file system calls, the server MUST take
- special care not to serve files that were not intended to be
- delivered to HTTP clients. For example, UNIX, Microsoft Windows, and
- other operating systems use ".." as a path component to indicate a
- directory level above the current one. On such a system, an HTTP
- server MUST disallow any such construct in the request-target if it
- would otherwise allow access to a resource outside those intended to
- be accessible via the HTTP server. Similarly, files intended for
- reference only internally to the server (such as access control
- files, configuration files, and script code) MUST be protected from
- inappropriate retrieval, since they might contain sensitive
- information. Experience has shown that minor bugs in such HTTP
- server implementations have turned into security risks.
-
-11.4. DNS Spoofing
-
- Clients using HTTP rely heavily on the Domain Name Service, and are
- thus generally prone to security attacks based on the deliberate mis-
- association of IP addresses and DNS names. Clients need to be
- cautious in assuming the continuing validity of an IP number/DNS name
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 63]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- association.
-
- In particular, HTTP clients SHOULD rely on their name resolver for
- confirmation of an IP number/DNS name association, rather than
- caching the result of previous host name lookups. Many platforms
- already can cache host name lookups locally when appropriate, and
- they SHOULD be configured to do so. It is proper for these lookups
- to be cached, however, only when the TTL (Time To Live) information
- reported by the name server makes it likely that the cached
- information will remain useful.
-
- If HTTP clients cache the results of host name lookups in order to
- achieve a performance improvement, they MUST observe the TTL
- information reported by DNS.
-
- If HTTP clients do not observe this rule, they could be spoofed when
- a previously-accessed server's IP address changes. As network
- renumbering is expected to become increasingly common [RFC1900], the
- possibility of this form of attack will grow. Observing this
- requirement thus reduces this potential security vulnerability.
-
- This requirement also improves the load-balancing behavior of clients
- for replicated servers using the same DNS name and reduces the
- likelihood of a user's experiencing failure in accessing sites which
- use that strategy.
-
-11.5. Proxies and Caching
-
- By their very nature, HTTP proxies are men-in-the-middle, and
- represent an opportunity for man-in-the-middle attacks. Compromise
- of the systems on which the proxies run can result in serious
- security and privacy problems. Proxies have access to security-
- related information, personal information about individual users and
- organizations, and proprietary information belonging to users and
- content providers. A compromised proxy, or a proxy implemented or
- configured without regard to security and privacy considerations,
- might be used in the commission of a wide range of potential attacks.
-
- Proxy operators need to protect the systems on which proxies run as
- they would protect any system that contains or transports sensitive
- information. In particular, log information gathered at proxies
- often contains highly sensitive personal information, and/or
- information about organizations. Log information needs to be
- carefully guarded, and appropriate guidelines for use need to be
- developed and followed. (Section 11.2).
-
- Proxy implementors need to consider the privacy and security
- implications of their design and coding decisions, and of the
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 64]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- configuration options they provide to proxy operators (especially the
- default configuration).
-
- Users of a proxy need to be aware that proxies are no trustworthier
- than the people who run them; HTTP itself cannot solve this problem.
-
- The judicious use of cryptography, when appropriate, might suffice to
- protect against a broad range of security and privacy attacks. Such
- cryptography is beyond the scope of the HTTP/1.1 specification.
-
-11.6. Denial of Service Attacks on Proxies
-
- They exist. They are hard to defend against. Research continues.
- Beware.
-
-12. Acknowledgments
-
- HTTP has evolved considerably over the years. It has benefited from
- a large and active developer community--the many people who have
- participated on the www-talk mailing list--and it is that community
- which has been most responsible for the success of HTTP and of the
- World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel
- W. Connolly, Bob Denny, John Franks, Jean-Francois Groff, Phillip M.
- Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli,
- Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special
- recognition for their efforts in defining early aspects of the
- protocol.
-
- This document has benefited greatly from the comments of all those
- participating in the HTTP-WG. In addition to those already
- mentioned, the following individuals have contributed to this
- specification:
-
- Gary Adams, Harald Tveit Alvestrand, Keith Ball, Brian Behlendorf,
- Paul Burchard, Maurizio Codogno, Josh Cohen, Mike Cowlishaw, Roman
- Czyborra, Michael A. Dolan, Daniel DuBois, David J. Fiander, Alan
- Freier, Marc Hedlund, Greg Herlihy, Koen Holtman, Alex Hopmann, Bob
- Jernigan, Shel Kaphan, Rohit Khare, John Klensin, Martijn Koster,
- Alexei Kosut, David M. Kristol, Daniel LaLiberte, Ben Laurie, Paul J.
- Leach, Albert Lunde, John C. Mallery, Jean-Philippe Martin-Flatin,
- Mitra, David Morris, Gavin Nicol, Ross Patterson, Bill Perry, Jeffrey
- Perry, Scott Powers, Owen Rees, Luigi Rizzo, David Robinson, Marc
- Salomon, Rich Salz, Allan M. Schiffman, Jim Seidman, Chuck Shotton,
- Eric W. Sink, Simon E. Spero, Richard N. Taylor, Robert S. Thau, Bill
- (BearHeart) Weinman, Francois Yergeau, Mary Ellen Zurko.
-
- Thanks to the "cave men" of Palo Alto. You know who you are.
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 65]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- Jim Gettys (the editor of [RFC2616]) wishes particularly to thank Roy
- Fielding, the editor of [RFC2068], along with John Klensin, Jeff
- Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh
- Cohen, Alex Hopmann, Scott Lawrence, and Larry Masinter for their
- help. And thanks go particularly to Jeff Mogul and Scott Lawrence
- for performing the "MUST/MAY/SHOULD" audit.
-
- The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik
- Frystyk implemented RFC 2068 early, and we wish to thank them for the
- discovery of many of the problems that this document attempts to
- rectify.
-
- This specification makes heavy use of the augmented BNF and generic
- constructs defined by David H. Crocker for [RFC5234]. Similarly, it
- reuses many of the definitions provided by Nathaniel Borenstein and
- Ned Freed for MIME [RFC2045]. We hope that their inclusion in this
- specification will help reduce past confusion over the relationship
- between HTTP and Internet mail message formats.
-
-13. References
-
-13.1. Normative References
-
- [ISO-8859-1] International Organization for Standardization,
- "Information technology -- 8-bit single-byte coded
- graphic character sets -- Part 1: Latin alphabet No.
- 1", ISO/IEC 8859-1:1998, 1998.
-
- [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
- Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
- Ed., and J. Reschke, Ed., "HTTP/1.1, part 2: Message
- Semantics", draft-ietf-httpbis-p2-semantics-11 (work in
- progress), August 2010.
-
- [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
- Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
- Ed., and J. Reschke, Ed., "HTTP/1.1, part 3: Message
- Payload and Content Negotiation",
- draft-ietf-httpbis-p3-payload-11 (work in progress),
- August 2010.
-
- [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
- Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y.,
- Ed., Nottingham, M., Ed., and J. Reschke, Ed.,
- "HTTP/1.1, part 6: Caching",
- draft-ietf-httpbis-p6-cache-11 (work in progress),
- August 2010.
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 66]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
- Format Specification version 3.3", RFC 1950, May 1996.
-
- RFC 1950 is an Informational RFC, thus it might be less
- stable than this specification. On the other hand,
- this downward reference was present since the
- publication of RFC 2068 in 1997 ([RFC2068]), therefore
- it is unlikely to cause problems in practice. See also
- [BCP97].
-
- [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
- Specification version 1.3", RFC 1951, May 1996.
-
- RFC 1951 is an Informational RFC, thus it might be less
- stable than this specification. On the other hand,
- this downward reference was present since the
- publication of RFC 2068 in 1997 ([RFC2068]), therefore
- it is unlikely to cause problems in practice. See also
- [BCP97].
-
- [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and
- G. Randers-Pehrson, "GZIP file format specification
- version 4.3", RFC 1952, May 1996.
-
- RFC 1952 is an Informational RFC, thus it might be less
- stable than this specification. On the other hand,
- this downward reference was present since the
- publication of RFC 2068 in 1997 ([RFC2068]), therefore
- it is unlikely to cause problems in practice. See also
- [BCP97].
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
- "Uniform Resource Identifier (URI): Generic Syntax",
- RFC 3986, STD 66, January 2005.
-
- [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
- Syntax Specifications: ABNF", STD 68, RFC 5234,
- January 2008.
-
- [USASCII] American National Standards Institute, "Coded Character
- Set -- 7-bit American Standard Code for Information
- Interchange", ANSI X3.4, 1986.
-
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 67]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
-13.2. Informative References
-
- [BCP97] Klensin, J. and S. Hartman, "Handling Normative
- References to Standards-Track Documents", BCP 97,
- RFC 4897, June 2007.
-
- [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and
- Politics", ACM Transactions on Internet Technology Vol.
- 1, #2, November 2001,
- .
-
- [Nie1997] Frystyk, H., Gettys, J., Prud'hommeaux, E., Lie, H.,
- and C. Lilley, "Network Performance Effects of
- HTTP/1.1, CSS1, and PNG", ACM Proceedings of the ACM
- SIGCOMM '97 conference on Applications, technologies,
- architectures, and protocols for computer communication
- SIGCOMM '97, September 1997,
- .
-
- [Pad1995] Padmanabhan, V. and J. Mogul, "Improving HTTP Latency",
- Computer Networks and ISDN Systems v. 28, pp. 25-35,
- December 1995,
- .
-
- [RFC1123] Braden, R., "Requirements for Internet Hosts -
- Application and Support", STD 3, RFC 1123,
- October 1989.
-
- [RFC1305] Mills, D., "Network Time Protocol (Version 3)
- Specification, Implementation", RFC 1305, March 1992.
-
- [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work",
- RFC 1900, February 1996.
-
- [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen,
- "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
- May 1996.
-
- [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
- Mail Extensions (MIME) Part One: Format of Internet
- Message Bodies", RFC 2045, November 1996.
-
- [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail
- Extensions) Part Three: Message Header Extensions for
- Non-ASCII Text", RFC 2047, November 1996.
-
- [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and
- T. Berners-Lee, "Hypertext Transfer Protocol --
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 68]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- HTTP/1.1", RFC 2068, January 1997.
-
- [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management
- Mechanism", RFC 2109, February 1997.
-
- [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen,
- "Use and Interpretation of HTTP Version Numbers",
- RFC 2145, May 1997.
-
- [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
- Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
- Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
-
- [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
- HTTP/1.1", RFC 2817, May 2000.
-
- [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
-
- [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management
- Mechanism", RFC 2965, October 2000.
-
- [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
- Procedures for Message Header Fields", BCP 90,
- RFC 3864, September 2004.
-
- [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications
- and Registration Procedures", BCP 13, RFC 4288,
- December 2005.
-
- [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines
- and Registration Procedures for New URI Schemes",
- BCP 115, RFC 4395, February 2006.
-
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
- an IANA Considerations Section in RFCs", BCP 26,
- RFC 5226, May 2008.
-
- [RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
- October 2008.
-
- [Spe] Spero, S., "Analysis of HTTP Performance Problems",
- .
-
- [Tou1998] Touch, J., Heidemann, J., and K. Obraczka, "Analysis of
- HTTP Performance", ISI Research Report ISI/RR-98-463,
- Aug 1998, .
-
- (original report dated Aug. 1996)
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 69]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
-Appendix A. Tolerant Applications
-
- Although this document specifies the requirements for the generation
- of HTTP/1.1 messages, not all applications will be correct in their
- implementation. We therefore recommend that operational applications
- be tolerant of deviations whenever those deviations can be
- interpreted unambiguously.
-
- Clients SHOULD be tolerant in parsing the Status-Line and servers
- SHOULD be tolerant when parsing the Request-Line. In particular,
- they SHOULD accept any amount of WSP characters between fields, even
- though only a single SP is required.
-
- The line terminator for header fields is the sequence CRLF. However,
- we recommend that applications, when parsing such headers, recognize
- a single LF as a line terminator and ignore the leading CR.
-
- The character set of a representation SHOULD be labeled as the lowest
- common denominator of the character codes used within that
- representation, with the exception that not labeling the
- representation is preferred over labeling the representation with the
- labels US-ASCII or ISO-8859-1. See [Part3].
-
- Additional rules for requirements on parsing and encoding of dates
- and other potential problems with date encodings include:
-
- o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date
- which appears to be more than 50 years in the future is in fact in
- the past (this helps solve the "year 2000" problem).
-
- o Although all date formats are specified to be case-sensitive,
- recipients SHOULD match day, week and timezone names case-
- insensitively.
-
- o An HTTP/1.1 implementation MAY internally represent a parsed
- Expires date as earlier than the proper value, but MUST NOT
- internally represent a parsed Expires date as later than the
- proper value.
-
- o All expiration-related calculations MUST be done in GMT. The
- local time zone MUST NOT influence the calculation or comparison
- of an age or expiration time.
-
- o If an HTTP header incorrectly carries a date value with a time
- zone other than GMT, it MUST be converted into GMT using the most
- conservative possible conversion.
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 70]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
-Appendix B. Compatibility with Previous Versions
-
- HTTP has been in use by the World-Wide Web global information
- initiative since 1990. The first version of HTTP, later referred to
- as HTTP/0.9, was a simple protocol for hypertext data transfer across
- the Internet with only a single method and no metadata. HTTP/1.0, as
- defined by [RFC1945], added a range of request methods and MIME-like
- messaging that could include metadata about the data transferred and
- modifiers on the request/response semantics. However, HTTP/1.0 did
- not sufficiently take into consideration the effects of hierarchical
- proxies, caching, the need for persistent connections, or name-based
- virtual hosts. The proliferation of incompletely-implemented
- applications calling themselves "HTTP/1.0" further necessitated a
- protocol version change in order for two communicating applications
- to determine each other's true capabilities.
-
- HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent
- requirements that enable reliable implementations, adding only those
- new features that will either be safely ignored by an HTTP/1.0
- recipient or only sent when communicating with a party advertising
- compliance with HTTP/1.1.
-
- It is beyond the scope of a protocol specification to mandate
- compliance with previous versions. HTTP/1.1 was deliberately
- designed, however, to make supporting previous versions easy. It is
- worth noting that, at the time of composing this specification, we
- would expect general-purpose HTTP/1.1 servers to:
-
- o understand any valid request in the format of HTTP/1.0 and 1.1;
-
- o respond appropriately with a message in the same major version
- used by the client.
-
- And we would expect HTTP/1.1 clients to:
-
- o understand any valid response in the format of HTTP/1.0 or 1.1.
-
- For most implementations of HTTP/1.0, each connection is established
- by the client prior to the request and closed by the server after
- sending the response. Some implementations implement the Keep-Alive
- version of persistent connections described in Section 19.7.1 of
- [RFC2068].
-
-B.1. Changes from HTTP/1.0
-
- This section summarizes major differences between versions HTTP/1.0
- and HTTP/1.1.
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 71]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
-B.1.1. Changes to Simplify Multi-homed Web Servers and Conserve IP
- Addresses
-
- The requirements that clients and servers support the Host request-
- header, report an error if the Host request-header (Section 9.4) is
- missing from an HTTP/1.1 request, and accept absolute URIs
- (Section 4.1.2) are among the most important changes defined by this
- specification.
-
- Older HTTP/1.0 clients assumed a one-to-one relationship of IP
- addresses and servers; there was no other established mechanism for
- distinguishing the intended server of a request than the IP address
- to which that request was directed. The changes outlined above will
- allow the Internet, once older HTTP clients are no longer common, to
- support multiple Web sites from a single IP address, greatly
- simplifying large operational Web servers, where allocation of many
- IP addresses to a single host has created serious problems. The
- Internet will also be able to recover the IP addresses that have been
- allocated for the sole purpose of allowing special-purpose domain
- names to be used in root-level HTTP URLs. Given the rate of growth
- of the Web, and the number of servers already deployed, it is
- extremely important that all implementations of HTTP (including
- updates to existing HTTP/1.0 applications) correctly implement these
- requirements:
-
- o Both clients and servers MUST support the Host request-header.
-
- o A client that sends an HTTP/1.1 request MUST send a Host header.
-
- o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1
- request does not include a Host request-header.
-
- o Servers MUST accept absolute URIs.
-
-B.2. Compatibility with HTTP/1.0 Persistent Connections
-
- Some clients and servers might wish to be compatible with some
- previous implementations of persistent connections in HTTP/1.0
- clients and servers. Persistent connections in HTTP/1.0 are
- explicitly negotiated as they are not the default behavior. HTTP/1.0
- experimental implementations of persistent connections are faulty,
- and the new facilities in HTTP/1.1 are designed to rectify these
- problems. The problem was that some existing HTTP/1.0 clients might
- send Keep-Alive to a proxy server that doesn't understand Connection,
- which would then erroneously forward it to the next inbound server,
- which would establish the Keep-Alive connection and result in a hung
- HTTP/1.0 proxy waiting for the close on the response. The result is
- that HTTP/1.0 clients must be prevented from using Keep-Alive when
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 72]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- talking to proxies.
-
- However, talking to proxies is the most important use of persistent
- connections, so that prohibition is clearly unacceptable. Therefore,
- we need some other mechanism for indicating a persistent connection
- is desired, which is safe to use even when talking to an old proxy
- that ignores Connection. Persistent connections are the default for
- HTTP/1.1 messages; we introduce a new keyword (Connection: close) for
- declaring non-persistence. See Section 9.1.
-
- The original HTTP/1.0 form of persistent connections (the Connection:
- Keep-Alive and Keep-Alive header) is documented in Section 19.7.1 of
- [RFC2068].
-
-B.3. Changes from RFC 2616
-
- Empty list elements in list productions have been deprecated.
- (Section 1.2.1)
-
- Rules about implicit linear whitespace between certain grammar
- productions have been removed; now it's only allowed when
- specifically pointed out in the ABNF. The NUL character is no longer
- allowed in comment and quoted-string text. The quoted-pair rule no
- longer allows escaping control characters other than HTAB. Non-ASCII
- content in header fields and reason phrase has been obsoleted and
- made opaque (the TEXT rule was removed) (Section 1.2.2)
-
- Clarify that HTTP-Version is case sensitive. (Section 2.5)
-
- Remove reference to non-existent identity transfer-coding value
- tokens. (Sections 6.2 and 3.3)
-
- Require that invalid whitespace around field-names be rejected.
- (Section 3.2)
-
- Update use of abs_path production from RFC1808 to the path-absolute +
- query components of RFC3986. (Section 4.1.2)
-
- Clarification that the chunk length does not include the count of the
- octets in the chunk header and trailer. Furthermore disallowed line
- folding in chunk extensions. (Section 6.2.1)
-
- Remove hard limit of two connections per server. (Section 7.1.4)
-
- Clarify exactly when close connection options must be sent.
- (Section 9.1)
-
-Appendix C. Collected ABNF
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 73]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- BWS = OWS
-
- Cache-Control =
- Chunked-Body = *chunk last-chunk trailer-part CRLF
- Connection = "Connection:" OWS Connection-v
- Connection-v = *( "," OWS ) connection-token *( OWS "," [ OWS
- connection-token ] )
- Content-Length = "Content-Length:" OWS 1*Content-Length-v
- Content-Length-v = 1*DIGIT
-
- Date = "Date:" OWS Date-v
- Date-v = HTTP-date
-
- GMT = %x47.4D.54 ; GMT
-
- HTTP-Prot-Name = %x48.54.54.50 ; HTTP
- HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT
- HTTP-date = rfc1123-date / obs-date
- HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body
- ]
- Host = "Host:" OWS Host-v
- Host-v = uri-host [ ":" port ]
-
- MIME-Version =
- Method = token
-
- OWS = *( [ obs-fold ] WSP )
-
- Pragma =
-
- RWS = 1*( [ obs-fold ] WSP )
- Reason-Phrase = *( WSP / VCHAR / obs-text )
- Request = Request-Line *( header-field CRLF ) CRLF [ message-body ]
- Request-Line = Method SP request-target SP HTTP-Version CRLF
- Response = Status-Line *( header-field CRLF ) CRLF [ message-body ]
-
- Status-Code = 3DIGIT
- Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
-
- TE = "TE:" OWS TE-v
- TE-v = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ]
- Trailer = "Trailer:" OWS Trailer-v
- Trailer-v = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] )
- Transfer-Encoding = "Transfer-Encoding:" OWS Transfer-Encoding-v
- Transfer-Encoding-v = *( "," OWS ) transfer-coding *( OWS "," [ OWS
- transfer-coding ] )
-
- URI-reference =
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 74]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- Upgrade = "Upgrade:" OWS Upgrade-v
- Upgrade-v = *( "," OWS ) product *( OWS "," [ OWS product ] )
-
- Via = "Via:" OWS Via-v
- Via-v = *( "," OWS ) received-protocol RWS received-by [ RWS comment
- ] *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ]
- ] )
-
- Warning =
-
- absolute-URI =
- asctime-date = day-name SP date3 SP time-of-day SP year
- attribute = token
- authority =
-
- chunk = chunk-size *WSP [ chunk-ext ] CRLF chunk-data CRLF
- chunk-data = 1*OCTET
- chunk-ext = *( ";" *WSP chunk-ext-name [ "=" chunk-ext-val ] *WSP )
- chunk-ext-name = token
- chunk-ext-val = token / quoted-str-nf
- chunk-size = 1*HEXDIG
- comment = "(" *( ctext / quoted-cpair / comment ) ")"
- connection-token = token
- ctext = OWS / %x21-27 ; '!'-'''
- / %x2A-5B ; '*'-'['
- / %x5D-7E ; ']'-'~'
- / obs-text
-
- date1 = day SP month SP year
- date2 = day "-" month "-" 2DIGIT
- date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
- day = 2DIGIT
- day-name = %x4D.6F.6E ; Mon
- / %x54.75.65 ; Tue
- / %x57.65.64 ; Wed
- / %x54.68.75 ; Thu
- / %x46.72.69 ; Fri
- / %x53.61.74 ; Sat
- / %x53.75.6E ; Sun
- day-name-l = %x4D.6F.6E.64.61.79 ; Monday
- / %x54.75.65.73.64.61.79 ; Tuesday
- / %x57.65.64.6E.65.73.64.61.79 ; Wednesday
- / %x54.68.75.72.73.64.61.79 ; Thursday
- / %x46.72.69.64.61.79 ; Friday
- / %x53.61.74.75.72.64.61.79 ; Saturday
- / %x53.75.6E.64.61.79 ; Sunday
-
- field-content = *( WSP / VCHAR / obs-text )
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 75]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- field-name = token
- field-value = *( field-content / OWS )
-
- general-header = Cache-Control / Connection / Date / Pragma / Trailer
- / Transfer-Encoding / Upgrade / Via / Warning / MIME-Version
-
- header-field = field-name ":" OWS [ field-value ] OWS
- hour = 2DIGIT
- http-URI = "http://" authority path-abempty [ "?" query ]
- https-URI = "https://" authority path-abempty [ "?" query ]
-
- last-chunk = 1*"0" *WSP [ chunk-ext ] CRLF
-
- message-body = *OCTET
- minute = 2DIGIT
- month = %x4A.61.6E ; Jan
- / %x46.65.62 ; Feb
- / %x4D.61.72 ; Mar
- / %x41.70.72 ; Apr
- / %x4D.61.79 ; May
- / %x4A.75.6E ; Jun
- / %x4A.75.6C ; Jul
- / %x41.75.67 ; Aug
- / %x53.65.70 ; Sep
- / %x4F.63.74 ; Oct
- / %x4E.6F.76 ; Nov
- / %x44.65.63 ; Dec
-
- obs-date = rfc850-date / asctime-date
- obs-fold = CRLF
- obs-text = %x80-FF
-
- partial-URI = relative-part [ "?" query ]
- path-abempty =
- path-absolute =
- port =
- product = token [ "/" product-version ]
- product-version = token
- protocol-name = token
- protocol-version = token
- pseudonym = token
-
- qdtext = OWS / "!" / %x23-5B ; '#'-'['
- / %x5D-7E ; ']'-'~'
- / obs-text
- qdtext-nf = WSP / "!" / %x23-5B ; '#'-'['
- / %x5D-7E ; ']'-'~'
- / obs-text
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 76]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- query =
- quoted-cpair = "\" ( WSP / VCHAR / obs-text )
- quoted-pair = "\" ( WSP / VCHAR / obs-text )
- quoted-str-nf = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE
- quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
- qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
-
- received-by = ( uri-host [ ":" port ] ) / pseudonym
- received-protocol = [ protocol-name "/" ] protocol-version
- relative-part =
- request-header =
- request-target = "*" / absolute-URI / ( path-absolute [ "?" query ] )
- / authority
- response-header =
- rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT
- rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
-
- second = 2DIGIT
- special = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" /
- DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}"
- start-line = Request-Line / Status-Line
-
- t-codings = "trailers" / ( transfer-extension [ te-params ] )
- tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /
- "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
- te-ext = OWS ";" OWS token [ "=" word ]
- te-params = OWS ";" OWS "q=" qvalue *te-ext
- time-of-day = hour ":" minute ":" second
- token = 1*tchar
- trailer-part = *( header-field CRLF )
- transfer-coding = "chunked" / "compress" / "deflate" / "gzip" /
- transfer-extension
- transfer-extension = token *( OWS ";" OWS transfer-parameter )
- transfer-parameter = attribute BWS "=" BWS value
-
- uri-host =
-
- value = word
-
- word = token / quoted-string
-
- year = 4DIGIT
-
-
-
-
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 77]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- ABNF diagnostics:
-
- ; Chunked-Body defined but not used
- ; Content-Length defined but not used
- ; HTTP-message defined but not used
- ; Host defined but not used
- ; Request defined but not used
- ; Response defined but not used
- ; TE defined but not used
- ; URI-reference defined but not used
- ; general-header defined but not used
- ; http-URI defined but not used
- ; https-URI defined but not used
- ; partial-URI defined but not used
- ; request-header defined but not used
- ; response-header defined but not used
- ; special defined but not used
-
-Appendix D. Change Log (to be removed by RFC Editor before publication)
-
-D.1. Since RFC2616
-
- Extracted relevant partitions from [RFC2616].
-
-D.2. Since draft-ietf-httpbis-p1-messaging-00
-
- Closed issues:
-
- o : "HTTP Version
- should be case sensitive"
- ()
-
- o : "'unsafe'
- characters" ()
-
- o : "Chunk Size
- Definition" ()
-
- o : "Message Length"
- ()
-
- o : "Media Type
- Registrations" ()
-
- o : "URI includes
- query" ()
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 78]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- o : "No close on
- 1xx responses" ()
-
- o : "Remove
- 'identity' token references"
- ()
-
- o : "Import query
- BNF"
-
- o : "qdtext BNF"
-
- o : "Normative and
- Informative references"
-
- o : "RFC2606
- Compliance"
-
- o : "RFC977
- reference"
-
- o : "RFC1700
- references"
-
- o : "inconsistency
- in date format explanation"
-
- o : "Date reference
- typo"
-
- o : "Informative
- references"
-
- o : "ISO-8859-1
- Reference"
-
- o : "Normative up-
- to-date references"
-
- Other changes:
-
- o Update media type registrations to use RFC4288 template.
-
- o Use names of RFC4234 core rules DQUOTE and WSP, fix broken ABNF
- for chunk-data (work in progress on
- )
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 79]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
-D.3. Since draft-ietf-httpbis-p1-messaging-01
-
- Closed issues:
-
- o : "Bodies on GET
- (and other) requests"
-
- o : "Updating to
- RFC4288"
-
- o : "Status Code
- and Reason Phrase"
-
- o : "rel_path not
- used"
-
- Ongoing work on ABNF conversion
- ():
-
- o Get rid of duplicate BNF rule names ("host" -> "uri-host",
- "trailer" -> "trailer-part").
-
- o Avoid underscore character in rule names ("http_URL" -> "http-
- URL", "abs_path" -> "path-absolute").
-
- o Add rules for terms imported from URI spec ("absoluteURI",
- "authority", "path-absolute", "port", "query", "relativeURI",
- "host) -- these will have to be updated when switching over to
- RFC3986.
-
- o Synchronize core rules with RFC5234.
-
- o Get rid of prose rules that span multiple lines.
-
- o Get rid of unused rules LOALPHA and UPALPHA.
-
- o Move "Product Tokens" section (back) into Part 1, as "token" is
- used in the definition of the Upgrade header.
-
- o Add explicit references to BNF syntax and rules imported from
- other parts of the specification.
-
- o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule
- "TEXT".
-
-
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 80]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
-D.4. Since draft-ietf-httpbis-p1-messaging-02
-
- Closed issues:
-
- o : "HTTP-date vs.
- rfc1123-date"
-
- o : "WS in quoted-
- pair"
-
- Ongoing work on IANA Message Header Registration
- ():
-
- o Reference RFC 3984, and update header registrations for headers
- defined in this document.
-
- Ongoing work on ABNF conversion
- ():
-
- o Replace string literals when the string really is case-sensitive
- (HTTP-Version).
-
-D.5. Since draft-ietf-httpbis-p1-messaging-03
-
- Closed issues:
-
- o : "Connection
- closing"
-
- o : "Move
- registrations and registry information to IANA Considerations"
-
- o : "need new URL
- for PAD1995 reference"
-
- o : "IANA
- Considerations: update HTTP URI scheme registration"
-
- o : "Cite HTTPS
- URI scheme definition"
-
- o : "List-type
- headers vs Set-Cookie"
-
- Ongoing work on ABNF conversion
- ():
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 81]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- o Replace string literals when the string really is case-sensitive
- (HTTP-Date).
-
- o Replace HEX by HEXDIG for future consistence with RFC 5234's core
- rules.
-
-D.6. Since draft-ietf-httpbis-p1-messaging-04
-
- Closed issues:
-
- o : "Out-of-date
- reference for URIs"
-
- o : "RFC 2822 is
- updated by RFC 5322"
-
- Ongoing work on ABNF conversion
- ():
-
- o Use "/" instead of "|" for alternatives.
-
- o Get rid of RFC822 dependency; use RFC5234 plus extensions instead.
-
- o Only reference RFC 5234's core rules.
-
- o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
- whitespace ("OWS") and required whitespace ("RWS").
-
- o Rewrite ABNFs to spell out whitespace rules, factor out header
- value format definitions.
-
-D.7. Since draft-ietf-httpbis-p1-messaging-05
-
- Closed issues:
-
- o : "Header LWS"
-
- o : "Sort 1.3
- Terminology"
-
- o : "RFC2047
- encoded words"
-
- o : "Character
- Encodings in TEXT"
-
- o : "Line Folding"
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 82]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- o : "OPTIONS * and
- proxies"
-
- o : "Reason-Phrase
- BNF"
-
- o : "Use of TEXT"
-
- o : "Join
- "Differences Between HTTP Entities and RFC 2045 Entities"?"
-
- o : "RFC822
- reference left in discussion of date formats"
-
- Final work on ABNF conversion
- ():
-
- o Rewrite definition of list rules, deprecate empty list elements.
-
- o Add appendix containing collected and expanded ABNF.
-
- Other changes:
-
- o Rewrite introduction; add mostly new Architecture Section.
-
- o Move definition of quality values from Part 3 into Part 1; make TE
- request header grammar independent of accept-params (defined in
- Part 3).
-
-D.8. Since draft-ietf-httpbis-p1-messaging-06
-
- Closed issues:
-
- o : "base for
- numeric protocol elements"
-
- o : "comment ABNF"
-
- Partly resolved issues:
-
- o : "205 Bodies"
- (took out language that implied that there might be methods for
- which a request body MUST NOT be included)
-
- o : "editorial
- improvements around HTTP-date"
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 83]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
-D.9. Since draft-ietf-httpbis-p1-messaging-07
-
- Closed issues:
-
- o : "Repeating
- single-value headers"
-
- o : "increase
- connection limit"
-
- o : "IP addresses
- in URLs"
-
- o : "take over
- HTTP Upgrade Token Registry"
-
- o : "CR and LF in
- chunk extension values"
-
- o : "HTTP/0.9
- support"
-
- o : "pick IANA
- policy (RFC5226) for Transfer Coding / Content Coding"
-
- o : "move
- definitions of gzip/deflate/compress to part 1"
-
- o : "disallow
- control characters in quoted-pair"
-
- Partly resolved issues:
-
- o : "update IANA
- requirements wrt Transfer-Coding values" (add the IANA
- Considerations subsection)
-
-D.10. Since draft-ietf-httpbis-p1-messaging-08
-
- Closed issues:
-
- o : "header
- parsing, treatment of leading and trailing OWS"
-
- Partly resolved issues:
-
- o : "Placement of
- 13.5.1 and 13.5.2"
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 84]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- o : "use of term
- "word" when talking about header structure"
-
-D.11. Since draft-ietf-httpbis-p1-messaging-09
-
- Closed issues:
-
- o : "Clarification
- of the term 'deflate'"
-
- o : "OPTIONS * and
- proxies"
-
- o : "MIME-Version
- not listed in P1, general header fields"
-
- o : "IANA registry
- for content/transfer encodings"
-
- o : "Case-
- sensitivity of HTTP-date"
-
- o : "use of term
- "word" when talking about header structure"
-
- Partly resolved issues:
-
- o : "Term for the
- requested resource's URI"
-
-D.12. Since draft-ietf-httpbis-p1-messaging-10
-
- Closed issues:
-
- o : "Connection
- Closing"
-
- o : "Delimiting
- messages with multipart/byteranges"
-
- o : "Handling
- multiple Content-Length headers"
-
- o : "Clarify
- entity / representation / variant terminology"
-
- o : "consider
- removing the 'changes from 2068' sections"
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 85]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- Partly resolved issues:
-
- o : "HTTP(s) URI
- scheme definitions"
-
-Index
-
- A
- application/http Media Type 61
-
- B
- browser 10
-
- C
- cache 13
- cacheable 14
- chunked (Coding Format) 35
- client 10
- Coding Format
- chunked 35
- compress 38
- deflate 38
- gzip 38
- compress (Coding Format) 38
- connection 10
- Connection header 49
- Content-Length header 50
-
- D
- Date header 51
- deflate (Coding Format) 38
- downstream 12
-
- E
- effective request URI 29
-
- G
- gateway 13
- Grammar
- absolute-URI 16
- ALPHA 7
- asctime-date 34
- attribute 34
- authority 16
- BWS 9
- chunk 35
- chunk-data 35
- chunk-ext 35
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 86]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- chunk-ext-name 35
- chunk-ext-val 35
- chunk-size 35
- Chunked-Body 35
- comment 22
- Connection 49
- connection-token 49
- Connection-v 49
- Content-Length 50
- Content-Length-v 50
- CR 7
- CRLF 7
- ctext 22
- CTL 7
- Date 51
- Date-v 51
- date1 33
- date2 34
- date3 34
- day 33
- day-name 33
- day-name-l 33
- DIGIT 7
- DQUOTE 7
- extension-code 32
- extension-method 26
- field-content 20
- field-name 20
- field-value 20
- general-header 26
- GMT 33
- header-field 20
- HEXDIG 7
- Host 52
- Host-v 52
- hour 33
- HTTP-date 32
- HTTP-message 19
- HTTP-Prot-Name 15
- http-URI 16
- HTTP-Version 15
- https-URI 18
- last-chunk 35
- LF 7
- message-body 22
- Method 26
- minute 33
- month 33
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 87]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- obs-date 33
- obs-text 10
- OCTET 7
- OWS 9
- path-absolute 16
- port 16
- product 39
- product-version 39
- protocol-name 57
- protocol-version 57
- pseudonym 57
- qdtext 10
- qdtext-nf 35
- query 16
- quoted-cpair 22
- quoted-pair 10
- quoted-str-nf 35
- quoted-string 10
- qvalue 39
- Reason-Phrase 32
- received-by 57
- received-protocol 57
- Request 26
- Request-Line 26
- request-target 27
- Response 31
- rfc850-date 34
- rfc1123-date 33
- RWS 9
- second 33
- SP 7
- special 9
- Status-Code 32
- Status-Line 31
- t-codings 53
- tchar 9
- TE 53
- te-ext 53
- te-params 53
- TE-v 53
- time-of-day 33
- token 9
- Trailer 54
- trailer-part 35
- Trailer-v 54
- transfer-coding 34
- Transfer-Encoding 55
- Transfer-Encoding-v 55
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 88]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- transfer-extension 34
- transfer-parameter 34
- Upgrade 55
- Upgrade-v 55
- uri-host 16
- URI-reference 16
- value 34
- VCHAR 7
- Via 57
- Via-v 57
- word 9
- WSP 7
- year 33
- gzip (Coding Format) 38
-
- H
- header field 19
- header section 19
- Headers
- Connection 49
- Content-Length 50
- Date 51
- Host 52
- TE 53
- Trailer 54
- Transfer-Encoding 55
- Upgrade 55
- Via 57
- headers 19
- Host header 52
- http URI scheme 16
- https URI scheme 18
-
- I
- inbound 12
- intermediary 12
-
- M
- Media Type
- application/http 61
- message/http 59
- message 11
- message/http Media Type 59
-
- O
- origin server 10
- outbound 12
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 89]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- P
- proxy 12
-
- R
- request 11
- resource 16
- response 11
- reverse proxy 13
-
- S
- server 10
- spider 10
-
- T
- target resource 29
- TE header 53
- Trailer header 54
- Transfer-Encoding header 55
- tunnel 13
-
- U
- Upgrade header 55
- upstream 12
- URI scheme
- http 16
- https 18
- user agent 10
-
- V
- Via header 57
-
-Authors' Addresses
-
- Roy T. Fielding (editor)
- Day Software
- 23 Corporate Plaza DR, Suite 280
- Newport Beach, CA 92660
- USA
-
- Phone: +1-949-706-5300
- Fax: +1-949-706-5305
- EMail: fielding@gbiv.com
- URI: http://roy.gbiv.com/
-
-
-
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 90]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- Jim Gettys
- Alcatel-Lucent Bell Labs
- 21 Oak Knoll Road
- Carlisle, MA 01741
- USA
-
- EMail: jg@freedesktop.org
- URI: http://gettys.wordpress.com/
-
-
- Jeffrey C. Mogul
- Hewlett-Packard Company
- HP Labs, Large Scale Systems Group
- 1501 Page Mill Road, MS 1177
- Palo Alto, CA 94304
- USA
-
- EMail: JeffMogul@acm.org
-
-
- Henrik Frystyk Nielsen
- Microsoft Corporation
- 1 Microsoft Way
- Redmond, WA 98052
- USA
-
- EMail: henrikn@microsoft.com
-
-
- Larry Masinter
- Adobe Systems, Incorporated
- 345 Park Ave
- San Jose, CA 95110
- USA
-
- EMail: LMM@acm.org
- URI: http://larry.masinter.net/
-
-
- Paul J. Leach
- Microsoft Corporation
- 1 Microsoft Way
- Redmond, WA 98052
-
- EMail: paulle@microsoft.com
-
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 91]
-
-Internet-Draft HTTP/1.1, Part 1 August 2010
-
-
- Tim Berners-Lee
- World Wide Web Consortium
- MIT Computer Science and Artificial Intelligence Laboratory
- The Stata Center, Building 32
- 32 Vassar Street
- Cambridge, MA 02139
- USA
-
- EMail: timbl@w3.org
- URI: http://www.w3.org/People/Berners-Lee/
-
-
- Yves Lafon (editor)
- World Wide Web Consortium
- W3C / ERCIM
- 2004, rte des Lucioles
- Sophia-Antipolis, AM 06902
- France
-
- EMail: ylafon@w3.org
- URI: http://www.raubacapeu.net/people/yves/
-
-
- Julian F. Reschke (editor)
- greenbytes GmbH
- Hafenweg 16
- Muenster, NW 48155
- Germany
-
- Phone: +49 251 2807760
- Fax: +49 251 2807761
- EMail: julian.reschke@greenbytes.de
- URI: http://greenbytes.de/tech/webdav/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 92]
-
diff --git a/vendor/sabre/dav/docs/draft-ietf-httpbis-p4-conditional-11.txt b/vendor/sabre/dav/docs/draft-ietf-httpbis-p4-conditional-11.txt
deleted file mode 100644
index 2dd1b7fc2..000000000
--- a/vendor/sabre/dav/docs/draft-ietf-httpbis-p4-conditional-11.txt
+++ /dev/null
@@ -1,1512 +0,0 @@
-
-
-
-HTTPbis Working Group R. Fielding, Ed.
-Internet-Draft Day Software
-Obsoletes: 2616 (if approved) J. Gettys
-Intended status: Standards Track Alcatel-Lucent
-Expires: February 5, 2011 J. Mogul
- HP
- H. Frystyk
- Microsoft
- L. Masinter
- Adobe Systems
- P. Leach
- Microsoft
- T. Berners-Lee
- W3C/MIT
- Y. Lafon, Ed.
- W3C
- J. Reschke, Ed.
- greenbytes
- August 4, 2010
-
-
- HTTP/1.1, part 4: Conditional Requests
- draft-ietf-httpbis-p4-conditional-11
-
-Abstract
-
- The Hypertext Transfer Protocol (HTTP) is an application-level
- protocol for distributed, collaborative, hypermedia information
- systems. HTTP has been in use by the World Wide Web global
- information initiative since 1990. This document is Part 4 of the
- seven-part specification that defines the protocol referred to as
- "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines
- request header fields for indicating conditional requests and the
- rules for constructing responses to those requests.
-
-Editorial Note (To be removed by RFC Editor)
-
- Discussion of this draft should take place on the HTTPBIS working
- group mailing list (ietf-http-wg@w3.org). The current issues list is
- at and related
- documents (including fancy diffs) can be found at
- .
-
- The changes in this draft are summarized in Appendix C.12.
-
-Status of This Memo
-
- This Internet-Draft is submitted in full conformance with the
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 1]
-
-Internet-Draft HTTP/1.1, Part 4 August 2010
-
-
- provisions of BCP 78 and BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF). Note that other groups may also distribute
- working documents as Internet-Drafts. The list of current Internet-
- Drafts is at http://datatracker.ietf.org/drafts/current/.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- This Internet-Draft will expire on February 5, 2011.
-
-Copyright Notice
-
- Copyright (c) 2010 IETF Trust and the persons identified as the
- document authors. All rights reserved.
-
- This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents
- (http://trustee.ietf.org/license-info) in effect on the date of
- publication of this document. Please review these documents
- carefully, as they describe your rights and restrictions with respect
- to this document. Code Components extracted from this document must
- include Simplified BSD License text as described in Section 4.e of
- the Trust Legal Provisions and are provided without warranty as
- described in the Simplified BSD License.
-
- This document may contain material from IETF Documents or IETF
- Contributions published or made publicly available before November
- 10, 2008. The person(s) controlling the copyright in some of this
- material may not have granted the IETF Trust the right to allow
- modifications of such material outside the IETF Standards Process.
- Without obtaining an adequate license from the person(s) controlling
- the copyright in such materials, this document may not be modified
- outside the IETF Standards Process, and derivative works of it may
- not be created outside the IETF Standards Process, except to format
- it for publication as an RFC or to translate it into languages other
- than English.
-
-
-
-
-
-
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 2]
-
-Internet-Draft HTTP/1.1, Part 4 August 2010
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4
- 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5
- 1.2.2. ABNF Rules defined in other Parts of the
- Specification . . . . . . . . . . . . . . . . . . . . 5
- 2. Entity-Tags . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 2.1. Example: Entity-tags varying on Content-Negotiated
- Resources . . . . . . . . . . . . . . . . . . . . . . . . 6
- 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7
- 3.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 7
- 3.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 7
- 4. Weak and Strong Validators . . . . . . . . . . . . . . . . . . 8
- 5. Rules for When to Use Entity-tags and Last-Modified Dates . . 10
- 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 12
- 6.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
- 6.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 13
- 6.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 14
- 6.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 16
- 6.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 17
- 6.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 18
- 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
- 7.1. Status Code Registration . . . . . . . . . . . . . . . . . 19
- 7.2. Header Field Registration . . . . . . . . . . . . . . . . 19
- 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
- 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
- 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
- 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
- 10.2. Informative References . . . . . . . . . . . . . . . . . . 20
- Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 20
- Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 21
- Appendix C. Change Log (to be removed by RFC Editor before
- publication) . . . . . . . . . . . . . . . . . . . . 21
- C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 21
- C.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 22
- C.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 22
- C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 22
- C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 22
- C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 23
- C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 23
- C.8. Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 23
- C.9. Since draft-ietf-httpbis-p4-conditional-07 . . . . . . . . 23
- C.10. Since draft-ietf-httpbis-p4-conditional-08 . . . . . . . . 23
- C.11. Since draft-ietf-httpbis-p4-conditional-09 . . . . . . . . 23
- C.12. Since draft-ietf-httpbis-p4-conditional-10 . . . . . . . . 24
- Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 3]
-
-Internet-Draft HTTP/1.1, Part 4 August 2010
-
-
-1. Introduction
-
- This document defines HTTP/1.1 response metadata for indicating
- potential changes to payload content, including modification time
- stamps and opaque entity-tags, and the HTTP conditional request
- mechanisms that allow preconditions to be placed on a request method.
- Conditional GET requests allow for efficient cache updates. Other
- conditional request methods are used to protect against overwriting
- or misunderstanding the state of a resource that has been changed
- unbeknownst to the requesting client.
-
- This document is currently disorganized in order to minimize the
- changes between drafts and enable reviewers to see the smaller errata
- changes. The next draft will reorganize the sections to better
- reflect the content. In particular, the sections on resource
- metadata will be discussed first and then followed by each
- conditional request-header, concluding with a definition of
- precedence and the expectation of ordering strong validator checks
- before weak validator checks. It is likely that more content from
- [Part6] will migrate to this part, where appropriate. The current
- mess reflects how widely dispersed these topics and associated
- requirements had become in [RFC2616].
-
-1.1. Requirements
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
- An implementation is not compliant if it fails to satisfy one or more
- of the "MUST" or "REQUIRED" level requirements for the protocols it
- implements. An implementation that satisfies all the "MUST" or
- "REQUIRED" level and all the "SHOULD" level requirements for its
- protocols is said to be "unconditionally compliant"; one that
- satisfies all the "MUST" level requirements but not all the "SHOULD"
- level requirements for its protocols is said to be "conditionally
- compliant".
-
-1.2. Syntax Notation
-
- This specification uses the ABNF syntax defined in Section 1.2 of
- [Part1] (which extends the syntax defined in [RFC5234] with a list
- rule). Appendix B shows the collected ABNF, with the list rule
- expanded.
-
- The following core rules are included by reference, as defined in
- [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
- (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 4]
-
-Internet-Draft HTTP/1.1, Part 4 August 2010
-
-
- HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
- sequence of data), SP (space), VCHAR (any visible USASCII character),
- and WSP (whitespace).
-
-1.2.1. Core Rules
-
- The core rules below are defined in Section 1.2.2 of [Part1]:
-
- quoted-string =
- OWS =
-
-1.2.2. ABNF Rules defined in other Parts of the Specification
-
- The ABNF rules below are defined in other parts:
-
- HTTP-date =
-
-2. Entity-Tags
-
- Entity-tags are used for comparing two or more representations of the
- same resource. HTTP/1.1 uses entity-tags in the ETag (Section 6.1),
- If-Match (Section 6.2), If-None-Match (Section 6.4), and If-Range
- (Section 5.3 of [Part5]) header fields. The definition of how they
- are used and compared as cache validators is in Section 4. An
- entity-tag consists of an opaque quoted string, possibly prefixed by
- a weakness indicator.
-
- entity-tag = [ weak ] opaque-tag
- weak = %x57.2F ; "W/", case-sensitive
- opaque-tag = quoted-string
-
- A "strong entity-tag" MAY be shared by two representations of a
- resource only if they are equivalent by octet equality.
-
- A "weak entity-tag", indicated by the "W/" prefix, MAY be shared by
- two representations of a resource only if the representations are
- equivalent and could be substituted for each other with no
- significant change in semantics. A weak entity-tag can only be used
- for weak comparison.
-
- An entity-tag MUST be unique across all versions of all
- representations associated with a particular resource. A given
- entity-tag value MAY be used for representations obtained by requests
- on different URIs. The use of the same entity-tag value in
- conjunction with representations obtained by requests on different
- URIs does not imply the equivalence of those representations.
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 5]
-
-Internet-Draft HTTP/1.1, Part 4 August 2010
-
-
-2.1. Example: Entity-tags varying on Content-Negotiated Resources
-
- Consider a resource that is subject to content negotiation (Section 5
- of [Part3]), and where the representations returned upon a GET
- request vary based on the Accept-Encoding request header field
- (Section 6.3 of [Part3]):
-
- >> Request:
-
- GET /index HTTP/1.1
- Host: www.example.com
- Accept-Encoding: gzip
-
-
- In this case, the response might or might not use the gzip content
- coding. If it does not, the response might look like:
-
- >> Response:
-
- HTTP/1.1 200 OK
- Date: Thu, 26 Mar 2010 00:05:00 GMT
- ETag: "123-a"
- Content-Length: 70
- Vary: Accept-Encoding
- Content-Type: text/plain
-
- Hello World!
- Hello World!
- Hello World!
- Hello World!
- Hello World!
-
- An alternative representation that does use gzip content coding would
- be:
-
- >> Response:
-
- HTTP/1.1 200 OK
- Date: Thu, 26 Mar 2010 00:05:00 GMT
- ETag: "123-b"
- Content-Length: 43
- Vary: Accept-Encoding
- Content-Type: text/plain
- Content-Encoding: gzip
-
- ...binary data...
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 6]
-
-Internet-Draft HTTP/1.1, Part 4 August 2010
-
-
- Note: Content codings are a property of the representation, so
- therefore an entity-tag of an encoded representation must be
- distinct from an unencoded representation to prevent conflicts
- during cache updates and range requests. In contrast, transfer
- codings (Section 6.2 of [Part1]) apply only during message
- transfer and do not require distinct entity-tags.
-
-3. Status Code Definitions
-
-3.1. 304 Not Modified
-
- If the client has performed a conditional GET request and access is
- allowed, but the document has not been modified, the server SHOULD
- respond with this status code. The 304 response MUST NOT contain a
- message-body, and thus is always terminated by the first empty line
- after the header fields.
-
- A 304 response MUST include a Date header field (Section 9.3 of
- [Part1]) unless its omission is required by Section 9.3.1 of [Part1].
- If a 200 response to the same request would have included any of the
- header fields Cache-Control, Content-Location, ETag, Expires, Last-
- Modified, or Vary, then those same header fields MUST be sent in a
- 304 response.
-
- Since the goal of a 304 response is to minimize information transfer
- when the recipient already has one or more cached representations,
- the response SHOULD NOT include representation metadata other than
- the above listed fields unless said metadata exists for the purpose
- of guiding cache updates (e.g., future HTTP extensions).
-
- If a 304 response includes an entity-tag that indicates a
- representation not currently cached, then the recipient MUST NOT use
- the 304 to update its own cache. If that conditional request
- originated with an outbound client, such as a user agent with its own
- cache sending a conditional GET to a shared proxy, then the 304
- response MAY be forwarded to the outbound client. Otherwise,
- disregard the response and repeat the request without the
- conditional.
-
- If a cache uses a received 304 response to update a cache entry, the
- cache MUST update the entry to reflect any new field values given in
- the response.
-
-3.2. 412 Precondition Failed
-
- The precondition given in one or more of the request-header fields
- evaluated to false when it was tested on the server. This response
- code allows the client to place preconditions on the current resource
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 7]
-
-Internet-Draft HTTP/1.1, Part 4 August 2010
-
-
- metadata (header field data) and thus prevent the requested method
- from being applied to a resource other than the one intended.
-
-4. Weak and Strong Validators
-
- Since both origin servers and caches will compare two validators to
- decide if they represent the same or different representations, one
- normally would expect that if the representation (including both
- representation header fields and representation body) changes in any
- way, then the associated validator would change as well. If this is
- true, then we call this validator a "strong validator".
-
- However, there might be cases when a server prefers to change the
- validator only on semantically significant changes, and not when
- insignificant aspects of the representation change. A validator that
- does not always change when the representation changes is a "weak
- validator".
-
- An entity-tag is normally a strong validator, but the protocol
- provides a mechanism to tag an entity-tag as "weak". One can think
- of a strong validator as one that changes whenever the sequence of
- bits in a representation changes, while a weak value changes whenever
- the meaning of a representation changes. Alternatively, one can
- think of a strong validator as part of an identifier for a specific
- representation, whereas a weak validator is part of an identifier for
- a set of semantically equivalent representations.
-
- Note: One example of a strong validator is an integer that is
- incremented in stable storage every time a representation is
- changed.
-
- A representation's modification time, if defined with only one-
- second resolution, could be a weak validator, since it is possible
- that the representation might be modified twice during a single
- second.
-
- Support for weak validators is optional. However, weak validators
- allow for more efficient caching of equivalent objects; for
- example, a hit counter on a site is probably good enough if it is
- updated every few days or weeks, and any value during that period
- is likely "good enough" to be equivalent.
-
- A "use" of a validator is either when a client generates a request
- and includes the validator in a validating header field, or when a
- server compares two validators.
-
- Strong validators are usable in any context. Weak validators are
- only usable in contexts that do not depend on exact equality of a
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 8]
-
-Internet-Draft HTTP/1.1, Part 4 August 2010
-
-
- representation. For example, either kind is usable for a normal
- conditional GET. However, only a strong validator is usable for a
- sub-range retrieval, since otherwise the client might end up with an
- internally inconsistent representation.
-
- Clients MUST NOT use weak validators in range requests ([Part5]).
-
- The only function that HTTP/1.1 defines on validators is comparison.
- There are two validator comparison functions, depending on whether
- the comparison context allows the use of weak validators or not:
-
- o The strong comparison function: in order to be considered equal,
- both opaque-tags MUST be identical character-by-character, and
- both MUST NOT be weak.
-
- o The weak comparison function: in order to be considered equal,
- both opaque-tags MUST be identical character-by-character, but
- either or both of them MAY be tagged as "weak" without affecting
- the result.
-
- The example below shows the results for a set of entity-tag pairs,
- and both the weak and strong comparison function results:
-
- +--------+--------+-------------------+-----------------+
- | ETag 1 | ETag 2 | Strong Comparison | Weak Comparison |
- +--------+--------+-------------------+-----------------+
- | W/"1" | W/"1" | no match | match |
- | W/"1" | W/"2" | no match | no match |
- | W/"1" | "1" | no match | match |
- | "1" | "1" | match | match |
- +--------+--------+-------------------+-----------------+
-
- An entity-tag is strong unless it is explicitly tagged as weak.
- Section 2 gives the syntax for entity-tags.
-
- A Last-Modified time, when used as a validator in a request, is
- implicitly weak unless it is possible to deduce that it is strong,
- using the following rules:
-
- o The validator is being compared by an origin server to the actual
- current validator for the representation and,
-
- o That origin server reliably knows that the associated
- representation did not change twice during the second covered by
- the presented validator.
-
- or
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 9]
-
-Internet-Draft HTTP/1.1, Part 4 August 2010
-
-
- o The validator is about to be used by a client in an If-Modified-
- Since or If-Unmodified-Since header, because the client has a
- cache entry for the associated representation, and
-
- o That cache entry includes a Date value, which gives the time when
- the origin server sent the original response, and
-
- o The presented Last-Modified time is at least 60 seconds before the
- Date value.
-
- or
-
- o The validator is being compared by an intermediate cache to the
- validator stored in its cache entry for the representation, and
-
- o That cache entry includes a Date value, which gives the time when
- the origin server sent the original response, and
-
- o The presented Last-Modified time is at least 60 seconds before the
- Date value.
-
- This method relies on the fact that if two different responses were
- sent by the origin server during the same second, but both had the
- same Last-Modified time, then at least one of those responses would
- have a Date value equal to its Last-Modified time. The arbitrary 60-
- second limit guards against the possibility that the Date and Last-
- Modified values are generated from different clocks, or at somewhat
- different times during the preparation of the response. An
- implementation MAY use a value larger than 60 seconds, if it is
- believed that 60 seconds is too short.
-
- If a client wishes to perform a sub-range retrieval on a value for
- which it has only a Last-Modified time and no opaque validator, it
- MAY do this only if the Last-Modified time is strong in the sense
- described here.
-
- A cache or origin server receiving a conditional range request
- ([Part5]) MUST use the strong comparison function to evaluate the
- condition.
-
- These rules allow HTTP/1.1 caches and clients to safely perform sub-
- range retrievals on values that have been obtained from HTTP/1.0
- servers.
-
-5. Rules for When to Use Entity-tags and Last-Modified Dates
-
- We adopt a set of rules and recommendations for origin servers,
- clients, and caches regarding when various validator types ought to
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 10]
-
-Internet-Draft HTTP/1.1, Part 4 August 2010
-
-
- be used, and for what purposes.
-
- HTTP/1.1 origin servers:
-
- o SHOULD send an entity-tag validator unless it is not feasible to
- generate one.
-
- o MAY send a weak entity-tag instead of a strong entity-tag, if
- performance considerations support the use of weak entity-tags, or
- if it is unfeasible to send a strong entity-tag.
-
- o SHOULD send a Last-Modified value if it is feasible to send one,
- unless the risk of a breakdown in semantic transparency that could
- result from using this date in an If-Modified-Since header would
- lead to serious problems.
-
- In other words, the preferred behavior for an HTTP/1.1 origin server
- is to send both a strong entity-tag and a Last-Modified value.
-
- In order to be legal, a strong entity-tag MUST change whenever the
- associated representation changes in any way. A weak entity-tag
- SHOULD change whenever the associated representation changes in a
- semantically significant way.
-
- Note: In order to provide semantically transparent caching, an
- origin server must avoid reusing a specific strong entity-tag
- value for two different representations, or reusing a specific
- weak entity-tag value for two semantically different
- representations. Cache entries might persist for arbitrarily long
- periods, regardless of expiration times, so it might be
- inappropriate to expect that a cache will never again attempt to
- validate an entry using a validator that it obtained at some point
- in the past.
-
- HTTP/1.1 clients:
-
- o MUST use that entity-tag in any cache-conditional request (using
- If-Match or If-None-Match) if an entity-tag has been provided by
- the origin server.
-
- o SHOULD use the Last-Modified value in non-subrange cache-
- conditional requests (using If-Modified-Since) if only a Last-
- Modified value has been provided by the origin server.
-
- o MAY use the Last-Modified value in subrange cache-conditional
- requests (using If-Unmodified-Since) if only a Last-Modified value
- has been provided by an HTTP/1.0 origin server. The user agent
- SHOULD provide a way to disable this, in case of difficulty.
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 11]
-
-Internet-Draft HTTP/1.1, Part 4 August 2010
-
-
- o SHOULD use both validators in cache-conditional requests if both
- an entity-tag and a Last-Modified value have been provided by the
- origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to
- respond appropriately.
-
- An HTTP/1.1 origin server, upon receiving a conditional request that
- includes both a Last-Modified date (e.g., in an If-Modified-Since or
- If-Unmodified-Since header field) and one or more entity-tags (e.g.,
- in an If-Match, If-None-Match, or If-Range header field) as cache
- validators, MUST NOT return a response status code of 304 (Not
- Modified) unless doing so is consistent with all of the conditional
- header fields in the request.
-
- An HTTP/1.1 caching proxy, upon receiving a conditional request that
- includes both a Last-Modified date and one or more entity-tags as
- cache validators, MUST NOT return a locally cached response to the
- client unless that cached response is consistent with all of the
- conditional header fields in the request.
-
- Note: The general principle behind these rules is that HTTP/1.1
- servers and clients ought to transmit as much non-redundant
- information as is available in their responses and requests.
- HTTP/1.1 systems receiving this information will make the most
- conservative assumptions about the validators they receive.
-
- HTTP/1.0 clients and caches will ignore entity-tags. Generally,
- last-modified values received or used by these systems will
- support transparent and efficient caching, and so HTTP/1.1 origin
- servers should provide Last-Modified values. In those rare cases
- where the use of a Last-Modified value as a validator by an
- HTTP/1.0 system could result in a serious problem, then HTTP/1.1
- origin servers should not provide one.
-
-6. Header Field Definitions
-
- This section defines the syntax and semantics of HTTP/1.1 header
- fields related to conditional requests.
-
-6.1. ETag
-
- The "ETag" response-header field provides the current value of the
- entity-tag (see Section 2) for one representation of the target
- resource. An entity-tag is intended for use as a resource-local
- identifier for differentiating between representations of the same
- resource that vary over time or via content negotiation (see
- Section 4).
-
- ETag = "ETag" ":" OWS ETag-v
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 12]
-
-Internet-Draft HTTP/1.1, Part 4 August 2010
-
-
- ETag-v = entity-tag
-
- Examples:
-
- ETag: "xyzzy"
- ETag: W/"xyzzy"
- ETag: ""
-
- An entity-tag provides an "opaque" cache validator that allows for
- more reliable validation than modification dates in situations where
- it is inconvenient to store modification dates, where the one-second
- resolution of HTTP date values is not sufficient, or where the origin
- server wishes to avoid certain paradoxes that might arise from the
- use of modification dates.
-
- The principle behind entity-tags is that only the service author
- knows the semantics of a resource well enough to select an
- appropriate cache validation mechanism, and the specification of any
- validator comparison function more complex than byte-equality would
- open up a can of worms. Thus, comparisons of any other headers
- (except Last-Modified, for compatibility with HTTP/1.0) are never
- used for purposes of validating a cache entry.
-
-6.2. If-Match
-
- The "If-Match" request-header field is used to make a request method
- conditional. A client that has one or more representations
- previously obtained from the resource can verify that one of those
- representations is current by including a list of their associated
- entity-tags in the If-Match header field.
-
- This allows efficient updates of cached information with a minimum
- amount of transaction overhead. It is also used when updating
- resources, to prevent inadvertent modification of the wrong version
- of a resource. As a special case, the value "*" matches any current
- representation of the resource.
-
- If-Match = "If-Match" ":" OWS If-Match-v
- If-Match-v = "*" / 1#entity-tag
-
- If any of the entity-tags match the entity-tag of the representation
- that would have been returned in the response to a similar GET
- request (without the If-Match header) on that resource, or if "*" is
- given and any current representation exists for that resource, then
- the server MAY perform the requested method as if the If-Match header
- field did not exist.
-
- If none of the entity-tags match, or if "*" is given and no current
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 13]
-
-Internet-Draft HTTP/1.1, Part 4 August 2010
-
-
- representation exists, the server MUST NOT perform the requested
- method, and MUST return a 412 (Precondition Failed) response. This
- behavior is most useful when the client wants to prevent an updating
- method, such as PUT, from modifying a resource that has changed since
- the client last retrieved it.
-
- If the request would, without the If-Match header field, result in
- anything other than a 2xx or 412 status code, then the If-Match
- header MUST be ignored.
-
- The meaning of "If-Match: *" is that the method SHOULD be performed
- if the representation selected by the origin server (or by a cache,
- possibly using the Vary mechanism, see Section 3.5 of [Part6])
- exists, and MUST NOT be performed if the representation does not
- exist.
-
- A request intended to update a resource (e.g., a PUT) MAY include an
- If-Match header field to signal that the request method MUST NOT be
- applied if the representation corresponding to the If-Match value (a
- single entity-tag) is no longer a representation of that resource.
- This allows the user to indicate that they do not wish the request to
- be successful if the resource has been changed without their
- knowledge. Examples:
-
- If-Match: "xyzzy"
- If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
- If-Match: *
-
- The result of a request having both an If-Match header field and
- either an If-None-Match or an If-Modified-Since header fields is
- undefined by this specification.
-
-6.3. If-Modified-Since
-
- The "If-Modified-Since" request-header field is used to make a
- request method conditional by date: if the representation that would
- have been transferred in a 200 response to a GET request has not been
- modified since the time specified in this field, then do not perform
- the method; instead, respond as detailed below.
-
- If-Modified-Since = "If-Modified-Since" ":" OWS
- If-Modified-Since-v
- If-Modified-Since-v = HTTP-date
-
- An example of the field is:
-
- If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 14]
-
-Internet-Draft HTTP/1.1, Part 4 August 2010
-
-
- A GET method with an If-Modified-Since header and no Range header
- requests that the representation be transferred only if it has been
- modified since the date given by the If-Modified-Since header. The
- algorithm for determining this includes the following cases:
-
- 1. If the request would normally result in anything other than a 200
- (OK) status code, or if the passed If-Modified-Since date is
- invalid, the response is exactly the same as for a normal GET. A
- date which is later than the server's current time is invalid.
-
- 2. If the representation has been modified since the If-Modified-
- Since date, the response is exactly the same as for a normal GET.
-
- 3. If the representation has not been modified since a valid If-
- Modified-Since date, the server SHOULD return a 304 (Not
- Modified) response.
-
- The purpose of this feature is to allow efficient updates of cached
- information with a minimum amount of transaction overhead.
-
- Note: The Range request-header field modifies the meaning of If-
- Modified-Since; see Section 5.4 of [Part5] for full details.
-
- Note: If-Modified-Since times are interpreted by the server, whose
- clock might not be synchronized with the client.
-
- Note: When handling an If-Modified-Since header field, some
- servers will use an exact date comparison function, rather than a
- less-than function, for deciding whether to send a 304 (Not
- Modified) response. To get best results when sending an If-
- Modified-Since header field for cache validation, clients are
- advised to use the exact date string received in a previous Last-
- Modified header field whenever possible.
-
- Note: If a client uses an arbitrary date in the If-Modified-Since
- header instead of a date taken from the Last-Modified header for
- the same request, the client needs to be aware that this date is
- interpreted in the server's understanding of time. Unsynchronized
- clocks and rounding problems, due to the different encodings of
- time between the client and server, are concerns. This includes
- the possibility of race conditions if the document has changed
- between the time it was first requested and the If-Modified-Since
- date of a subsequent request, and the possibility of clock-skew-
- related problems if the If-Modified-Since date is derived from the
- client's clock without correction to the server's clock.
- Corrections for different time bases between client and server are
- at best approximate due to network latency.
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 15]
-
-Internet-Draft HTTP/1.1, Part 4 August 2010
-
-
- The result of a request having both an If-Modified-Since header field
- and either an If-Match or an If-Unmodified-Since header fields is
- undefined by this specification.
-
-6.4. If-None-Match
-
- The "If-None-Match" request-header field is used to make a request
- method conditional. A client that has one or more representations
- previously obtained from the resource can verify that none of those
- representations is current by including a list of their associated
- entity-tags in the If-None-Match header field.
-
- This allows efficient updates of cached information with a minimum
- amount of transaction overhead. It is also used to prevent a method
- (e.g., PUT) from inadvertently modifying an existing resource when
- the client believes that the resource does not exist.
-
- As a special case, the value "*" matches any current representation
- of the resource.
-
- If-None-Match = "If-None-Match" ":" OWS If-None-Match-v
- If-None-Match-v = "*" / 1#entity-tag
-
- If any of the entity-tags match the entity-tag of the representation
- that would have been returned in the response to a similar GET
- request (without the If-None-Match header) on that resource, or if
- "*" is given and any current representation exists for that resource,
- then the server MUST NOT perform the requested method, unless
- required to do so because the resource's modification date fails to
- match that supplied in an If-Modified-Since header field in the
- request. Instead, if the request method was GET or HEAD, the server
- SHOULD respond with a 304 (Not Modified) response, including the
- cache-related header fields (particularly ETag) of one of the
- representations that matched. For all other request methods, the
- server MUST respond with a 412 (Precondition Failed) status code.
-
- If none of the entity-tags match, then the server MAY perform the
- requested method as if the If-None-Match header field did not exist,
- but MUST also ignore any If-Modified-Since header field(s) in the
- request. That is, if no entity-tags match, then the server MUST NOT
- return a 304 (Not Modified) response.
-
- If the request would, without the If-None-Match header field, result
- in anything other than a 2xx or 304 status code, then the If-None-
- Match header MUST be ignored. (See Section 5 for a discussion of
- server behavior when both If-Modified-Since and If-None-Match appear
- in the same request.)
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 16]
-
-Internet-Draft HTTP/1.1, Part 4 August 2010
-
-
- The meaning of "If-None-Match: *" is that the method MUST NOT be
- performed if the representation selected by the origin server (or by
- a cache, possibly using the Vary mechanism, see Section 3.5 of
- [Part6]) exists, and SHOULD be performed if the representation does
- not exist. This feature is intended to be useful in preventing races
- between PUT operations.
-
- Examples:
-
- If-None-Match: "xyzzy"
- If-None-Match: W/"xyzzy"
- If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
- If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
- If-None-Match: *
-
- The result of a request having both an If-None-Match header field and
- either an If-Match or an If-Unmodified-Since header fields is
- undefined by this specification.
-
-6.5. If-Unmodified-Since
-
- The "If-Unmodified-Since" request-header field is used to make a
- request method conditional. If the representation that would have
- been transferred in a 200 response to a GET request on the same
- resource has not been modified since the time specified in this
- field, the server SHOULD perform the requested operation as if the
- If-Unmodified-Since header were not present.
-
- If the representation has been modified since the specified time, the
- server MUST NOT perform the requested operation, and MUST return a
- 412 (Precondition Failed).
-
- If-Unmodified-Since = "If-Unmodified-Since" ":" OWS
- If-Unmodified-Since-v
- If-Unmodified-Since-v = HTTP-date
-
- An example of the field is:
-
- If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
-
- If the request normally (i.e., without the If-Unmodified-Since
- header) would result in anything other than a 2xx or 412 status code,
- the If-Unmodified-Since header SHOULD be ignored.
-
- If the specified date is invalid, the header is ignored.
-
- The result of a request having both an If-Unmodified-Since header
- field and either an If-None-Match or an If-Modified-Since header
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 17]
-
-Internet-Draft HTTP/1.1, Part 4 August 2010
-
-
- fields is undefined by this specification.
-
-6.6. Last-Modified
-
- The "Last-Modified" header field indicates the date and time at which
- the origin server believes the representation was last modified.
-
- Last-Modified = "Last-Modified" ":" OWS Last-Modified-v
- Last-Modified-v = HTTP-date
-
- An example of its use is
-
- Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
-
- The exact meaning of this header field depends on the implementation
- of the origin server and the nature of the original resource. For
- files, it might be just the file system last-modified time. For
- representations with dynamically included parts, it might be the most
- recent of the set of last-modify times for its component parts. For
- database gateways, it might be the last-update time stamp of the
- record. For virtual objects, it might be the last time the internal
- state changed.
-
- An origin server MUST NOT send a Last-Modified date which is later
- than the server's time of message origination. In such cases, where
- the resource's last modification would indicate some time in the
- future, the server MUST replace that date with the message
- origination date.
-
- An origin server SHOULD obtain the Last-Modified value of the
- representation as close as possible to the time that it generates the
- Date value of its response. This allows a recipient to make an
- accurate assessment of the representation's modification time,
- especially if the representation changes near the time that the
- response is generated.
-
- HTTP/1.1 servers SHOULD send Last-Modified whenever feasible.
-
- The Last-Modified header field value is often used as a cache
- validator. In simple terms, a cache entry is considered to be valid
- if the representation has not been modified since the Last-Modified
- value.
-
-7. IANA Considerations
-
-
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 18]
-
-Internet-Draft HTTP/1.1, Part 4 August 2010
-
-
-7.1. Status Code Registration
-
- The HTTP Status Code Registry located at
- shall be updated
- with the registrations below:
-
- +-------+---------------------+-------------+
- | Value | Description | Reference |
- +-------+---------------------+-------------+
- | 304 | Not Modified | Section 3.1 |
- | 412 | Precondition Failed | Section 3.2 |
- +-------+---------------------+-------------+
-
-7.2. Header Field Registration
-
- The Message Header Field Registry located at shall be
- updated with the permanent registrations below (see [RFC3864]):
-
- +---------------------+----------+----------+-------------+
- | Header Field Name | Protocol | Status | Reference |
- +---------------------+----------+----------+-------------+
- | ETag | http | standard | Section 6.1 |
- | If-Match | http | standard | Section 6.2 |
- | If-Modified-Since | http | standard | Section 6.3 |
- | If-None-Match | http | standard | Section 6.4 |
- | If-Unmodified-Since | http | standard | Section 6.5 |
- | Last-Modified | http | standard | Section 6.6 |
- +---------------------+----------+----------+-------------+
-
- The change controller is: "IETF (iesg@ietf.org) - Internet
- Engineering Task Force".
-
-8. Security Considerations
-
- No additional security considerations have been identified beyond
- those applicable to HTTP in general [Part1].
-
-9. Acknowledgments
-
-10. References
-
-10.1. Normative References
-
- [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
- Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
- and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
- and Message Parsing", draft-ietf-httpbis-p1-messaging-11
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 19]
-
-Internet-Draft HTTP/1.1, Part 4 August 2010
-
-
- (work in progress), August 2010.
-
- [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
- Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
- and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
- and Content Negotiation", draft-ietf-httpbis-p3-payload-11
- (work in progress), August 2010.
-
- [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
- Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
- and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
- Partial Responses", draft-ietf-httpbis-p5-range-11 (work
- in progress), August 2010.
-
- [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
- Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
- Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
- 6: Caching", draft-ietf-httpbis-p6-cache-11 (work in
- progress), August 2010.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", STD 68, RFC 5234, January 2008.
-
-10.2. Informative References
-
- [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
- Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
- Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
-
- [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
- Procedures for Message Header Fields", BCP 90, RFC 3864,
- September 2004.
-
-Appendix A. Changes from RFC 2616
-
- Allow weak entity-tags in all requests except range requests
- (Sections 4 and 6.4).
-
-
-
-
-
-
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 20]
-
-Internet-Draft HTTP/1.1, Part 4 August 2010
-
-
-Appendix B. Collected ABNF
-
- ETag = "ETag:" OWS ETag-v
- ETag-v = entity-tag
-
- HTTP-date =
-
- If-Match = "If-Match:" OWS If-Match-v
- If-Match-v = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
- entity-tag ] ) )
- If-Modified-Since = "If-Modified-Since:" OWS If-Modified-Since-v
- If-Modified-Since-v = HTTP-date
- If-None-Match = "If-None-Match:" OWS If-None-Match-v
- If-None-Match-v = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
- entity-tag ] ) )
- If-Unmodified-Since = "If-Unmodified-Since:" OWS
- If-Unmodified-Since-v
- If-Unmodified-Since-v = HTTP-date
-
- Last-Modified = "Last-Modified:" OWS Last-Modified-v
- Last-Modified-v = HTTP-date
-
- OWS =
-
- entity-tag = [ weak ] opaque-tag
-
- opaque-tag = quoted-string
-
- quoted-string =
-
- weak = %x57.2F ; W/
-
- ABNF diagnostics:
-
- ; ETag defined but not used
- ; If-Match defined but not used
- ; If-Modified-Since defined but not used
- ; If-None-Match defined but not used
- ; If-Unmodified-Since defined but not used
- ; Last-Modified defined but not used
-
-Appendix C. Change Log (to be removed by RFC Editor before publication)
-
-C.1. Since RFC2616
-
- Extracted relevant partitions from [RFC2616].
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 21]
-
-Internet-Draft HTTP/1.1, Part 4 August 2010
-
-
-C.2. Since draft-ietf-httpbis-p4-conditional-00
-
- Closed issues:
-
- o : "Normative and
- Informative references"
-
- Other changes:
-
- o Move definitions of 304 and 412 condition codes from Part2.
-
-C.3. Since draft-ietf-httpbis-p4-conditional-01
-
- Ongoing work on ABNF conversion
- ():
-
- o Add explicit references to BNF syntax and rules imported from
- other parts of the specification.
-
-C.4. Since draft-ietf-httpbis-p4-conditional-02
-
- Closed issues:
-
- o : "Weak ETags on
- non-GET requests"
-
- Ongoing work on IANA Message Header Registration
- ():
-
- o Reference RFC 3984, and update header registrations for headers
- defined in this document.
-
-C.5. Since draft-ietf-httpbis-p4-conditional-03
-
- Closed issues:
-
- o : "Examples for
- ETag matching"
-
- o : "'entity
- value' undefined"
-
- o : "bogus 2068
- Date header reference"
-
-
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 22]
-
-Internet-Draft HTTP/1.1, Part 4 August 2010
-
-
-C.6. Since draft-ietf-httpbis-p4-conditional-04
-
- Ongoing work on ABNF conversion
- ():
-
- o Use "/" instead of "|" for alternatives.
-
- o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
- whitespace ("OWS") and required whitespace ("RWS").
-
- o Rewrite ABNFs to spell out whitespace rules, factor out header
- value format definitions.
-
-C.7. Since draft-ietf-httpbis-p4-conditional-05
-
- Final work on ABNF conversion
- ():
-
- o Add appendix containing collected and expanded ABNF, reorganize
- ABNF introduction.
-
-C.8. Since draft-ietf-httpbis-p4-conditional-06
-
- Closed issues:
-
- o : "case-
- sensitivity of etag weakness indicator"
-
-C.9. Since draft-ietf-httpbis-p4-conditional-07
-
- Closed issues:
-
- o : "Weak ETags on
- non-GET requests" (If-Match still was defined to require strong
- matching)
-
- o : "move IANA
- registrations for optional status codes"
-
-C.10. Since draft-ietf-httpbis-p4-conditional-08
-
- No significant changes.
-
-C.11. Since draft-ietf-httpbis-p4-conditional-09
-
- No significant changes.
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 23]
-
-Internet-Draft HTTP/1.1, Part 4 August 2010
-
-
-C.12. Since draft-ietf-httpbis-p4-conditional-10
-
- Closed issues:
-
- o : "Clarify
- 'Requested Variant'"
-
- o : "Clarify
- entity / representation / variant terminology"
-
- o : "consider
- removing the 'changes from 2068' sections"
-
-Index
-
- 3
- 304 Not Modified (status code) 7
-
- 4
- 412 Precondition Failed (status code) 7
-
- E
- ETag header 12
-
- G
- Grammar
- entity-tag 5
- ETag 12
- ETag-v 12
- If-Match 13
- If-Match-v 13
- If-Modified-Since 14
- If-Modified-Since-v 14
- If-None-Match 16
- If-None-Match-v 16
- If-Unmodified-Since 17
- If-Unmodified-Since-v 17
- Last-Modified 18
- Last-Modified-v 18
- opaque-tag 5
- weak 5
-
- H
- Headers
- ETag 12
- If-Match 13
- If-Modified-Since 14
- If-None-Match 16
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 24]
-
-Internet-Draft HTTP/1.1, Part 4 August 2010
-
-
- If-Unmodified-Since 17
- Last-Modified 18
-
- I
- If-Match header 13
- If-Modified-Since header 14
- If-None-Match header 16
- If-Unmodified-Since header 17
-
- L
- Last-Modified header 18
-
- S
- Status Codes
- 304 Not Modified 7
- 412 Precondition Failed 7
-
-Authors' Addresses
-
- Roy T. Fielding (editor)
- Day Software
- 23 Corporate Plaza DR, Suite 280
- Newport Beach, CA 92660
- USA
-
- Phone: +1-949-706-5300
- Fax: +1-949-706-5305
- EMail: fielding@gbiv.com
- URI: http://roy.gbiv.com/
-
-
- Jim Gettys
- Alcatel-Lucent Bell Labs
- 21 Oak Knoll Road
- Carlisle, MA 01741
- USA
-
- EMail: jg@freedesktop.org
- URI: http://gettys.wordpress.com/
-
-
-
-
-
-
-
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 25]
-
-Internet-Draft HTTP/1.1, Part 4 August 2010
-
-
- Jeffrey C. Mogul
- Hewlett-Packard Company
- HP Labs, Large Scale Systems Group
- 1501 Page Mill Road, MS 1177
- Palo Alto, CA 94304
- USA
-
- EMail: JeffMogul@acm.org
-
-
- Henrik Frystyk Nielsen
- Microsoft Corporation
- 1 Microsoft Way
- Redmond, WA 98052
- USA
-
- EMail: henrikn@microsoft.com
-
-
- Larry Masinter
- Adobe Systems, Incorporated
- 345 Park Ave
- San Jose, CA 95110
- USA
-
- EMail: LMM@acm.org
- URI: http://larry.masinter.net/
-
-
- Paul J. Leach
- Microsoft Corporation
- 1 Microsoft Way
- Redmond, WA 98052
-
- EMail: paulle@microsoft.com
-
-
- Tim Berners-Lee
- World Wide Web Consortium
- MIT Computer Science and Artificial Intelligence Laboratory
- The Stata Center, Building 32
- 32 Vassar Street
- Cambridge, MA 02139
- USA
-
- EMail: timbl@w3.org
- URI: http://www.w3.org/People/Berners-Lee/
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 26]
-
-Internet-Draft HTTP/1.1, Part 4 August 2010
-
-
- Yves Lafon (editor)
- World Wide Web Consortium
- W3C / ERCIM
- 2004, rte des Lucioles
- Sophia-Antipolis, AM 06902
- France
-
- EMail: ylafon@w3.org
- URI: http://www.raubacapeu.net/people/yves/
-
-
- Julian F. Reschke (editor)
- greenbytes GmbH
- Hafenweg 16
- Muenster, NW 48155
- Germany
-
- Phone: +49 251 2807760
- Fax: +49 251 2807761
- EMail: julian.reschke@greenbytes.de
- URI: http://greenbytes.de/tech/webdav/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 27]
-
diff --git a/vendor/sabre/dav/docs/draft-ietf-httpbis-p5-range-11.txt b/vendor/sabre/dav/docs/draft-ietf-httpbis-p5-range-11.txt
deleted file mode 100644
index 1ef7b0946..000000000
--- a/vendor/sabre/dav/docs/draft-ietf-httpbis-p5-range-11.txt
+++ /dev/null
@@ -1,1512 +0,0 @@
-
-
-
-HTTPbis Working Group R. Fielding, Ed.
-Internet-Draft Day Software
-Obsoletes: 2616 (if approved) J. Gettys
-Intended status: Standards Track Alcatel-Lucent
-Expires: February 5, 2011 J. Mogul
- HP
- H. Frystyk
- Microsoft
- L. Masinter
- Adobe Systems
- P. Leach
- Microsoft
- T. Berners-Lee
- W3C/MIT
- Y. Lafon, Ed.
- W3C
- J. Reschke, Ed.
- greenbytes
- August 4, 2010
-
-
- HTTP/1.1, part 5: Range Requests and Partial Responses
- draft-ietf-httpbis-p5-range-11
-
-Abstract
-
- The Hypertext Transfer Protocol (HTTP) is an application-level
- protocol for distributed, collaborative, hypermedia information
- systems. HTTP has been in use by the World Wide Web global
- information initiative since 1990. This document is Part 5 of the
- seven-part specification that defines the protocol referred to as
- "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines
- range-specific requests and the rules for constructing and combining
- responses to those requests.
-
-Editorial Note (To be removed by RFC Editor)
-
- Discussion of this draft should take place on the HTTPBIS working
- group mailing list (ietf-http-wg@w3.org). The current issues list is
- at and related
- documents (including fancy diffs) can be found at
- .
-
- The changes in this draft are summarized in Appendix D.12.
-
-Status of This Memo
-
- This Internet-Draft is submitted in full conformance with the
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 1]
-
-Internet-Draft HTTP/1.1, Part 5 August 2010
-
-
- provisions of BCP 78 and BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF). Note that other groups may also distribute
- working documents as Internet-Drafts. The list of current Internet-
- Drafts is at http://datatracker.ietf.org/drafts/current/.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- This Internet-Draft will expire on February 5, 2011.
-
-Copyright Notice
-
- Copyright (c) 2010 IETF Trust and the persons identified as the
- document authors. All rights reserved.
-
- This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents
- (http://trustee.ietf.org/license-info) in effect on the date of
- publication of this document. Please review these documents
- carefully, as they describe your rights and restrictions with respect
- to this document. Code Components extracted from this document must
- include Simplified BSD License text as described in Section 4.e of
- the Trust Legal Provisions and are provided without warranty as
- described in the Simplified BSD License.
-
- This document may contain material from IETF Documents or IETF
- Contributions published or made publicly available before November
- 10, 2008. The person(s) controlling the copyright in some of this
- material may not have granted the IETF Trust the right to allow
- modifications of such material outside the IETF Standards Process.
- Without obtaining an adequate license from the person(s) controlling
- the copyright in such materials, this document may not be modified
- outside the IETF Standards Process, and derivative works of it may
- not be created outside the IETF Standards Process, except to format
- it for publication as an RFC or to translate it into languages other
- than English.
-
-
-
-
-
-
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 2]
-
-Internet-Draft HTTP/1.1, Part 5 August 2010
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
- 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
- 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6
- 1.2.2. ABNF Rules defined in other Parts of the
- Specification . . . . . . . . . . . . . . . . . . . . 6
- 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 6
- 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7
- 3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 7
- 3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 8
- 4. Combining Ranges . . . . . . . . . . . . . . . . . . . . . . . 8
- 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 8
- 5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 9
- 5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 9
- 5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 11
- 5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 12
- 5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 12
- 5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 14
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
- 6.1. Status Code Registration . . . . . . . . . . . . . . . . . 15
- 6.2. Header Field Registration . . . . . . . . . . . . . . . . 15
- 6.3. Range Specifier Registration . . . . . . . . . . . . . . . 16
- 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
- 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
- 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
- 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
- 9.2. Informative References . . . . . . . . . . . . . . . . . . 17
- Appendix A. Internet Media Type multipart/byteranges . . . . . . 17
- Appendix B. Compatibility with Previous Versions . . . . . . . . 20
- B.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 20
- Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 20
- Appendix D. Change Log (to be removed by RFC Editor before
- publication) . . . . . . . . . . . . . . . . . . . . 21
- D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 21
- D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 21
- D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 22
- D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 22
- D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 22
- D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 22
- D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 22
- D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 23
- D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 23
- D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 23
- D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 23
- D.12. Since draft-ietf-httpbis-p5-range-10 . . . . . . . . . . . 23
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 3]
-
-Internet-Draft HTTP/1.1, Part 5 August 2010
-
-
- Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 4]
-
-Internet-Draft HTTP/1.1, Part 5 August 2010
-
-
-1. Introduction
-
- HTTP clients often encounter interrupted data transfers as a result
- of cancelled requests or dropped connections. When a cache has
- stored a partial representation, it is desirable to request the
- remainder of that representation in a subsequent request rather than
- transfer the entire representation. There are also a number of Web
- applications that benefit from being able to request only a subset of
- a larger representation, such as a single page of a very large
- document or only part of an image to be rendered by a device with
- limited local storage.
-
- This document defines HTTP/1.1 range requests, partial responses, and
- the multipart/byteranges media type. The protocol for range requests
- is an OPTIONAL feature of HTTP, designed so resources or recipients
- that do not implement this feature can respond as if it is a normal
- GET request without impacting interoperability. Partial responses
- are indicated by a distinct status code to not be mistaken for full
- responses by intermediate caches that might not implement the
- feature.
-
- Although the HTTP range request mechanism is designed to allow for
- extensible range types, this specification only defines requests for
- byte ranges.
-
-1.1. Requirements
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
- An implementation is not compliant if it fails to satisfy one or more
- of the "MUST" or "REQUIRED" level requirements for the protocols it
- implements. An implementation that satisfies all the "MUST" or
- "REQUIRED" level and all the "SHOULD" level requirements for its
- protocols is said to be "unconditionally compliant"; one that
- satisfies all the "MUST" level requirements but not all the "SHOULD"
- level requirements for its protocols is said to be "conditionally
- compliant".
-
-1.2. Syntax Notation
-
- This specification uses the ABNF syntax defined in Section 1.2 of
- [Part1] (which extends the syntax defined in [RFC5234] with a list
- rule). Appendix C shows the collected ABNF, with the list rule
- expanded.
-
- The following core rules are included by reference, as defined in
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 5]
-
-Internet-Draft HTTP/1.1, Part 5 August 2010
-
-
- [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
- (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
- HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
- sequence of data), SP (space), VCHAR (any visible USASCII character),
- and WSP (whitespace).
-
-1.2.1. Core Rules
-
- The core rules below are defined in Section 1.2.2 of [Part1]:
-
- token =
- OWS =
-
-1.2.2. ABNF Rules defined in other Parts of the Specification
-
- The ABNF rules below are defined in other parts:
-
- HTTP-date =
-
-
- entity-tag =
-
-2. Range Units
-
- HTTP/1.1 allows a client to request that only part (a range of) the
- representation be included within the response. HTTP/1.1 uses range
- units in the Range (Section 5.4) and Content-Range (Section 5.2)
- header fields. A representation can be broken down into subranges
- according to various structural units.
-
- range-unit = bytes-unit / other-range-unit
- bytes-unit = "bytes"
- other-range-unit = token
-
- HTTP/1.1 has been designed to allow implementations of applications
- that do not depend on knowledge of ranges. The only range unit
- defined by HTTP/1.1 is "bytes". Additional specifiers can be defined
- as described in Section 2.1.
-
- If a range unit is not understood in a request, a server MUST ignore
- the whole Range header (Section 5.4). If a range unit is not
- understood in a response, an intermediary SHOULD pass the response to
- the client; a client MUST fail.
-
-2.1. Range Specifier Registry
-
- The HTTP Ranger Specifier Registry defines the name space for the
- range specifier names.
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 6]
-
-Internet-Draft HTTP/1.1, Part 5 August 2010
-
-
- Registrations MUST include the following fields:
-
- o Name
-
- o Description
-
- o Pointer to specification text
-
- Values to be added to this name space are subject to IETF review
- ([RFC5226], Section 4.1).
-
- The registry itself is maintained at
- .
-
-3. Status Code Definitions
-
-3.1. 206 Partial Content
-
- The server has fulfilled the partial GET request for the resource.
- The request MUST have included a Range header field (Section 5.4)
- indicating the desired range, and MAY have included an If-Range
- header field (Section 5.3) to make the request conditional.
-
- The response MUST include the following header fields:
-
- o Either a Content-Range header field (Section 5.2) indicating the
- range included with this response, or a multipart/byteranges
- Content-Type including Content-Range fields for each part. If a
- Content-Length header field is present in the response, its value
- MUST match the actual number of octets transmitted in the message-
- body.
-
- o Date
-
- o Cache-Control, ETag, Expires, Content-Location, Last-Modified,
- and/or Vary, if the header field would have been sent in a 200
- response to the same request
-
- If the 206 response is the result of an If-Range request, the
- response SHOULD NOT include other representation header fields.
- Otherwise, the response MUST include all of the representation header
- fields that would have been returned with a 200 (OK) response to the
- same request.
-
- A cache MUST NOT combine a 206 response with other previously cached
- content if the ETag or Last-Modified headers do not match exactly,
- see Section 4.
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 7]
-
-Internet-Draft HTTP/1.1, Part 5 August 2010
-
-
- A cache that does not support the Range and Content-Range headers
- MUST NOT cache 206 (Partial Content) responses. Furthermore, if a
- response uses a range unit that is not understood by the cache, then
- it MUST NOT be cached either.
-
-3.2. 416 Requested Range Not Satisfiable
-
- A server SHOULD return a response with this status code if a request
- included a Range request-header field (Section 5.4), and none of the
- ranges-specifier values in this field overlap the current extent of
- the selected resource, and the request did not include an If-Range
- request-header field (Section 5.3). (For byte-ranges, this means
- that the first-byte-pos of all of the byte-range-spec values were
- greater than the current length of the selected resource.)
-
- When this status code is returned for a byte-range request, the
- response SHOULD include a Content-Range header field specifying the
- current length of the representation (see Section 5.2). This
- response MUST NOT use the multipart/byteranges content-type.
-
-4. Combining Ranges
-
- A response might transfer only a subrange of a representation, either
- because the request included one or more Range specifications, or
- because a connection closed prematurely. After several such
- transfers, a cache might have received several ranges of the same
- representation.
-
- If a cache has a stored non-empty set of subranges for a
- representation, and an incoming response transfers another subrange,
- the cache MAY combine the new subrange with the existing set if both
- the following conditions are met:
-
- o Both the incoming response and the cache entry have a cache
- validator.
-
- o The two cache validators match using the strong comparison
- function (see Section 4 of [Part4]).
-
- If either requirement is not met, the cache MUST use only the most
- recent partial response (based on the Date values transmitted with
- every response, and using the incoming response if these values are
- equal or missing), and MUST discard the other partial information.
-
-5. Header Field Definitions
-
- This section defines the syntax and semantics of HTTP/1.1 header
- fields related to range requests and partial responses.
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 8]
-
-Internet-Draft HTTP/1.1, Part 5 August 2010
-
-
-5.1. Accept-Ranges
-
- The "Accept-Ranges" response-header field allows a resource to
- indicate its acceptance of range requests.
-
- Accept-Ranges = "Accept-Ranges" ":" OWS Accept-Ranges-v
- Accept-Ranges-v = acceptable-ranges
- acceptable-ranges = 1#range-unit / "none"
-
- Origin servers that accept byte-range requests MAY send
-
- Accept-Ranges: bytes
-
- but are not required to do so. Clients MAY generate range requests
- without having received this header for the resource involved. Range
- units are defined in Section 2.
-
- Servers that do not accept any kind of range request for a resource
- MAY send
-
- Accept-Ranges: none
-
- to advise the client not to attempt a range request.
-
-5.2. Content-Range
-
- The "Content-Range" header field is sent with a partial
- representation to specify where in the full representation the
- payload body is intended to be applied.
-
- Range units are defined in Section 2.
-
- Content-Range = "Content-Range" ":" OWS Content-Range-v
- Content-Range-v = content-range-spec
-
- content-range-spec = byte-content-range-spec
- / other-content-range-spec
- byte-content-range-spec = bytes-unit SP
- byte-range-resp-spec "/"
- ( instance-length / "*" )
-
- byte-range-resp-spec = (first-byte-pos "-" last-byte-pos)
- / "*"
-
- instance-length = 1*DIGIT
-
- other-content-range-spec = other-range-unit SP
- other-range-resp-spec
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 9]
-
-Internet-Draft HTTP/1.1, Part 5 August 2010
-
-
- other-range-resp-spec = *CHAR
-
- The header SHOULD indicate the total length of the full
- representation, unless this length is unknown or difficult to
- determine. The asterisk "*" character means that the instance-length
- is unknown at the time when the response was generated.
-
- Unlike byte-ranges-specifier values (see Section 5.4.1), a byte-
- range-resp-spec MUST only specify one range, and MUST contain
- absolute byte positions for both the first and last byte of the
- range.
-
- A byte-content-range-spec with a byte-range-resp-spec whose last-
- byte-pos value is less than its first-byte-pos value, or whose
- instance-length value is less than or equal to its last-byte-pos
- value, is invalid. The recipient of an invalid byte-content-range-
- spec MUST ignore it and any content transferred along with it.
-
- In the case of a byte range request: A server sending a response with
- status code 416 (Requested range not satisfiable) SHOULD include a
- Content-Range field with a byte-range-resp-spec of "*". The
- instance-length specifies the current length of the selected
- resource. A response with status code 206 (Partial Content) MUST NOT
- include a Content-Range field with a byte-range-resp-spec of "*".
-
- Examples of byte-content-range-spec values, assuming that the
- representation contains a total of 1234 bytes:
-
- o The first 500 bytes:
-
- bytes 0-499/1234
-
- o The second 500 bytes:
-
- bytes 500-999/1234
-
- o All except for the first 500 bytes:
-
- bytes 500-1233/1234
-
- o The last 500 bytes:
-
- bytes 734-1233/1234
-
- When an HTTP message includes the content of a single range (for
- example, a response to a request for a single range, or to a request
- for a set of ranges that overlap without any holes), this content is
- transmitted with a Content-Range header, and a Content-Length header
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 10]
-
-Internet-Draft HTTP/1.1, Part 5 August 2010
-
-
- showing the number of bytes actually transferred. For example,
-
- HTTP/1.1 206 Partial Content
- Date: Wed, 15 Nov 1995 06:25:24 GMT
- Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
- Content-Range: bytes 21010-47021/47022
- Content-Length: 26012
- Content-Type: image/gif
-
- When an HTTP message includes the content of multiple ranges (for
- example, a response to a request for multiple non-overlapping
- ranges), these are transmitted as a multipart message. The multipart
- media type used for this purpose is "multipart/byteranges" as defined
- in Appendix A.
-
- A response to a request for a single range MUST NOT be sent using the
- multipart/byteranges media type. A response to a request for
- multiple ranges, whose result is a single range, MAY be sent as a
- multipart/byteranges media type with one part. A client that cannot
- decode a multipart/byteranges message MUST NOT ask for multiple
- ranges in a single request.
-
- When a client requests multiple ranges in one request, the server
- SHOULD return them in the order that they appeared in the request.
-
- If the server ignores a byte-range-spec because it is syntactically
- invalid, the server SHOULD treat the request as if the invalid Range
- header field did not exist. (Normally, this means return a 200
- response containing the full representation).
-
- If the server receives a request (other than one including an If-
- Range request-header field) with an unsatisfiable Range request-
- header field (that is, all of whose byte-range-spec values have a
- first-byte-pos value greater than the current length of the selected
- resource), it SHOULD return a response code of 416 (Requested range
- not satisfiable) (Section 3.2).
-
- Note: Clients cannot depend on servers to send a 416 (Requested
- range not satisfiable) response instead of a 200 (OK) response for
- an unsatisfiable Range request-header, since not all servers
- implement this request-header.
-
-5.3. If-Range
-
- If a client has a partial copy of a representation in its cache, and
- wishes to have an up-to-date copy of the entire representation in its
- cache, it could use the Range request-header with a conditional GET
- (using either or both of If-Unmodified-Since and If-Match.) However,
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 11]
-
-Internet-Draft HTTP/1.1, Part 5 August 2010
-
-
- if the condition fails because the representation has been modified,
- the client would then have to make a second request to obtain the
- entire current representation.
-
- The "If-Range" request-header field allows a client to "short-
- circuit" the second request. Informally, its meaning is "if the
- representation is unchanged, send me the part(s) that I am missing;
- otherwise, send me the entire new representation".
-
- If-Range = "If-Range" ":" OWS If-Range-v
- If-Range-v = entity-tag / HTTP-date
-
- If the client has no entity-tag for a representation, but does have a
- Last-Modified date, it MAY use that date in an If-Range header. (The
- server can distinguish between a valid HTTP-date and any form of
- entity-tag by examining no more than two characters.) The If-Range
- header SHOULD only be used together with a Range header, and MUST be
- ignored if the request does not include a Range header, or if the
- server does not support the sub-range operation.
-
- If the entity-tag given in the If-Range header matches the current
- cache validator for the representation, then the server SHOULD
- provide the specified sub-range of the representation using a 206
- (Partial Content) response. If the cache validator does not match,
- then the server SHOULD return the entire representation using a 200
- (OK) response.
-
-5.4. Range
-
-5.4.1. Byte Ranges
-
- Since all HTTP representations are transferred as sequences of bytes,
- the concept of a byte range is meaningful for any HTTP
- representation. (However, not all clients and servers need to
- support byte-range operations.)
-
- Byte range specifications in HTTP apply to the sequence of bytes in
- the representation body (not necessarily the same as the message-
- body).
-
- A byte range operation MAY specify a single range of bytes, or a set
- of ranges within a single representation.
-
- byte-ranges-specifier = bytes-unit "=" byte-range-set
- byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec )
- byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
- first-byte-pos = 1*DIGIT
- last-byte-pos = 1*DIGIT
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 12]
-
-Internet-Draft HTTP/1.1, Part 5 August 2010
-
-
- The first-byte-pos value in a byte-range-spec gives the byte-offset
- of the first byte in a range. The last-byte-pos value gives the
- byte-offset of the last byte in the range; that is, the byte
- positions specified are inclusive. Byte offsets start at zero.
-
- If the last-byte-pos value is present, it MUST be greater than or
- equal to the first-byte-pos in that byte-range-spec, or the byte-
- range-spec is syntactically invalid. The recipient of a byte-range-
- set that includes one or more syntactically invalid byte-range-spec
- values MUST ignore the header field that includes that byte-range-
- set.
-
- If the last-byte-pos value is absent, or if the value is greater than
- or equal to the current length of the representation body, last-byte-
- pos is taken to be equal to one less than the current length of the
- representation in bytes.
-
- By its choice of last-byte-pos, a client can limit the number of
- bytes retrieved without knowing the size of the representation.
-
- suffix-byte-range-spec = "-" suffix-length
- suffix-length = 1*DIGIT
-
- A suffix-byte-range-spec is used to specify the suffix of the
- representation body, of a length given by the suffix-length value.
- (That is, this form specifies the last N bytes of a representation.)
- If the representation is shorter than the specified suffix-length,
- the entire representation is used.
-
- If a syntactically valid byte-range-set includes at least one byte-
- range-spec whose first-byte-pos is less than the current length of
- the representation, or at least one suffix-byte-range-spec with a
- non-zero suffix-length, then the byte-range-set is satisfiable.
- Otherwise, the byte-range-set is unsatisfiable. If the byte-range-
- set is unsatisfiable, the server SHOULD return a response with a 416
- (Requested range not satisfiable) status code. Otherwise, the server
- SHOULD return a response with a 206 (Partial Content) status code
- containing the satisfiable ranges of the representation.
-
- Examples of byte-ranges-specifier values (assuming a representation
- of length 10000):
-
- o The first 500 bytes (byte offsets 0-499, inclusive):
-
- bytes=0-499
-
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 13]
-
-Internet-Draft HTTP/1.1, Part 5 August 2010
-
-
- o The second 500 bytes (byte offsets 500-999, inclusive):
-
- bytes=500-999
-
- o The final 500 bytes (byte offsets 9500-9999, inclusive):
-
- bytes=-500
-
- Or:
-
- bytes=9500-
-
- o The first and last bytes only (bytes 0 and 9999):
-
- bytes=0-0,-1
-
- o Several legal but not canonical specifications of the second 500
- bytes (byte offsets 500-999, inclusive):
-
- bytes=500-600,601-999
- bytes=500-700,601-999
-
-5.4.2. Range Retrieval Requests
-
- The "Range" request-header field defines the GET method (conditional
- or not) to request one or more sub-ranges of the response
- representation body, instead of the entire representation body.
-
- Range = "Range" ":" OWS Range-v
- Range-v = byte-ranges-specifier
- / other-ranges-specifier
- other-ranges-specifier = other-range-unit "=" other-range-set
- other-range-set = 1*CHAR
-
- A server MAY ignore the Range header. However, HTTP/1.1 origin
- servers and intermediate caches ought to support byte ranges when
- possible, since Range supports efficient recovery from partially
- failed transfers, and supports efficient partial retrieval of large
- representations.
-
- If the server supports the Range header and the specified range or
- ranges are appropriate for the representation:
-
- o The presence of a Range header in an unconditional GET modifies
- what is returned if the GET is otherwise successful. In other
- words, the response carries a status code of 206 (Partial Content)
- instead of 200 (OK).
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 14]
-
-Internet-Draft HTTP/1.1, Part 5 August 2010
-
-
- o The presence of a Range header in a conditional GET (a request
- using one or both of If-Modified-Since and If-None-Match, or one
- or both of If-Unmodified-Since and If-Match) modifies what is
- returned if the GET is otherwise successful and the condition is
- true. It does not affect the 304 (Not Modified) response returned
- if the conditional is false.
-
- In some cases, it might be more appropriate to use the If-Range
- header (see Section 5.3) in addition to the Range header.
-
- If a proxy that supports ranges receives a Range request, forwards
- the request to an inbound server, and receives an entire
- representation in reply, it SHOULD only return the requested range to
- its client. It SHOULD store the entire received response in its
- cache if that is consistent with its cache allocation policies.
-
-6. IANA Considerations
-
-6.1. Status Code Registration
-
- The HTTP Status Code Registry located at
- shall be updated
- with the registrations below:
-
- +-------+---------------------------------+-------------+
- | Value | Description | Reference |
- +-------+---------------------------------+-------------+
- | 206 | Partial Content | Section 3.1 |
- | 416 | Requested Range Not Satisfiable | Section 3.2 |
- +-------+---------------------------------+-------------+
-
-6.2. Header Field Registration
-
- The Message Header Field Registry located at shall be
- updated with the permanent registrations below (see [RFC3864]):
-
- +-------------------+----------+----------+-------------+
- | Header Field Name | Protocol | Status | Reference |
- +-------------------+----------+----------+-------------+
- | Accept-Ranges | http | standard | Section 5.1 |
- | Content-Range | http | standard | Section 5.2 |
- | If-Range | http | standard | Section 5.3 |
- | Range | http | standard | Section 5.4 |
- +-------------------+----------+----------+-------------+
-
- The change controller is: "IETF (iesg@ietf.org) - Internet
- Engineering Task Force".
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 15]
-
-Internet-Draft HTTP/1.1, Part 5 August 2010
-
-
-6.3. Range Specifier Registration
-
- The registration procedure for HTTP Range Specifiers is defined by
- Section 2.1 of this document.
-
- The HTTP Range Specifier Registry shall be created at
- and be
- populated with the registrations below:
-
- +----------------------+-------------------+----------------------+
- | Range Specifier Name | Description | Reference |
- +----------------------+-------------------+----------------------+
- | bytes | a range of octets | (this specification) |
- +----------------------+-------------------+----------------------+
-
- The change controller is: "IETF (iesg@ietf.org) - Internet
- Engineering Task Force".
-
-7. Security Considerations
-
- No additional security considerations have been identified beyond
- those applicable to HTTP in general [Part1].
-
-8. Acknowledgments
-
- Most of the specification of ranges is based on work originally done
- by Ari Luotonen and John Franks, with additional input from Steve
- Zilles, Daniel W. Connolly, Roy T. Fielding, Jim Gettys, Martin
- Hamilton, Koen Holtman, Shel Kaplan, Paul Leach, Alex Lopez-Ortiz,
- Larry Masinter, Jeff Mogul, Lou Montulli, David W. Morris, Luigi
- Rizzo, and Bill Weihl.
-
-9. References
-
-9.1. Normative References
-
- [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
- Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
- and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
- and Message Parsing", draft-ietf-httpbis-p1-messaging-11
- (work in progress), August 2010.
-
- [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
- Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
- and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
- Requests", draft-ietf-httpbis-p4-conditional-11 (work in
- progress), August 2010.
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 16]
-
-Internet-Draft HTTP/1.1, Part 5 August 2010
-
-
- [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
- Extensions (MIME) Part Two: Media Types", RFC 2046,
- November 1996.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", STD 68, RFC 5234, January 2008.
-
-9.2. Informative References
-
- [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
- Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
- Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
-
- [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
- Procedures for Message Header Fields", BCP 90, RFC 3864,
- September 2004.
-
- [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
- Registration Procedures", BCP 13, RFC 4288, December 2005.
-
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
- IANA Considerations Section in RFCs", BCP 26, RFC 5226,
- May 2008.
-
-Appendix A. Internet Media Type multipart/byteranges
-
- When an HTTP 206 (Partial Content) response message includes the
- content of multiple ranges (a response to a request for multiple non-
- overlapping ranges), these are transmitted as a multipart message-
- body ([RFC2046], Section 5.1). The media type for this purpose is
- called "multipart/byteranges". The following is to be registered
- with IANA [RFC4288].
-
- Note: Despite the name "multipart/byteranges" is not limited to
- the byte ranges only.
-
- The multipart/byteranges media type includes one or more parts, each
- with its own Content-Type and Content-Range fields. The required
- boundary parameter specifies the boundary string used to separate
- each body-part.
-
-
-
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 17]
-
-Internet-Draft HTTP/1.1, Part 5 August 2010
-
-
- Type name: multipart
-
- Subtype name: byteranges
-
- Required parameters: boundary
-
- Optional parameters: none
-
- Encoding considerations: only "7bit", "8bit", or "binary" are
- permitted
-
- Security considerations: none
-
- Interoperability considerations: none
-
- Published specification: This specification (see Appendix A).
-
- Applications that use this media type:
-
- Additional information:
-
- Magic number(s): none
-
- File extension(s): none
-
- Macintosh file type code(s): none
-
- Person and email address to contact for further information: See
- Authors Section.
-
- Intended usage: COMMON
-
- Restrictions on usage: none
-
- Author/Change controller: IESG
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 18]
-
-Internet-Draft HTTP/1.1, Part 5 August 2010
-
-
- For example:
-
- HTTP/1.1 206 Partial Content
- Date: Wed, 15 Nov 1995 06:25:24 GMT
- Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
- Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
-
- --THIS_STRING_SEPARATES
- Content-type: application/pdf
- Content-range: bytes 500-999/8000
-
- ...the first range...
- --THIS_STRING_SEPARATES
- Content-type: application/pdf
- Content-range: bytes 7000-7999/8000
-
- ...the second range
- --THIS_STRING_SEPARATES--
-
- Other example:
-
- HTTP/1.1 206 Partial Content
- Date: Tue, 14 Nov 1995 06:25:24 GMT
- Last-Modified: Tue, 14 July 04:58:08 GMT
- Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
-
- --THIS_STRING_SEPARATES
- Content-type: video/example
- Content-range: exampleunit 1.2-4.3/25
-
- ...the first range...
- --THIS_STRING_SEPARATES
- Content-type: video/example
- Content-range: exampleunit 11.2-14.3/25
-
- ...the second range
- --THIS_STRING_SEPARATES--
-
- Notes:
-
- 1. Additional CRLFs MAY precede the first boundary string in the
- body.
-
- 2. Although [RFC2046] permits the boundary string to be quoted, some
- existing implementations handle a quoted boundary string
- incorrectly.
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 19]
-
-Internet-Draft HTTP/1.1, Part 5 August 2010
-
-
- 3. A number of browsers and servers were coded to an early draft of
- the byteranges specification to use a media type of multipart/
- x-byteranges, which is almost, but not quite compatible with the
- version documented in HTTP/1.1.
-
-Appendix B. Compatibility with Previous Versions
-
-B.1. Changes from RFC 2616
-
- Clarify that it is not ok to use a weak cache validator in a 206
- response. (Section 3.1)
-
- Clarify that multipart/byteranges can consist of a single part.
- (Appendix A)
-
-Appendix C. Collected ABNF
-
- Accept-Ranges = "Accept-Ranges:" OWS Accept-Ranges-v
- Accept-Ranges-v = acceptable-ranges
-
- Content-Range = "Content-Range:" OWS Content-Range-v
- Content-Range-v = content-range-spec
-
- HTTP-date =
-
- If-Range = "If-Range:" OWS If-Range-v
- If-Range-v = entity-tag / HTTP-date
-
- OWS =
-
- Range = "Range:" OWS Range-v
- Range-v = byte-ranges-specifier / other-ranges-specifier
-
- acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS
- range-unit ] ) ) / "none"
-
- byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/" (
- instance-length / "*" )
- byte-range-resp-spec = ( first-byte-pos "-" last-byte-pos ) / "*"
- byte-range-set = ( *( "," OWS ) byte-range-spec ) / (
- suffix-byte-range-spec *( OWS "," [ ( OWS byte-range-spec ) /
- suffix-byte-range-spec ] ) )
- byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
- byte-ranges-specifier = bytes-unit "=" byte-range-set
- bytes-unit = "bytes"
-
- content-range-spec = byte-content-range-spec /
- other-content-range-spec
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 20]
-
-Internet-Draft HTTP/1.1, Part 5 August 2010
-
-
- entity-tag =
-
- first-byte-pos = 1*DIGIT
-
- instance-length = 1*DIGIT
-
- last-byte-pos = 1*DIGIT
-
- other-content-range-spec = other-range-unit SP other-range-resp-spec
- other-range-resp-spec = *CHAR
- other-range-set = 1*CHAR
- other-range-unit = token
- other-ranges-specifier = other-range-unit "=" other-range-set
-
- range-unit = bytes-unit / other-range-unit
-
- suffix-byte-range-spec = "-" suffix-length
- suffix-length = 1*DIGIT
-
- token =
-
- ABNF diagnostics:
-
- ; Accept-Ranges defined but not used
- ; Content-Range defined but not used
- ; If-Range defined but not used
- ; Range defined but not used
-
-Appendix D. Change Log (to be removed by RFC Editor before publication)
-
-D.1. Since RFC2616
-
- Extracted relevant partitions from [RFC2616].
-
-D.2. Since draft-ietf-httpbis-p5-range-00
-
- Closed issues:
-
- o : "Cache
- validators in 206 responses"
- ()
-
- o : "Normative and
- Informative references"
-
- o : "Normative up-
- to-date references"
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 21]
-
-Internet-Draft HTTP/1.1, Part 5 August 2010
-
-
-D.3. Since draft-ietf-httpbis-p5-range-01
-
- Closed issues:
-
- o : "Updating to
- RFC4288"
-
- Ongoing work on ABNF conversion
- ():
-
- o Add explicit references to BNF syntax and rules imported from
- other parts of the specification.
-
-D.4. Since draft-ietf-httpbis-p5-range-02
-
- Ongoing work on IANA Message Header Registration
- ():
-
- o Reference RFC 3984, and update header registrations for headers
- defined in this document.
-
-D.5. Since draft-ietf-httpbis-p5-range-03
-
-D.6. Since draft-ietf-httpbis-p5-range-04
-
- Closed issues:
-
- o : "multipart/
- byteranges minimum number of parts"
-
- Ongoing work on ABNF conversion
- ():
-
- o Use "/" instead of "|" for alternatives.
-
- o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
- whitespace ("OWS") and required whitespace ("RWS").
-
- o Rewrite ABNFs to spell out whitespace rules, factor out header
- value format definitions.
-
-D.7. Since draft-ietf-httpbis-p5-range-05
-
- Closed issues:
-
- o : "State base
- for *-byte-pos and suffix-length"
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 22]
-
-Internet-Draft HTTP/1.1, Part 5 August 2010
-
-
- Ongoing work on Custom Ranges
- ():
-
- o Remove bias in favor of byte ranges; allow custom ranges in ABNF.
-
- Final work on ABNF conversion
- ():
-
- o Add appendix containing collected and expanded ABNF, reorganize
- ABNF introduction.
-
-D.8. Since draft-ietf-httpbis-p5-range-06
-
- Closed issues:
-
- o : "base for
- numeric protocol elements"
-
-D.9. Since draft-ietf-httpbis-p5-range-07
-
- Closed issues:
-
- o Fixed discrepancy in the If-Range definition about allowed
- validators.
-
- o : "multipart/
- byteranges for custom range units"
-
- o : "range unit
- missing from other-ranges-specifier in Range header"
-
- o : "move IANA
- registrations for optional status codes"
-
-D.10. Since draft-ietf-httpbis-p5-range-08
-
- No significant changes.
-
-D.11. Since draft-ietf-httpbis-p5-range-09
-
- No significant changes.
-
-D.12. Since draft-ietf-httpbis-p5-range-10
-
- Closed issues:
-
- o : "Clarify
- 'Requested Variant'"
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 23]
-
-Internet-Draft HTTP/1.1, Part 5 August 2010
-
-
- o : "Clarify
- entity / representation / variant terminology"
-
- o : "consider
- removing the 'changes from 2068' sections"
-
- Ongoing work on Custom Ranges
- ():
-
- o Add IANA registry.
-
-Index
-
- 2
- 206 Partial Content (status code) 7
-
- 4
- 416 Requested Range Not Satisfiable (status code) 8
-
- A
- Accept-Ranges header 9
-
- C
- Content-Range header 9
-
- G
- Grammar
- Accept-Ranges 9
- Accept-Ranges-v 9
- acceptable-ranges 9
- byte-content-range-spec 9
- byte-range-resp-spec 9
- byte-range-set 12
- byte-range-spec 12
- byte-ranges-specifier 12
- bytes-unit 6
- Content-Range 9
- content-range-spec 9
- Content-Range-v 9
- first-byte-pos 12
- If-Range 12
- If-Range-v 12
- instance-length 9
- last-byte-pos 12
- other-range-unit 6
- Range 14
- range-unit 6
- ranges-specifier 12
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 24]
-
-Internet-Draft HTTP/1.1, Part 5 August 2010
-
-
- suffix-byte-range-spec 13
- suffix-length 13
-
- H
- Headers
- Accept-Ranges 9
- Content-Range 9
- If-Range 11
- Range 12
-
- I
- If-Range header 11
-
- M
- Media Type
- multipart/byteranges 17
- multipart/x-byteranges 20
- multipart/byteranges Media Type 17
- multipart/x-byteranges Media Type 20
-
- R
- Range header 12
-
- S
- Status Codes
- 206 Partial Content 7
- 416 Requested Range Not Satisfiable 8
-
-Authors' Addresses
-
- Roy T. Fielding (editor)
- Day Software
- 23 Corporate Plaza DR, Suite 280
- Newport Beach, CA 92660
- USA
-
- Phone: +1-949-706-5300
- Fax: +1-949-706-5305
- EMail: fielding@gbiv.com
- URI: http://roy.gbiv.com/
-
-
-
-
-
-
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 25]
-
-Internet-Draft HTTP/1.1, Part 5 August 2010
-
-
- Jim Gettys
- Alcatel-Lucent Bell Labs
- 21 Oak Knoll Road
- Carlisle, MA 01741
- USA
-
- EMail: jg@freedesktop.org
- URI: http://gettys.wordpress.com/
-
-
- Jeffrey C. Mogul
- Hewlett-Packard Company
- HP Labs, Large Scale Systems Group
- 1501 Page Mill Road, MS 1177
- Palo Alto, CA 94304
- USA
-
- EMail: JeffMogul@acm.org
-
-
- Henrik Frystyk Nielsen
- Microsoft Corporation
- 1 Microsoft Way
- Redmond, WA 98052
- USA
-
- EMail: henrikn@microsoft.com
-
-
- Larry Masinter
- Adobe Systems, Incorporated
- 345 Park Ave
- San Jose, CA 95110
- USA
-
- EMail: LMM@acm.org
- URI: http://larry.masinter.net/
-
-
- Paul J. Leach
- Microsoft Corporation
- 1 Microsoft Way
- Redmond, WA 98052
-
- EMail: paulle@microsoft.com
-
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 26]
-
-Internet-Draft HTTP/1.1, Part 5 August 2010
-
-
- Tim Berners-Lee
- World Wide Web Consortium
- MIT Computer Science and Artificial Intelligence Laboratory
- The Stata Center, Building 32
- 32 Vassar Street
- Cambridge, MA 02139
- USA
-
- EMail: timbl@w3.org
- URI: http://www.w3.org/People/Berners-Lee/
-
-
- Yves Lafon (editor)
- World Wide Web Consortium
- W3C / ERCIM
- 2004, rte des Lucioles
- Sophia-Antipolis, AM 06902
- France
-
- EMail: ylafon@w3.org
- URI: http://www.raubacapeu.net/people/yves/
-
-
- Julian F. Reschke (editor)
- greenbytes GmbH
- Hafenweg 16
- Muenster, NW 48155
- Germany
-
- Phone: +49 251 2807760
- Fax: +49 251 2807761
- EMail: julian.reschke@greenbytes.de
- URI: http://greenbytes.de/tech/webdav/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 27]
-
diff --git a/vendor/sabre/dav/docs/draft-ietf-httpbis-p6-cache-11.txt b/vendor/sabre/dav/docs/draft-ietf-httpbis-p6-cache-11.txt
deleted file mode 100644
index 35b875615..000000000
--- a/vendor/sabre/dav/docs/draft-ietf-httpbis-p6-cache-11.txt
+++ /dev/null
@@ -1,2352 +0,0 @@
-
-
-
-HTTPbis Working Group R. Fielding, Ed.
-Internet-Draft Day Software
-Obsoletes: 2616 (if approved) J. Gettys
-Intended status: Standards Track Alcatel-Lucent
-Expires: February 5, 2011 J. Mogul
- HP
- H. Frystyk
- Microsoft
- L. Masinter
- Adobe Systems
- P. Leach
- Microsoft
- T. Berners-Lee
- W3C/MIT
- Y. Lafon, Ed.
- W3C
- M. Nottingham, Ed.
-
- J. Reschke, Ed.
- greenbytes
- August 4, 2010
-
-
- HTTP/1.1, part 6: Caching
- draft-ietf-httpbis-p6-cache-11
-
-Abstract
-
- The Hypertext Transfer Protocol (HTTP) is an application-level
- protocol for distributed, collaborative, hypermedia information
- systems. This document is Part 6 of the seven-part specification
- that defines the protocol referred to as "HTTP/1.1" and, taken
- together, obsoletes RFC 2616. Part 6 defines requirements on HTTP
- caches and the associated header fields that control cache behavior
- or indicate cacheable response messages.
-
-Editorial Note (To be removed by RFC Editor)
-
- Discussion of this draft should take place on the HTTPBIS working
- group mailing list (ietf-http-wg@w3.org). The current issues list is
- at and related
- documents (including fancy diffs) can be found at
- .
-
- The changes in this draft are summarized in Appendix C.12.
-
-Status of This Memo
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 1]
-
-Internet-Draft HTTP/1.1, Part 6 August 2010
-
-
- This Internet-Draft is submitted in full conformance with the
- provisions of BCP 78 and BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF). Note that other groups may also distribute
- working documents as Internet-Drafts. The list of current Internet-
- Drafts is at http://datatracker.ietf.org/drafts/current/.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- This Internet-Draft will expire on February 5, 2011.
-
-Copyright Notice
-
- Copyright (c) 2010 IETF Trust and the persons identified as the
- document authors. All rights reserved.
-
- This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents
- (http://trustee.ietf.org/license-info) in effect on the date of
- publication of this document. Please review these documents
- carefully, as they describe your rights and restrictions with respect
- to this document. Code Components extracted from this document must
- include Simplified BSD License text as described in Section 4.e of
- the Trust Legal Provisions and are provided without warranty as
- described in the Simplified BSD License.
-
- This document may contain material from IETF Documents or IETF
- Contributions published or made publicly available before November
- 10, 2008. The person(s) controlling the copyright in some of this
- material may not have granted the IETF Trust the right to allow
- modifications of such material outside the IETF Standards Process.
- Without obtaining an adequate license from the person(s) controlling
- the copyright in such materials, this document may not be modified
- outside the IETF Standards Process, and derivative works of it may
- not be created outside the IETF Standards Process, except to format
- it for publication as an RFC or to translate it into languages other
- than English.
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
- 1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 2]
-
-Internet-Draft HTTP/1.1, Part 6 August 2010
-
-
- 1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7
- 1.4.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7
- 1.4.2. ABNF Rules defined in other Parts of the
- Specification . . . . . . . . . . . . . . . . . . . . 7
- 2. Cache Operation . . . . . . . . . . . . . . . . . . . . . . . 7
- 2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 7
- 2.1.1. Storing Partial and Incomplete Responses . . . . . . . 8
- 2.2. Constructing Responses from Caches . . . . . . . . . . . . 9
- 2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 10
- 2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 11
- 2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 12
- 2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 13
- 2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 14
- 2.5. Request Methods that Invalidate . . . . . . . . . . . . . 14
- 2.6. Shared Caching of Authenticated Responses . . . . . . . . 15
- 2.7. Caching Negotiated Responses . . . . . . . . . . . . . . . 16
- 2.8. Combining Responses . . . . . . . . . . . . . . . . . . . 16
- 3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 17
- 3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
- 3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 18
- 3.2.1. Request Cache-Control Directives . . . . . . . . . . . 18
- 3.2.2. Response Cache-Control Directives . . . . . . . . . . 20
- 3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 22
- 3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 24
- 3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 24
- 3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
- 3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 26
- 4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 28
- 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
- 5.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 28
- 5.2. Header Field Registration . . . . . . . . . . . . . . . . 29
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
- 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
- 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
- 8.1. Normative References . . . . . . . . . . . . . . . . . . . 30
- 8.2. Informative References . . . . . . . . . . . . . . . . . . 31
- Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 31
- Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 31
- Appendix C. Change Log (to be removed by RFC Editor before
- publication) . . . . . . . . . . . . . . . . . . . . 33
- C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 33
- C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 33
- C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 34
- C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 34
- C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 34
- C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 34
- C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 35
- C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 35
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 3]
-
-Internet-Draft HTTP/1.1, Part 6 August 2010
-
-
- C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 35
- C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 36
- C.11. Since draft-ietf-httpbis-p6-cache-09 . . . . . . . . . . . 36
- C.12. Since draft-ietf-httpbis-p6-cache-10 . . . . . . . . . . . 37
- Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 4]
-
-Internet-Draft HTTP/1.1, Part 6 August 2010
-
-
-1. Introduction
-
- HTTP is typically used for distributed information systems, where
- performance can be improved by the use of response caches. This
- document defines aspects of HTTP/1.1 related to caching and reusing
- response messages.
-
-1.1. Purpose
-
- An HTTP cache is a local store of response messages and the subsystem
- that controls its message storage, retrieval, and deletion. A cache
- stores cacheable responses in order to reduce the response time and
- network bandwidth consumption on future, equivalent requests. Any
- client or server MAY employ a cache, though a cache cannot be used by
- a server that is acting as a tunnel.
-
- Caching would be useless if it did not significantly improve
- performance. The goal of caching in HTTP/1.1 is to reuse a prior
- response message to satisfy a current request. In some cases, a
- stored response can be reused without the need for a network request,
- reducing latency and network round-trips; a "freshness" mechanism is
- used for this purpose (see Section 2.3). Even when a new request is
- required, it is often possible to reuse all or parts of the payload
- of a prior response to satisfy the request, thereby reducing network
- bandwidth usage; a "validation" mechanism is used for this purpose
- (see Section 2.4).
-
-1.2. Terminology
-
- This specification uses a number of terms to refer to the roles
- played by participants in, and objects of, HTTP caching.
-
- cacheable
-
- A response is cacheable if a cache is allowed to store a copy of
- the response message for use in answering subsequent requests.
- Even when a response is cacheable, there might be additional
- constraints on whether a cache can use the cached copy to satisfy
- a particular request.
-
- explicit expiration time
-
- The time at which the origin server intends that a representation
- no longer be returned by a cache without further validation.
-
-
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 5]
-
-Internet-Draft HTTP/1.1, Part 6 August 2010
-
-
- heuristic expiration time
-
- An expiration time assigned by a cache when no explicit expiration
- time is available.
-
- age
-
- The age of a response is the time since it was sent by, or
- successfully validated with, the origin server.
-
- first-hand
-
- A response is first-hand if the freshness model is not in use;
- i.e., its age is 0.
-
- freshness lifetime
-
- The length of time between the generation of a response and its
- expiration time.
-
- fresh
-
- A response is fresh if its age has not yet exceeded its freshness
- lifetime.
-
- stale
-
- A response is stale if its age has passed its freshness lifetime
- (either explicit or heuristic).
-
- validator
-
- A protocol element (e.g., an entity-tag or a Last-Modified time)
- that is used to find out whether a stored response has an
- equivalent copy of a representation.
-
- shared cache
-
- A cache that is accessible to more than one user. A non-shared
- cache is dedicated to a single user.
-
-1.3. Requirements
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
- An implementation is not compliant if it fails to satisfy one or more
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 6]
-
-Internet-Draft HTTP/1.1, Part 6 August 2010
-
-
- of the "MUST" or "REQUIRED" level requirements for the protocols it
- implements. An implementation that satisfies all the "MUST" or
- "REQUIRED" level and all the "SHOULD" level requirements for its
- protocols is said to be "unconditionally compliant"; one that
- satisfies all the "MUST" level requirements but not all the "SHOULD"
- level requirements for its protocols is said to be "conditionally
- compliant".
-
-1.4. Syntax Notation
-
- This specification uses the ABNF syntax defined in Section 1.2 of
- [Part1] (which extends the syntax defined in [RFC5234] with a list
- rule). Appendix B shows the collected ABNF, with the list rule
- expanded.
-
- The following core rules are included by reference, as defined in
- [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
- (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
- HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
- sequence of data), SP (space), VCHAR (any visible USASCII character),
- and WSP (whitespace).
-
-1.4.1. Core Rules
-
- The core rules below are defined in Section 1.2.2 of [Part1]:
-
- quoted-string =
- token =
- OWS =
-
-1.4.2. ABNF Rules defined in other Parts of the Specification
-
- The ABNF rules below are defined in other parts:
-
- field-name =
- HTTP-date =
- port =
- pseudonym =
- uri-host =
-
-2. Cache Operation
-
-2.1. Response Cacheability
-
- A cache MUST NOT store a response to any request, unless:
-
- o The request method is understood by the cache and defined as being
- cacheable, and
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 7]
-
-Internet-Draft HTTP/1.1, Part 6 August 2010
-
-
- o the response status code is understood by the cache, and
-
- o the "no-store" cache directive (see Section 3.2) does not appear
- in request or response headers, and
-
- o the "private" cache response directive (see Section 3.2.2 does not
- appear in the response, if the cache is shared, and
-
- o the "Authorization" header (see Section 3.1 of [Part7]) does not
- appear in the request, if the cache is shared, unless the response
- explicitly allows it (see Section 2.6), and
-
- o the response either:
-
- * contains an Expires header (see Section 3.3), or
-
- * contains a max-age response cache directive (see
- Section 3.2.2), or
-
- * contains a s-maxage response cache directive and the cache is
- shared, or
-
- * contains a Cache Control Extension (see Section 3.2.3) that
- allows it to be cached, or
-
- * has a status code that can be served with heuristic freshness
- (see Section 2.3.1.1).
-
- In this context, a cache has "understood" a request method or a
- response status code if it recognises it and implements any cache-
- specific behaviour. In particular, 206 Partial Content responses
- cannot be cached by an implementation that does not handle partial
- content (see Section 2.1.1).
-
- Note that in normal operation, most caches will not store a response
- that has neither a cache validator nor an explicit expiration time,
- as such responses are not usually useful to store. However, caches
- are not prohibited from storing such responses.
-
-2.1.1. Storing Partial and Incomplete Responses
-
- A cache that receives an incomplete response (for example, with fewer
- bytes of data than specified in a Content-Length header) can store
- the response, but MUST treat it as a partial response [Part5].
- Partial responses can be combined as described in Section 4 of
- [Part5]; the result might be a full response or might still be
- partial. A cache MUST NOT return a partial response to a client
- without explicitly marking it as such using the 206 (Partial Content)
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 8]
-
-Internet-Draft HTTP/1.1, Part 6 August 2010
-
-
- status code.
-
- A cache that does not support the Range and Content-Range headers
- MUST NOT store incomplete or partial responses.
-
-2.2. Constructing Responses from Caches
-
- For a presented request, a cache MUST NOT return a stored response,
- unless:
-
- o The presented effective request URI (Section 4.3 of [Part1]) and
- that of the stored response match, and
-
- o the request method associated with the stored response allows it
- to be used for the presented request, and
-
- o selecting request-headers nominated by the stored response (if
- any) match those presented (see Section 2.7), and
-
- o the presented request and stored response are free from directives
- that would prevent its use (see Section 3.2 and Section 3.4), and
-
- o the stored response is either:
-
- * fresh (see Section 2.3), or
-
- * allowed to be served stale (see Section 2.3.3), or
-
- * successfully validated (see Section 2.4).
-
- When a stored response is used to satisfy a request without
- validation, caches MUST include a single Age header field
- (Section 3.1) in the response with a value equal to the stored
- response's current_age; see Section 2.3.2.
-
- Requests with methods that are unsafe (Section 7.1.1 of [Part2]) MUST
- be written through the cache to the origin server; i.e., a cache must
- not reply to such a request before having forwarded the request and
- having received a corresponding response.
-
- Also, note that unsafe requests might invalidate already stored
- responses; see Section 2.5.
-
- Caches MUST use the most recent response (as determined by the Date
- header) when more than one suitable response is stored. They can
- also forward a request with "Cache-Control: max-age=0" or "Cache-
- Control: no-cache" to disambiguate which response to use.
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 9]
-
-Internet-Draft HTTP/1.1, Part 6 August 2010
-
-
-2.3. Freshness Model
-
- When a response is "fresh" in the cache, it can be used to satisfy
- subsequent requests without contacting the origin server, thereby
- improving efficiency.
-
- The primary mechanism for determining freshness is for an origin
- server to provide an explicit expiration time in the future, using
- either the Expires header (Section 3.3) or the max-age response cache
- directive (Section 3.2.2). Generally, origin servers will assign
- future explicit expiration times to responses in the belief that the
- representation is not likely to change in a semantically significant
- way before the expiration time is reached.
-
- If an origin server wishes to force a cache to validate every
- request, it can assign an explicit expiration time in the past to
- indicate that the response is already stale. Compliant caches will
- validate the cached response before reusing it for subsequent
- requests.
-
- Since origin servers do not always provide explicit expiration times,
- HTTP caches MAY assign heuristic expiration times when explicit times
- are not specified, employing algorithms that use other header values
- (such as the Last-Modified time) to estimate a plausible expiration
- time. The HTTP/1.1 specification does not provide specific
- algorithms, but does impose worst-case constraints on their results.
-
- The calculation to determine if a response is fresh is:
-
- response_is_fresh = (freshness_lifetime > current_age)
-
- The freshness_lifetime is defined in Section 2.3.1; the current_age
- is defined in Section 2.3.2.
-
- Additionally, clients might need to influence freshness calculation.
- They can do this using several request cache directives, with the
- effect of either increasing or loosening constraints on freshness.
- See Section 3.2.1.
-
- [[ISSUE-no-req-for-directives: there are not requirements directly
- applying to cache-request-directives and freshness.]]
-
- Note that freshness applies only to cache operation; it cannot be
- used to force a user agent to refresh its display or reload a
- resource. See Section 4 for an explanation of the difference between
- caches and history mechanisms.
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 10]
-
-Internet-Draft HTTP/1.1, Part 6 August 2010
-
-
-2.3.1. Calculating Freshness Lifetime
-
- A cache can calculate the freshness lifetime (denoted as
- freshness_lifetime) of a response by using the first match of:
-
- o If the cache is shared and the s-maxage response cache directive
- (Section 3.2.2) is present, use its value, or
-
- o If the max-age response cache directive (Section 3.2.2) is
- present, use its value, or
-
- o If the Expires response header (Section 3.3) is present, use its
- value minus the value of the Date response header, or
-
- o Otherwise, no explicit expiration time is present in the response.
- A heuristic freshness lifetime might be applicable; see
- Section 2.3.1.1.
-
- Note that this calculation is not vulnerable to clock skew, since all
- of the information comes from the origin server.
-
-2.3.1.1. Calculating Heuristic Freshness
-
- If no explicit expiration time is present in a stored response that
- has a status code whose definition allows heuristic freshness to be
- used (including the following in Section 8 of [Part2]: 200, 203, 206,
- 300, 301 and 410), a heuristic expiration time MAY be calculated.
- Heuristics MUST NOT be used for response status codes that do not
- explicitly allow it.
-
- When a heuristic is used to calculate freshness lifetime, the cache
- SHOULD attach a Warning header with a 113 warn-code to the response
- if its current_age is more than 24 hours and such a warning is not
- already present.
-
- Also, if the response has a Last-Modified header (Section 6.6 of
- [Part4]), the heuristic expiration value SHOULD be no more than some
- fraction of the interval since that time. A typical setting of this
- fraction might be 10%.
-
- Note: RFC 2616 ([RFC2616], Section 13.9) required that caches do
- not calculate heuristic freshness for URLs with query components
- (i.e., those containing '?'). In practice, this has not been
- widely implemented. Therefore, servers are encouraged to send
- explicit directives (e.g., Cache-Control: no-cache) if they wish
- to preclude caching.
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 11]
-
-Internet-Draft HTTP/1.1, Part 6 August 2010
-
-
-2.3.2. Calculating Age
-
- HTTP/1.1 uses the Age response-header to convey the estimated age of
- the response message when obtained from a cache. The Age field value
- is the cache's estimate of the amount of time since the response was
- generated or validated by the origin server. In essence, the Age
- value is the sum of the time that the response has been resident in
- each of the caches along the path from the origin server, plus the
- amount of time it has been in transit along network paths.
-
- The following data is used for the age calculation:
-
- age_value
-
- The term "age_value" denotes the value of the Age header
- (Section 3.1), in a form appropriate for arithmetic operation; or
- 0, if not available.
-
- date_value
-
- HTTP/1.1 requires origin servers to send a Date header, if
- possible, with every response, giving the time at which the
- response was generated. The term "date_value" denotes the value
- of the Date header, in a form appropriate for arithmetic
- operations. See Section 9.3 of [Part1] for the definition of the
- Date header, and for requirements regarding responses without a
- Date response header.
-
- now
-
- The term "now" means "the current value of the clock at the host
- performing the calculation". Hosts that use HTTP, but especially
- hosts running origin servers and caches, SHOULD use NTP
- ([RFC1305]) or some similar protocol to synchronize their clocks
- to a globally accurate time standard.
-
- request_time
-
- The current value of the clock at the host at the time the request
- resulting in the stored response was made.
-
- response_time
-
- The current value of the clock at the host at the time the
- response was received.
-
- A response's age can be calculated in two entirely independent ways:
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 12]
-
-Internet-Draft HTTP/1.1, Part 6 August 2010
-
-
- 1. the "apparent_age": response_time minus date_value, if the local
- clock is reasonably well synchronized to the origin server's
- clock. If the result is negative, the result is replaced by
- zero.
-
- 2. the "corrected_age_value", if all of the caches along the
- response path implement HTTP/1.1; note this value MUST be
- interpreted relative to the time the request was initiated, not
- the time that the response was received.
-
-
- apparent_age = max(0, response_time - date_value);
-
- response_delay = response_time - request_time;
- corrected_age_value = age_value + response_delay;
-
- These are combined as
-
- corrected_initial_age = max(apparent_age, corrected_age_value);
-
- The current_age of a stored response can then be calculated by adding
- the amount of time (in seconds) since the stored response was last
- validated by the origin server to the corrected_initial_age.
-
- resident_time = now - response_time;
- current_age = corrected_initial_age + resident_time;
-
-2.3.3. Serving Stale Responses
-
- A "stale" response is one that either has explicit expiry information
- or is allowed to have heuristic expiry calculated, but is not fresh
- according to the calculations in Section 2.3.
-
- Caches MUST NOT return a stale response if it is prohibited by an
- explicit in-protocol directive (e.g., by a "no-store" or "no-cache"
- cache directive, a "must-revalidate" cache-response-directive, or an
- applicable "s-maxage" or "proxy-revalidate" cache-response-directive;
- see Section 3.2.2).
-
- Caches SHOULD NOT return stale responses unless they are disconnected
- (i.e., it cannot contact the origin server or otherwise find a
- forward path) or otherwise explicitly allowed (e.g., the max-stale
- request directive; see Section 3.2.1).
-
- Stale responses SHOULD have a Warning header with the 110 warn-code
- (see Section 3.6). Likewise, the 112 warn-code SHOULD be sent on
- stale responses if the cache is disconnected.
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 13]
-
-Internet-Draft HTTP/1.1, Part 6 August 2010
-
-
- If a cache receives a first-hand response (either an entire response,
- or a 304 (Not Modified) response) that it would normally forward to
- the requesting client, and the received response is no longer fresh,
- the cache SHOULD forward it to the requesting client without adding a
- new Warning (but without removing any existing Warning headers). A
- cache SHOULD NOT attempt to validate a response simply because that
- response became stale in transit.
-
-2.4. Validation Model
-
- When a cache has one or more stored responses for a requested URI,
- but cannot serve any of them (e.g., because they are not fresh, or
- one cannot be selected; see Section 2.7), it can use the conditional
- request mechanism [Part4] in the forwarded request to give the origin
- server an opportunity to both select a valid stored response to be
- used, and to update it. This process is known as "validating" or
- "revalidating" the stored response.
-
- When sending such a conditional request, the cache SHOULD add an If-
- Modified-Since header whose value is that of the Last-Modified header
- from the selected (see Section 2.7) stored response, if available.
-
- Additionally, the cache SHOULD add an If-None-Match header whose
- value is that of the ETag header(s) from all responses stored for the
- requested URI, if present. However, if any of the stored responses
- contains only partial content, its entity-tag SHOULD NOT be included
- in the If-None-Match header field unless the request is for a range
- that would be fully satisfied by that stored response.
-
- A 304 (Not Modified) response status code indicates that the stored
- response can be updated and reused; see Section 2.8.
-
- A full response (i.e., one with a response body) indicates that none
- of the stored responses nominated in the conditional request is
- suitable. Instead, the full response SHOULD be used to satisfy the
- request and MAY replace the stored response.
-
- If a cache receives a 5xx response while attempting to validate a
- response, it MAY either forward this response to the requesting
- client, or act as if the server failed to respond. In the latter
- case, it MAY return a previously stored response (see Section 2.3.3).
-
-2.5. Request Methods that Invalidate
-
- Because unsafe methods (Section 7.1.1 of [Part2]) have the potential
- for changing state on the origin server, intervening caches can use
- them to keep their contents up-to-date.
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 14]
-
-Internet-Draft HTTP/1.1, Part 6 August 2010
-
-
- The following HTTP methods MUST cause a cache to invalidate the
- effective Request URI (Section 4.3 of [Part1]) as well as the URI(s)
- in the Location and Content-Location headers (if present):
-
- o PUT
-
- o DELETE
-
- o POST
-
- An invalidation based on a URI from a Location or Content-Location
- header MUST NOT be performed if the host part of that URI differs
- from the host part in the effective request URI (Section 4.3 of
- [Part1]). This helps prevent denial of service attacks.
-
- A cache that passes through requests for methods it does not
- understand SHOULD invalidate the effective request URI (Section 4.3
- of [Part1]).
-
- Here, "invalidate" means that the cache will either remove all stored
- responses related to the effective request URI, or will mark these as
- "invalid" and in need of a mandatory validation before they can be
- returned in response to a subsequent request.
-
- Note that this does not guarantee that all appropriate responses are
- invalidated. For example, the request that caused the change at the
- origin server might not have gone through the cache where a response
- is stored.
-
-2.6. Shared Caching of Authenticated Responses
-
- Shared caches MUST NOT use a cached response to a request with an
- Authorization header (Section 3.1 of [Part7]) to satisfy any
- subsequent request unless a cache directive that allows such
- responses to be stored is present in the response.
-
- In this specification, the following Cache-Control response
- directives (Section 3.2.2) have such an effect: must-revalidate,
- public, s-maxage.
-
- Note that cached responses that contain the "must-revalidate" and/or
- "s-maxage" response directives are not allowed to be served stale
- (Section 2.3.3) by shared caches. In particular, a response with
- either "max-age=0, must-revalidate" or "s-maxage=0" cannot be used to
- satisfy a subsequent request without revalidating it on the origin
- server.
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 15]
-
-Internet-Draft HTTP/1.1, Part 6 August 2010
-
-
-2.7. Caching Negotiated Responses
-
- When a cache receives a request that can be satisfied by a stored
- response that has a Vary header field (Section 3.5), it MUST NOT use
- that response unless all of the selecting request-headers nominated
- by the Vary header match in both the original request (i.e., that
- associated with the stored response), and the presented request.
-
- The selecting request-headers from two requests are defined to match
- if and only if those in the first request can be transformed to those
- in the second request by applying any of the following:
-
- o adding or removing whitespace, where allowed in the header's
- syntax
-
- o combining multiple message-header fields with the same field name
- (see Section 3.2 of [Part1])
-
- o normalizing both header values in a way that is known to have
- identical semantics, according to the header's specification
- (e.g., re-ordering field values when order is not significant;
- case-normalization, where values are defined to be case-
- insensitive)
-
- If (after any normalization that might take place) a header field is
- absent from a request, it can only match another request if it is
- also absent there.
-
- A Vary header field-value of "*" always fails to match, and
- subsequent requests to that resource can only be properly interpreted
- by the origin server.
-
- The stored response with matching selecting request-headers is known
- as the selected response.
-
- If no selected response is available, the cache MAY forward the
- presented request to the origin server in a conditional request; see
- Section 2.4.
-
-2.8. Combining Responses
-
- When a cache receives a 304 (Not Modified) response or a 206 (Partial
- Content) response (in this section, the "new" response"), it needs to
- created an updated response by combining the stored response with the
- new one, so that the updated response can be used to satisfy the
- request, and potentially update the cached response.
-
- If the new response contains an ETag, it identifies the stored
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 16]
-
-Internet-Draft HTTP/1.1, Part 6 August 2010
-
-
- response to use. [[TODO-mention-CL: might need language about
- Content-Location here]][[TODO-select-for-combine: Shouldn't this be
- the selected response?]]
-
- If the new response's status code is 206 (partial content), both the
- stored and new responses MUST have validators, and those validators
- MUST match using the strong comparison function (see Section 4 of
- [Part4]). Otherwise, the responses MUST NOT be combined.
-
- The stored response headers are used as those of the updated
- response, except that
-
- o any stored Warning headers with warn-code 1xx (see Section 3.6)
- MUST be deleted.
-
- o any stored Warning headers with warn-code 2xx MUST be retained.
-
- o any other headers provided in the new response MUST replace all
- instances of the corresponding headers from the stored response.
-
- The updated response headers MUST be used to replace those of the
- stored response in cache (unless the stored response is removed from
- cache). In the case of a 206 response, the combined representation
- MAY be stored.
-
-3. Header Field Definitions
-
- This section defines the syntax and semantics of HTTP/1.1 header
- fields related to caching.
-
-3.1. Age
-
- The "Age" response-header field conveys the sender's estimate of the
- amount of time since the response was generated or successfully
- validated at the origin server. Age values are calculated as
- specified in Section 2.3.2.
-
- Age = "Age" ":" OWS Age-v
- Age-v = delta-seconds
-
- Age field-values are non-negative integers, representing time in
- seconds.
-
- delta-seconds = 1*DIGIT
-
- If a cache receives a value larger than the largest positive integer
- it can represent, or if any of its age calculations overflows, it
- MUST transmit an Age header with a field-value of 2147483648 (2^31).
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 17]
-
-Internet-Draft HTTP/1.1, Part 6 August 2010
-
-
- Caches SHOULD use an arithmetic type of at least 31 bits of range.
-
- The presence of an Age header field in a response implies that a
- response is not first-hand. However, the converse is not true, since
- HTTP/1.0 caches might not implement the Age header field.
-
-3.2. Cache-Control
-
- The "Cache-Control" general-header field is used to specify
- directives for caches along the request/response chain. Such cache
- directives are unidirectional in that the presence of a directive in
- a request does not imply that the same directive is to be given in
- the response.
-
- HTTP/1.1 caches MUST obey the requirements of the Cache-Control
- directives defined in this section. See Section 3.2.3 for
- information about how Cache-Control directives defined elsewhere are
- handled.
-
- Note: HTTP/1.0 caches might not implement Cache-Control and might
- only implement Pragma: no-cache (see Section 3.4).
-
- Cache directives MUST be passed through by a proxy or gateway
- application, regardless of their significance to that application,
- since the directives might be applicable to all recipients along the
- request/response chain. It is not possible to target a directive to
- a specific cache.
-
- Cache-Control = "Cache-Control" ":" OWS Cache-Control-v
- Cache-Control-v = 1#cache-directive
-
- cache-directive = cache-request-directive
- / cache-response-directive
-
- cache-extension = token [ "=" ( token / quoted-string ) ]
-
-3.2.1. Request Cache-Control Directives
-
- cache-request-directive =
- "no-cache"
- / "no-store"
- / "max-age" "=" delta-seconds
- / "max-stale" [ "=" delta-seconds ]
- / "min-fresh" "=" delta-seconds
- / "no-transform"
- / "only-if-cached"
- / cache-extension
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 18]
-
-Internet-Draft HTTP/1.1, Part 6 August 2010
-
-
- no-cache
-
- The no-cache request directive indicates that a stored response
- MUST NOT be used to satisfy the request without successful
- validation on the origin server.
-
- no-store
-
- The no-store request directive indicates that a cache MUST NOT
- store any part of either this request or any response to it. This
- directive applies to both non-shared and shared caches. "MUST NOT
- store" in this context means that the cache MUST NOT intentionally
- store the information in non-volatile storage, and MUST make a
- best-effort attempt to remove the information from volatile
- storage as promptly as possible after forwarding it.
-
- This directive is NOT a reliable or sufficient mechanism for
- ensuring privacy. In particular, malicious or compromised caches
- might not recognize or obey this directive, and communications
- networks might be vulnerable to eavesdropping.
-
- max-age
-
- The max-age request directive indicates that the client is willing
- to accept a response whose age is no greater than the specified
- time in seconds. Unless the max-stale request directive is also
- present, the client is not willing to accept a stale response.
-
- max-stale
-
- The max-stale request directive indicates that the client is
- willing to accept a response that has exceeded its expiration
- time. If max-stale is assigned a value, then the client is
- willing to accept a response that has exceeded its expiration time
- by no more than the specified number of seconds. If no value is
- assigned to max-stale, then the client is willing to accept a
- stale response of any age.
-
- min-fresh
-
- The min-fresh request directive indicates that the client is
- willing to accept a response whose freshness lifetime is no less
- than its current age plus the specified time in seconds. That is,
- the client wants a response that will still be fresh for at least
- the specified number of seconds.
-
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 19]
-
-Internet-Draft HTTP/1.1, Part 6 August 2010
-
-
- no-transform
-
- The no-transform request directive indicates that an intermediate
- cache or proxy MUST NOT change the Content-Encoding, Content-Range
- or Content-Type request headers, nor the request representation.
-
- only-if-cached
-
- The only-if-cached request directive indicates that the client
- only wishes to return a stored response. If it receives this
- directive, a cache SHOULD either respond using a stored response
- that is consistent with the other constraints of the request, or
- respond with a 504 (Gateway Timeout) status code. If a group of
- caches is being operated as a unified system with good internal
- connectivity, such a request MAY be forwarded within that group of
- caches.
-
-3.2.2. Response Cache-Control Directives
-
- cache-response-directive =
- "public"
- / "private" [ "=" DQUOTE 1#field-name DQUOTE ]
- / "no-cache" [ "=" DQUOTE 1#field-name DQUOTE ]
- / "no-store"
- / "no-transform"
- / "must-revalidate"
- / "proxy-revalidate"
- / "max-age" "=" delta-seconds
- / "s-maxage" "=" delta-seconds
- / cache-extension
-
- public
-
- The public response directive indicates that the response MAY be
- cached, even if it would normally be non-cacheable or cacheable
- only within a non-shared cache. (See also Authorization, Section
- 3.1 of [Part7], for additional details.)
-
- private
-
- The private response directive indicates that the response message
- is intended for a single user and MUST NOT be stored by a shared
- cache. A private (non-shared) cache MAY store the response.
-
- If the private response directive specifies one or more field-
- names, this requirement is limited to the field-values associated
- with the listed response headers. That is, the specified field-
- names(s) MUST NOT be stored by a shared cache, whereas the
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 20]
-
-Internet-Draft HTTP/1.1, Part 6 August 2010
-
-
- remainder of the response message MAY be.
-
- Note: This usage of the word private only controls where the
- response can be stored; it cannot ensure the privacy of the
- message content. Also, private response directives with field-
- names are often handled by implementations as if an unqualified
- private directive was received; i.e., the special handling for the
- qualified form is not widely implemented.
-
- no-cache
-
- The no-cache response directive indicates that the response MUST
- NOT be used to satisfy a subsequent request without successful
- validation on the origin server. This allows an origin server to
- prevent a cache from using it to satisfy a request without
- contacting it, even by caches that have been configured to return
- stale responses.
-
- If the no-cache response directive specifies one or more field-
- names, this requirement is limited to the field-values associated
- with the listed response headers. That is, the specified field-
- name(s) MUST NOT be sent in the response to a subsequent request
- without successful validation on the origin server. This allows
- an origin server to prevent the re-use of certain header fields in
- a response, while still allowing caching of the rest of the
- response.
-
- Note: Most HTTP/1.0 caches will not recognize or obey this
- directive. Also, no-cache response directives with field-names
- are often handled by implementations as if an unqualified no-cache
- directive was received; i.e., the special handling for the
- qualified form is not widely implemented.
-
- no-store
-
- The no-store response directive indicates that a cache MUST NOT
- store any part of either the immediate request or response. This
- directive applies to both non-shared and shared caches. "MUST NOT
- store" in this context means that the cache MUST NOT intentionally
- store the information in non-volatile storage, and MUST make a
- best-effort attempt to remove the information from volatile
- storage as promptly as possible after forwarding it.
-
- This directive is NOT a reliable or sufficient mechanism for
- ensuring privacy. In particular, malicious or compromised caches
- might not recognize or obey this directive, and communications
- networks might be vulnerable to eavesdropping.
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 21]
-
-Internet-Draft HTTP/1.1, Part 6 August 2010
-
-
- must-revalidate
-
- The must-revalidate response directive indicates that once it has
- become stale, the response MUST NOT be used to satisfy subsequent
- requests without successful validation on the origin server.
-
- The must-revalidate directive is necessary to support reliable
- operation for certain protocol features. In all circumstances an
- HTTP/1.1 cache MUST obey the must-revalidate directive; in
- particular, if the cache cannot reach the origin server for any
- reason, it MUST generate a 504 (Gateway Timeout) response.
-
- Servers SHOULD send the must-revalidate directive if and only if
- failure to validate a request on the representation could result
- in incorrect operation, such as a silently unexecuted financial
- transaction.
-
- proxy-revalidate
-
- The proxy-revalidate response directive has the same meaning as
- the must-revalidate response directive, except that it does not
- apply to non-shared caches.
-
- max-age
-
- The max-age response directive indicates that response is to be
- considered stale after its age is greater than the specified
- number of seconds.
-
- s-maxage
-
- The s-maxage response directive indicates that, in shared caches,
- the maximum age specified by this directive overrides the maximum
- age specified by either the max-age directive or the Expires
- header. The s-maxage directive also implies the semantics of the
- proxy-revalidate response directive.
-
- no-transform
-
- The no-transform response directive indicates that an intermediate
- cache or proxy MUST NOT change the Content-Encoding, Content-Range
- or Content-Type response headers, nor the response representation.
-
-3.2.3. Cache Control Extensions
-
- The Cache-Control header field can be extended through the use of one
- or more cache-extension tokens, each with an optional value.
- Informational extensions (those that do not require a change in cache
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 22]
-
-Internet-Draft HTTP/1.1, Part 6 August 2010
-
-
- behavior) can be added without changing the semantics of other
- directives. Behavioral extensions are designed to work by acting as
- modifiers to the existing base of cache directives. Both the new
- directive and the standard directive are supplied, such that
- applications that do not understand the new directive will default to
- the behavior specified by the standard directive, and those that
- understand the new directive will recognize it as modifying the
- requirements associated with the standard directive. In this way,
- extensions to the cache-control directives can be made without
- requiring changes to the base protocol.
-
- This extension mechanism depends on an HTTP cache obeying all of the
- cache-control directives defined for its native HTTP-version, obeying
- certain extensions, and ignoring all directives that it does not
- understand.
-
- For example, consider a hypothetical new response directive called
- "community" that acts as a modifier to the private directive. We
- define this new directive to mean that, in addition to any non-shared
- cache, any cache that is shared only by members of the community
- named within its value may cache the response. An origin server
- wishing to allow the UCI community to use an otherwise private
- response in their shared cache(s) could do so by including
-
- Cache-Control: private, community="UCI"
-
- A cache seeing this header field will act correctly even if the cache
- does not understand the community cache-extension, since it will also
- see and understand the private directive and thus default to the safe
- behavior.
-
- Unrecognized cache directives MUST be ignored; it is assumed that any
- cache directive likely to be unrecognized by an HTTP/1.1 cache will
- be combined with standard directives (or the response's default
- cacheability) such that the cache behavior will remain minimally
- correct even if the cache does not understand the extension(s).
-
- The HTTP Cache Directive Registry defines the name space for the
- cache directives.
-
- Registrations MUST include the following fields:
-
- o Cache Directive Name
-
- o Pointer to specification text
-
- Values to be added to this name space are subject to IETF review
- ([RFC5226], Section 4.1).
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 23]
-
-Internet-Draft HTTP/1.1, Part 6 August 2010
-
-
- The registry itself is maintained at
- .
-
-3.3. Expires
-
- The "Expires" header field gives the date/time after which the
- response is considered stale. See Section 2.3 for further discussion
- of the freshness model.
-
- The presence of an Expires field does not imply that the original
- resource will change or cease to exist at, before, or after that
- time.
-
- The field-value is an absolute date and time as defined by HTTP-date
- in Section 6.1 of [Part1]; it MUST be sent in rfc1123-date format.
-
- Expires = "Expires" ":" OWS Expires-v
- Expires-v = HTTP-date
-
- For example
-
- Expires: Thu, 01 Dec 1994 16:00:00 GMT
-
- Note: If a response includes a Cache-Control field with the max-
- age directive (see Section 3.2.2), that directive overrides the
- Expires field. Likewise, the s-maxage directive overrides Expires
- in shared caches.
-
- HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in
- the future.
-
- HTTP/1.1 clients and caches MUST treat other invalid date formats,
- especially including the value "0", as in the past (i.e., "already
- expired").
-
-3.4. Pragma
-
- The "Pragma" general-header field is used to include implementation-
- specific directives that might apply to any recipient along the
- request/response chain. All pragma directives specify optional
- behavior from the viewpoint of the protocol; however, some systems
- MAY require that behavior be consistent with the directives.
-
- Pragma = "Pragma" ":" OWS Pragma-v
- Pragma-v = 1#pragma-directive
- pragma-directive = "no-cache" / extension-pragma
- extension-pragma = token [ "=" ( token / quoted-string ) ]
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 24]
-
-Internet-Draft HTTP/1.1, Part 6 August 2010
-
-
- When the no-cache directive is present in a request message, an
- application SHOULD forward the request toward the origin server even
- if it has a cached copy of what is being requested. This pragma
- directive has the same semantics as the no-cache response directive
- (see Section 3.2.2) and is defined here for backward compatibility
- with HTTP/1.0. Clients SHOULD include both header fields when a no-
- cache request is sent to a server not known to be HTTP/1.1 compliant.
- HTTP/1.1 caches SHOULD treat "Pragma: no-cache" as if the client had
- sent "Cache-Control: no-cache".
-
- Note: Because the meaning of "Pragma: no-cache" as a response-
- header field is not actually specified, it does not provide a
- reliable replacement for "Cache-Control: no-cache" in a response.
-
- This mechanism is deprecated; no new Pragma directives will be
- defined in HTTP.
-
-3.5. Vary
-
- The "Vary" response-header field conveys the set of request-header
- fields that were used to select the representation.
-
- Caches use this information, in part, to determine whether a stored
- response can be used to satisfy a given request; see Section 2.7.
- determines, while the response is fresh, whether a cache is permitted
- to use the response to reply to a subsequent request without
- validation; see Section 2.7.
-
- In uncacheable or stale responses, the Vary field value advises the
- user agent about the criteria that were used to select the
- representation.
-
- Vary = "Vary" ":" OWS Vary-v
- Vary-v = "*" / 1#field-name
-
- The set of header fields named by the Vary field value is known as
- the selecting request-headers.
-
- Servers SHOULD include a Vary header field with any cacheable
- response that is subject to server-driven negotiation. Doing so
- allows a cache to properly interpret future requests on that resource
- and informs the user agent about the presence of negotiation on that
- resource. A server MAY include a Vary header field with a non-
- cacheable response that is subject to server-driven negotiation,
- since this might provide the user agent with useful information about
- the dimensions over which the response varies at the time of the
- response.
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 25]
-
-Internet-Draft HTTP/1.1, Part 6 August 2010
-
-
- A Vary field value of "*" signals that unspecified parameters not
- limited to the request-headers (e.g., the network address of the
- client), play a role in the selection of the response representation;
- therefore, a cache cannot determine whether this response is
- appropriate. The "*" value MUST NOT be generated by a proxy server.
-
- The field-names given are not limited to the set of standard request-
- header fields defined by this specification. Field names are case-
- insensitive.
-
-3.6. Warning
-
- The "Warning" general-header field is used to carry additional
- information about the status or transformation of a message that
- might not be reflected in the message. This information is typically
- used to warn about possible incorrectness introduced by caching
- operations or transformations applied to the payload of the message.
-
- Warnings can be used for other purposes, both cache-related and
- otherwise. The use of a warning, rather than an error status code,
- distinguishes these responses from true failures.
-
- Warning headers can in general be applied to any message, however
- some warn-codes are specific to caches and can only be applied to
- response messages.
-
- Warning = "Warning" ":" OWS Warning-v
- Warning-v = 1#warning-value
-
- warning-value = warn-code SP warn-agent SP warn-text
- [SP warn-date]
-
- warn-code = 3DIGIT
- warn-agent = ( uri-host [ ":" port ] ) / pseudonym
- ; the name or pseudonym of the server adding
- ; the Warning header, for use in debugging
- warn-text = quoted-string
- warn-date = DQUOTE HTTP-date DQUOTE
-
- Multiple warnings can be attached to a response (either by the origin
- server or by a cache), including multiple warnings with the same code
- number, only differing in warn-text.
-
- When this occurs, the user agent SHOULD inform the user of as many of
- them as possible, in the order that they appear in the response.
-
- Systems that generate multiple Warning headers SHOULD order them with
- this user agent behavior in mind. New Warning headers SHOULD be
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 26]
-
-Internet-Draft HTTP/1.1, Part 6 August 2010
-
-
- added after any existing Warning headers.
-
- Warnings are assigned three digit warn-codes. The first digit
- indicates whether the Warning is required to be deleted from a stored
- response after validation:
-
- o 1xx Warnings describe the freshness or validation status of the
- response, and so MUST be deleted by caches after validation. They
- can only be generated by a cache when validating a cached entry,
- and MUST NOT be generated in any other situation.
-
- o 2xx Warnings describe some aspect of the representation that is
- not rectified by a validation (for example, a lossy compression of
- the representation) and MUST NOT be deleted by caches after
- validation, unless a full response is returned, in which case they
- MUST be.
-
- If an implementation sends a message with one or more Warning headers
- to a receiver whose version is HTTP/1.0 or lower, then the sender
- MUST include in each warning-value a warn-date that matches the Date
- header in the message.
-
- If an implementation receives a message with a warning-value that
- includes a warn-date, and that warn-date is different from the Date
- value in the response, then that warning-value MUST be deleted from
- the message before storing, forwarding, or using it. (preventing the
- consequences of naive caching of Warning header fields.) If all of
- the warning-values are deleted for this reason, the Warning header
- MUST be deleted as well.
-
- The following warn-codes are defined by this specification, each with
- a recommended warn-text in English, and a description of its meaning.
-
- 110 Response is stale
-
- SHOULD be included whenever the returned response is stale.
-
- 111 Revalidation failed
-
- SHOULD be included if a cache returns a stale response because an
- attempt to validate the response failed, due to an inability to
- reach the server.
-
- 112 Disconnected operation
-
- SHOULD be included if the cache is intentionally disconnected from
- the rest of the network for a period of time.
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 27]
-
-Internet-Draft HTTP/1.1, Part 6 August 2010
-
-
- 113 Heuristic expiration
-
- SHOULD be included if the cache heuristically chose a freshness
- lifetime greater than 24 hours and the response's age is greater
- than 24 hours.
-
- 199 Miscellaneous warning
-
- The warning text can include arbitrary information to be presented
- to a human user, or logged. A system receiving this warning MUST
- NOT take any automated action, besides presenting the warning to
- the user.
-
- 214 Transformation applied
-
- MUST be added by an intermediate proxy if it applies any
- transformation to the representation, such as changing the
- content-coding, media-type, or modifying the representation data,
- unless this Warning code already appears in the response.
-
- 299 Miscellaneous persistent warning
-
- The warning text can include arbitrary information to be presented
- to a human user, or logged. A system receiving this warning MUST
- NOT take any automated action.
-
-4. History Lists
-
- User agents often have history mechanisms, such as "Back" buttons and
- history lists, that can be used to redisplay a representation
- retrieved earlier in a session.
-
- The freshness model (Section 2.3) does not necessarily apply to
- history mechanisms. I.e., a history mechanism can display a previous
- representation even if it has expired.
-
- This does not prohibit the history mechanism from telling the user
- that a view might be stale, or from honoring cache directives (e.g.,
- Cache-Control: no-store).
-
-5. IANA Considerations
-
-5.1. Cache Directive Registry
-
- The registration procedure for HTTP Cache Directives is defined by
- Section 3.2.3 of this document.
-
- The HTTP Cache Directive Registry shall be created at
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 28]
-
-Internet-Draft HTTP/1.1, Part 6 August 2010
-
-
- and be
- populated with the registrations below:
-
- +------------------------+------------------------------+
- | Cache Directive | Reference |
- +------------------------+------------------------------+
- | max-age | Section 3.2.1, Section 3.2.2 |
- | max-stale | Section 3.2.1 |
- | min-fresh | Section 3.2.1 |
- | must-revalidate | Section 3.2.2 |
- | no-cache | Section 3.2.1, Section 3.2.2 |
- | no-store | Section 3.2.1, Section 3.2.2 |
- | no-transform | Section 3.2.1, Section 3.2.2 |
- | only-if-cached | Section 3.2.1 |
- | private | Section 3.2.2 |
- | proxy-revalidate | Section 3.2.2 |
- | public | Section 3.2.2 |
- | s-maxage | Section 3.2.2 |
- | stale-if-error | [RFC5861], Section 4 |
- | stale-while-revalidate | [RFC5861], Section 3 |
- +------------------------+------------------------------+
-
-5.2. Header Field Registration
-
- The Message Header Field Registry located at shall be
- updated with the permanent registrations below (see [RFC3864]):
-
- +-------------------+----------+----------+-------------+
- | Header Field Name | Protocol | Status | Reference |
- +-------------------+----------+----------+-------------+
- | Age | http | standard | Section 3.1 |
- | Cache-Control | http | standard | Section 3.2 |
- | Expires | http | standard | Section 3.3 |
- | Pragma | http | standard | Section 3.4 |
- | Vary | http | standard | Section 3.5 |
- | Warning | http | standard | Section 3.6 |
- +-------------------+----------+----------+-------------+
-
- The change controller is: "IETF (iesg@ietf.org) - Internet
- Engineering Task Force".
-
-6. Security Considerations
-
- Caches expose additional potential vulnerabilities, since the
- contents of the cache represent an attractive target for malicious
- exploitation. Because cache contents persist after an HTTP request
- is complete, an attack on the cache can reveal information long after
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 29]
-
-Internet-Draft HTTP/1.1, Part 6 August 2010
-
-
- a user believes that the information has been removed from the
- network. Therefore, cache contents need to be protected as sensitive
- information.
-
-7. Acknowledgments
-
- Much of the content and presentation of the caching design is due to
- suggestions and comments from individuals including: Shel Kaphan,
- Paul Leach, Koen Holtman, David Morris, and Larry Masinter.
-
-8. References
-
-8.1. Normative References
-
- [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
- Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
- and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
- and Message Parsing", draft-ietf-httpbis-p1-messaging-11
- (work in progress), August 2010.
-
- [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
- Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
- and J. Reschke, Ed., "HTTP/1.1, part 2: Message
- Semantics", draft-ietf-httpbis-p2-semantics-11 (work in
- progress), August 2010.
-
- [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
- Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
- and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
- Requests", draft-ietf-httpbis-p4-conditional-11 (work in
- progress), August 2010.
-
- [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
- Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
- and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
- Partial Responses", draft-ietf-httpbis-p5-range-11 (work
- in progress), August 2010.
-
- [Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
- Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
- and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication",
- draft-ietf-httpbis-p7-auth-11 (work in progress),
- August 2010.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 30]
-
-Internet-Draft HTTP/1.1, Part 6 August 2010
-
-
- Specifications: ABNF", STD 68, RFC 5234, January 2008.
-
-8.2. Informative References
-
- [RFC1305] Mills, D., "Network Time Protocol (Version 3)
- Specification, Implementation", RFC 1305, March 1992.
-
- [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
- Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
- Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
-
- [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
- Procedures for Message Header Fields", BCP 90, RFC 3864,
- September 2004.
-
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
- IANA Considerations Section in RFCs", BCP 26, RFC 5226,
- May 2008.
-
- [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale
- Content", RFC 5861, April 2010.
-
-Appendix A. Changes from RFC 2616
-
- Make the specified age calculation algorithm less conservative.
- (Section 2.3.2)
-
- Remove requirement to consider Content-Location in successful
- responses in order to determine the appropriate response to use.
- (Section 2.4)
-
- Clarify denial of service attack avoidance requirement.
- (Section 2.5)
-
- Do not mention RFC 2047 encoding and multiple languages in Warning
- headers anymore, as these aspects never were implemented.
- (Section 3.6)
-
-Appendix B. Collected ABNF
-
- Age = "Age:" OWS Age-v
- Age-v = delta-seconds
-
- Cache-Control = "Cache-Control:" OWS Cache-Control-v
- Cache-Control-v = *( "," OWS ) cache-directive *( OWS "," [ OWS
- cache-directive ] )
-
- Expires = "Expires:" OWS Expires-v
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 31]
-
-Internet-Draft HTTP/1.1, Part 6 August 2010
-
-
- Expires-v = HTTP-date
-
- HTTP-date =
-
- OWS =
-
- Pragma = "Pragma:" OWS Pragma-v
- Pragma-v = *( "," OWS ) pragma-directive *( OWS "," [ OWS
- pragma-directive ] )
-
- Vary = "Vary:" OWS Vary-v
- Vary-v = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name
- ] ) )
-
- Warning = "Warning:" OWS Warning-v
- Warning-v = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value
- ] )
-
- cache-directive = cache-request-directive / cache-response-directive
- cache-extension = token [ "=" ( token / quoted-string ) ]
- cache-request-directive = "no-cache" / "no-store" / ( "max-age="
- delta-seconds ) / ( "max-stale" [ "=" delta-seconds ] ) / (
- "min-fresh=" delta-seconds ) / "no-transform" / "only-if-cached" /
- cache-extension
- cache-response-directive = "public" / ( "private" [ "=" DQUOTE *( ","
- OWS ) field-name *( OWS "," [ OWS field-name ] ) DQUOTE ] ) / (
- "no-cache" [ "=" DQUOTE *( "," OWS ) field-name *( OWS "," [ OWS
- field-name ] ) DQUOTE ] ) / "no-store" / "no-transform" /
- "must-revalidate" / "proxy-revalidate" / ( "max-age=" delta-seconds
- ) / ( "s-maxage=" delta-seconds ) / cache-extension
-
- delta-seconds = 1*DIGIT
-
- extension-pragma = token [ "=" ( token / quoted-string ) ]
-
- field-name =
-
- port =
- pragma-directive = "no-cache" / extension-pragma
- pseudonym =
-
- quoted-string =
-
- token =
-
- uri-host =
-
- warn-agent = ( uri-host [ ":" port ] ) / pseudonym
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 32]
-
-Internet-Draft HTTP/1.1, Part 6 August 2010
-
-
- warn-code = 3DIGIT
- warn-date = DQUOTE HTTP-date DQUOTE
- warn-text = quoted-string
- warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date
- ]
-
- ABNF diagnostics:
-
- ; Age defined but not used
- ; Cache-Control defined but not used
- ; Expires defined but not used
- ; Pragma defined but not used
- ; Vary defined but not used
- ; Warning defined but not used
-
-Appendix C. Change Log (to be removed by RFC Editor before publication)
-
-C.1. Since RFC2616
-
- Extracted relevant partitions from [RFC2616].
-
-C.2. Since draft-ietf-httpbis-p6-cache-00
-
- Closed issues:
-
- o : "Trailer"
- ()
-
- o : "Invalidation
- after Update or Delete"
- ()
-
- o : "Normative and
- Informative references"
-
- o : "Date reference
- typo"
-
- o : "Connection
- header text"
-
- o : "Informative
- references"
-
- o : "ISO-8859-1
- Reference"
-
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 33]
-
-Internet-Draft HTTP/1.1, Part 6 August 2010
-
-
- o : "Normative up-
- to-date references"
-
- o : "typo in
- 13.2.2"
-
- Other changes:
-
- o Use names of RFC4234 core rules DQUOTE and HTAB (work in progress
- on )
-
-C.3. Since draft-ietf-httpbis-p6-cache-01
-
- Closed issues:
-
- o : "rel_path not
- used"
-
- Other changes:
-
- o Get rid of duplicate BNF rule names ("host" -> "uri-host") (work
- in progress on )
-
- o Add explicit references to BNF syntax and rules imported from
- other parts of the specification.
-
-C.4. Since draft-ietf-httpbis-p6-cache-02
-
- Ongoing work on IANA Message Header Registration
- ():
-
- o Reference RFC 3984, and update header registrations for headers
- defined in this document.
-
-C.5. Since draft-ietf-httpbis-p6-cache-03
-
- Closed issues:
-
- o : "Vary header
- classification"
-
-C.6. Since draft-ietf-httpbis-p6-cache-04
-
- Ongoing work on ABNF conversion
- ():
-
- o Use "/" instead of "|" for alternatives.
-
-
-
-
-Fielding, et al. Expires February 5, 2011 [Page 34]
-
-Internet-Draft HTTP/1.1, Part 6 August 2010
-
-
- o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
- whitespace ("OWS") and required whitespace ("RWS").
-
- o Rewrite ABNFs to spell out whitespace rules, factor out header
- value format definitions.
-
-C.7. Since draft-ietf-httpbis-p6-cache-05
-
- This is a total rewrite of this part of the specification.
-
- Affected issues:
-
- o : "Definition of
- 1xx Warn-Codes"
-
- o : "Placement of
- 13.5.1 and 13.5.2"
-
- o : "The role of
- Warning and Semantic Transparency in Caching"
-
- o : "Methods and
- Caching"
-
- In addition: Final work on ABNF conversion
- (
+
+
+ 
+
+