draft-ietf-webdav-protocol-09.txt | draft-ietf-webdav-protocol-10.txt | |||
---|---|---|---|---|
WEBDAV Working Group Y.Y. Goland, Microsoft | WEBDAV Working Group Y.Y. Goland, Microsoft | |||
INTERNET DRAFT E.J. Whitehead, Jr., UC Irvine | INTERNET DRAFT E.J. Whitehead, Jr., UC Irvine | |||
<draft-ietf-webdav-protocol-09> A. Faizi, Netscape | <draft-ietf-webdav-protocol-10> A. Faizi, Netscape | |||
S.R. Carter, Novell | S.R. Carter, Novell | |||
D. Jensen, Novell | D. Jensen, Novell | |||
Expires September, 1998 October 22, 1998 | Expires April, 1999 November 16, 1998 | |||
HTTP Extensions for Distributed Authoring -- WEBDAV | HTTP Extensions for Distributed Authoring -- WEBDAV | |||
Status of this Memo | Status of this Memo | |||
This document is an Internet-Draft. Internet-Drafts are working | This document is an Internet-Draft. Internet-Drafts are working | |||
documents of the Internet Engineering Task Force (IETF), its areas, | documents of the Internet Engineering Task Force (IETF), its areas, | |||
and its working groups. Note that other groups may also distribute | and its working groups. Note that other groups may also distribute | |||
working documents as Internet-Drafts. | working documents as Internet-Drafts. | |||
skipping to change at page 2, line 25 | skipping to change at page 2, line 25 | |||
3 TERMINOLOGY ........................................................8 | 3 TERMINOLOGY ........................................................8 | |||
4 DATA MODEL FOR RESOURCE PROPERTIES .................................9 | 4 DATA MODEL FOR RESOURCE PROPERTIES .................................9 | |||
4.1 The Resource Property Model .....................................9 | 4.1 The Resource Property Model .....................................9 | |||
4.2 Existing Metadata Proposals ....................................10 | 4.2 Existing Metadata Proposals ....................................10 | |||
4.3 Properties and HTTP Headers ....................................10 | 4.3 Properties and HTTP Headers ....................................10 | |||
4.4 Property Values ................................................10 | 4.4 Property Values ................................................10 | |||
4.5 Property Names .................................................11 | 4.5 Property Names .................................................11 | |||
4.6 Media Independent Links ........................................11 | 4.6 Media Independent Links ........................................11 | |||
5 COLLECTIONS OF WEB RESOURCES ......................................11 | 5 COLLECTIONS OF WEB RESOURCES ......................................12 | |||
5.1 HTTP URL Namespace Model .......................................12 | 5.1 HTTP URL Namespace Model .......................................12 | |||
5.2 Collection Resources ...........................................12 | 5.2 Collection Resources ...........................................12 | |||
5.3 Creation and Retrieval of Collection Resources .................13 | 5.3 Creation and Retrieval of Collection Resources .................13 | |||
5.4 Source Resources and Output Resources ..........................14 | 5.4 Source Resources and Output Resources ..........................14 | |||
6 LOCKING ...........................................................15 | 6 LOCKING ...........................................................15 | |||
6.1 Exclusive Vs. Shared Locks .....................................15 | 6.1 Exclusive Vs. Shared Locks .....................................15 | |||
6.2 Required Support ...............................................16 | 6.2 Required Support ...............................................16 | |||
6.3 Lock Tokens ....................................................16 | 6.3 Lock Tokens ....................................................16 | |||
6.4 opaquelocktoken Lock Token URI Scheme ..........................17 | 6.4 opaquelocktoken Lock Token URI Scheme ..........................17 | |||
6.4.1 Node Field Generation Without the IEEE 802 Address ..........17 | 6.4.1 Node Field Generation Without the IEEE 802 Address ..........17 | |||
6.5 Lock Capability Discovery ......................................19 | 6.5 Lock Capability Discovery ......................................19 | |||
6.6 Active Lock Discovery ..........................................19 | 6.6 Active Lock Discovery ..........................................19 | |||
6.7 Usage Considerations ...........................................19 | 6.7 Usage Considerations ...........................................19 | |||
7 WRITE LOCK ........................................................20 | 7 WRITE LOCK ........................................................20 | |||
7.1 Methods Restricted by Write Locks ..............................20 | 7.1 Methods Restricted by Write Locks ..............................20 | |||
7.2 Write Locks and Lock Tokens ....................................20 | 7.2 Write Locks and Lock Tokens ....................................21 | |||
7.3 Write Locks and Properties .....................................20 | 7.3 Write Locks and Properties .....................................21 | |||
7.4 Write Locks and Null Resources .................................21 | 7.4 Write Locks and Null Resources .................................21 | |||
7.5 Write Locks and Collections ....................................21 | 7.5 Write Locks and Collections ....................................21 | |||
7.6 Write Locks and the If Request Header ..........................22 | 7.6 Write Locks and the If Request Header ..........................22 | |||
7.6.1 Example - Write Lock ........................................22 | 7.6.1 Example - Write Lock ........................................22 | |||
7.7 Write Locks and COPY/MOVE ......................................22 | 7.7 Write Locks and COPY/MOVE ......................................23 | |||
7.8 Refreshing Write Locks .........................................23 | 7.8 Refreshing Write Locks .........................................23 | |||
8 HTTP METHODS FOR DISTRIBUTED AUTHORING ............................23 | 8 HTTP METHODS FOR DISTRIBUTED AUTHORING ............................24 | |||
8.1 PROPFIND .......................................................24 | 8.1 PROPFIND .......................................................24 | |||
8.1.1 Example - Retrieving Named Properties .......................25 | 8.1.1 Example - Retrieving Named Properties .......................25 | |||
8.1.2 Example - Using allprop to Retrieve All Properties ..........26 | 8.1.2 Example - Using allprop to Retrieve All Properties ..........26 | |||
8.1.3 Example - Using propname to Retrieve all Property Names .....29 | 8.1.3 Example - Using propname to Retrieve all Property Names .....29 | |||
8.2 PROPPATCH ......................................................30 | 8.2 PROPPATCH ......................................................30 | |||
8.2.1 Status Codes for use with 207 (Multi-Status) ................31 | 8.2.1 Status Codes for use with 207 (Multi-Status) ................31 | |||
8.2.2 Example - PROPPATCH .........................................31 | 8.2.2 Example - PROPPATCH .........................................31 | |||
skipping to change at page 3, line 35 | skipping to change at page 3, line 35 | |||
8.6 DELETE .........................................................34 | 8.6 DELETE .........................................................34 | |||
8.6.1 DELETE for Non-Collection Resources .........................34 | 8.6.1 DELETE for Non-Collection Resources .........................34 | |||
8.6.2 DELETE for Collections ......................................34 | 8.6.2 DELETE for Collections ......................................34 | |||
8.7 PUT ............................................................35 | 8.7 PUT ............................................................35 | |||
8.7.1 PUT for Non-Collection Resources ............................35 | 8.7.1 PUT for Non-Collection Resources ............................35 | |||
8.7.2 PUT for Collections .........................................36 | 8.7.2 PUT for Collections .........................................36 | |||
8.8 COPY Method ....................................................36 | 8.8 COPY Method ....................................................36 | |||
8.8.1 COPY for HTTP/1.1 resources .................................36 | 8.8.1 COPY for HTTP/1.1 resources .................................36 | |||
8.8.2 COPY for Properties .........................................36 | 8.8.2 COPY for Properties .........................................37 | |||
8.8.3 COPY for Collections ........................................37 | 8.8.3 COPY for Collections ........................................37 | |||
8.8.4 COPY and the Overwrite Header ...............................38 | 8.8.4 COPY and the Overwrite Header ...............................38 | |||
8.8.5 Status Codes ................................................38 | 8.8.5 Status Codes ................................................38 | |||
8.8.6 Example - COPY with Overwrite ...............................39 | 8.8.6 Example - COPY with Overwrite ...............................39 | |||
8.8.7 Example - COPY with No Overwrite ............................39 | 8.8.7 Example - COPY with No Overwrite ............................39 | |||
8.8.8 Example - COPY of a Collection ..............................39 | 8.8.8 Example - COPY of a Collection ..............................40 | |||
8.9 MOVE Method ....................................................40 | 8.9 MOVE Method ....................................................40 | |||
8.9.1 MOVE for Properties .........................................40 | 8.9.1 MOVE for Properties .........................................41 | |||
8.9.2 MOVE for Collections ........................................41 | 8.9.2 MOVE for Collections ........................................41 | |||
8.9.3 MOVE and the Overwrite Header ...............................42 | 8.9.3 MOVE and the Overwrite Header ...............................42 | |||
8.9.4 Status Codes ................................................42 | 8.9.4 Status Codes ................................................42 | |||
8.9.5 Example - MOVE of a Non-Collection ..........................42 | 8.9.5 Example - MOVE of a Non-Collection ..........................42 | |||
8.9.6 Example - MOVE of a Collection ..............................43 | 8.9.6 Example - MOVE of a Collection ..............................43 | |||
8.10 LOCK Method ....................................................43 | 8.10 LOCK Method ....................................................44 | |||
8.10.1 Operation ...................................................44 | 8.10.1 Operation ...................................................44 | |||
8.10.2 The Effect of Locks on Properties and Collections ...........44 | 8.10.2 The Effect of Locks on Properties and Collections ...........44 | |||
8.10.3 Locking Replicated Resources ................................44 | 8.10.3 Locking Replicated Resources ................................45 | |||
8.10.4 Depth and Locking ...........................................44 | 8.10.4 Depth and Locking ...........................................45 | |||
8.10.5 Interaction with other Methods ..............................45 | 8.10.5 Interaction with other Methods ..............................45 | |||
8.10.6 Lock Compatibility Table ....................................45 | 8.10.6 Lock Compatibility Table ....................................46 | |||
8.10.7 Status Codes ................................................46 | 8.10.7 Status Codes ................................................46 | |||
8.10.8 Example - Simple Lock Request ...............................46 | 8.10.8 Example - Simple Lock Request ...............................47 | |||
8.10.9 Example - Refreshing a Write Lock ...........................48 | 8.10.9 Example - Refreshing a Write Lock ...........................48 | |||
8.10.10 Example - Multi-Resource Lock Request ......................49 | 8.10.10 Example - Multi-Resource Lock Request ......................49 | |||
8.11 UNLOCK Method ..................................................50 | 8.11 UNLOCK Method ..................................................50 | |||
8.11.1 Example - UNLOCK ............................................50 | 8.11.1 Example - UNLOCK ............................................50 | |||
9 HTTP HEADERS FOR DISTRIBUTED AUTHORING ............................51 | 9 HTTP HEADERS FOR DISTRIBUTED AUTHORING ............................51 | |||
9.1 DAV Header .....................................................51 | 9.1 DAV Header .....................................................51 | |||
9.2 Depth Header ...................................................51 | 9.2 Depth Header ...................................................51 | |||
9.3 Destination Header .............................................52 | 9.3 Destination Header .............................................52 | |||
9.4 If Header ......................................................52 | 9.4 If Header ......................................................52 | |||
9.4.1 No-tag-list Production ......................................53 | 9.4.1 No-tag-list Production ......................................53 | |||
9.4.2 Tagged-list Production ......................................53 | 9.4.2 Tagged-list Production ......................................53 | |||
9.4.3 not Production ..............................................54 | 9.4.3 not Production ..............................................54 | |||
9.4.4 Matching Function ...........................................54 | 9.4.4 Matching Function ...........................................54 | |||
9.4.5 If Header and Non-DAV Compliant Proxies .....................55 | 9.4.5 If Header and Non-DAV Compliant Proxies .....................55 | |||
9.5 Lock-Token Header ..............................................55 | 9.5 Lock-Token Header ..............................................55 | |||
9.6 Overwrite Header ...............................................55 | 9.6 Overwrite Header ...............................................55 | |||
9.7 Status-URI Response Header .....................................55 | 9.7 Status-URI Response Header .....................................56 | |||
9.8 Timeout Request Header .........................................56 | 9.8 Timeout Request Header .........................................56 | |||
10 STATUS CODE EXTENSIONS TO HTTP/1.1 ..............................57 | 10 STATUS CODE EXTENSIONS TO HTTP/1.1 ..............................57 | |||
10.1 102 Processing .................................................57 | 10.1 102 Processing .................................................57 | |||
10.2 207 Multi-Status ...............................................57 | 10.2 207 Multi-Status ...............................................57 | |||
10.3 422 Unprocessable Entity .......................................57 | 10.3 422 Unprocessable Entity .......................................58 | |||
10.4 423 Locked .....................................................58 | 10.4 423 Locked .....................................................58 | |||
10.5 424 Failed Dependency ..........................................58 | 10.5 424 Failed Dependency ..........................................58 | |||
10.6 507 Insufficient Storage .......................................58 | 10.6 507 Insufficient Storage .......................................58 | |||
11 MULTI-STATUS RESPONSE ...........................................58 | 11 MULTI-STATUS RESPONSE ...........................................58 | |||
12 XML ELEMENT DEFINITIONS .........................................58 | 12 XML ELEMENT DEFINITIONS .........................................58 | |||
12.1 activelock XML Element .........................................58 | 12.1 activelock XML Element .........................................59 | |||
12.1.1 depth XML Element ...........................................59 | 12.1.1 depth XML Element ...........................................59 | |||
12.1.2 locktoken XML Element .......................................59 | 12.1.2 locktoken XML Element .......................................59 | |||
12.1.3 timeout XML Element .........................................59 | 12.1.3 timeout XML Element .........................................59 | |||
12.2 collection XML Element .........................................59 | 12.2 collection XML Element .........................................59 | |||
12.3 href XML Element ...............................................59 | 12.3 href XML Element ...............................................60 | |||
12.4 link XML Element ...............................................60 | 12.4 link XML Element ...............................................60 | |||
12.4.1 dst XML Element .............................................60 | 12.4.1 dst XML Element .............................................60 | |||
12.4.2 src XML Element .............................................60 | 12.4.2 src XML Element .............................................60 | |||
12.5 lockentry XML Element ..........................................60 | 12.5 lockentry XML Element ..........................................60 | |||
12.6 lockinfo XML Element ...........................................60 | 12.6 lockinfo XML Element ...........................................61 | |||
12.7 lockscope XML Element ..........................................61 | 12.7 lockscope XML Element ..........................................61 | |||
12.7.1 exclusive XML Element .......................................61 | 12.7.1 exclusive XML Element .......................................61 | |||
12.7.2 shared XML Element ..........................................61 | 12.7.2 shared XML Element ..........................................61 | |||
12.8 locktype XML Element ...........................................61 | 12.8 locktype XML Element ...........................................61 | |||
12.8.1 write XML Element ...........................................61 | 12.8.1 write XML Element ...........................................61 | |||
12.9 multistatus XML Element ........................................62 | 12.9 multistatus XML Element ........................................62 | |||
12.9.1 response XML Element ........................................62 | 12.9.1 response XML Element ........................................62 | |||
12.9.2 responsedescription XML Element .............................63 | 12.9.2 responsedescription XML Element .............................63 | |||
12.10owner XML Element ..............................................63 | 12.10 owner XML Element .............................................63 | |||
12.11prop XML element ...............................................63 | 12.11 prop XML element ..............................................63 | |||
12.12propertybehavior XML element ...................................63 | 12.12 propertybehavior XML element ..................................63 | |||
12.12.1 keepalive XML element ......................................64 | 12.12.1 keepalive XML element ......................................64 | |||
12.12.2 omit XML element ...........................................64 | 12.12.2 omit XML element ...........................................64 | |||
12.13propertyupdate XML element .....................................64 | 12.13 propertyupdate XML element ....................................64 | |||
12.13.1 remove XML element .........................................65 | 12.13.1 remove XML element .........................................65 | |||
12.13.2 set XML element ............................................65 | 12.13.2 set XML element ............................................65 | |||
12.14propfind XML Element ...........................................65 | 12.14 propfind XML Element ..........................................65 | |||
12.14.1 allprop XML Element ........................................65 | 12.14.1 allprop XML Element ........................................65 | |||
12.14.2 propname XML Element .......................................66 | 12.14.2 propname XML Element .......................................66 | |||
13 DAV PROPERTIES ..................................................66 | 13 DAV PROPERTIES ..................................................66 | |||
13.1 creationdate Property ..........................................66 | 13.1 creationdate Property ..........................................66 | |||
13.2 displayname Property ...........................................66 | 13.2 displayname Property ...........................................66 | |||
13.3 getcontentlanguage Property ....................................67 | 13.3 getcontentlanguage Property ....................................67 | |||
13.4 getcontentlength Property ......................................67 | 13.4 getcontentlength Property ......................................67 | |||
13.5 getcontenttype Property ........................................67 | 13.5 getcontenttype Property ........................................67 | |||
13.6 getetag Property ...............................................67 | 13.6 getetag Property ...............................................67 | |||
13.7 getlastmodified Property .......................................68 | 13.7 getlastmodified Property .......................................68 | |||
13.8 lockdiscovery Property .........................................68 | 13.8 lockdiscovery Property .........................................68 | |||
13.8.1 Example - Retrieving the lockdiscovery Property .............68 | 13.8.1 Example - Retrieving the lockdiscovery Property .............68 | |||
13.9 resourcetype Property ..........................................69 | 13.9 resourcetype Property ..........................................69 | |||
13.10source Property ................................................70 | 13.10 source Property ...............................................70 | |||
13.10.1 Example - A source Property ................................70 | 13.10.1 Example - A source Property ................................70 | |||
13.11supportedlock Property .........................................71 | 13.11 supportedlock Property ........................................71 | |||
13.11.1 Example - Retrieving the supportedlock Property ............71 | 13.11.1 Example - Retrieving the supportedlock Property ............71 | |||
14 INSTRUCTIONS FOR PROCESSING XML IN DAV ..........................72 | 14 INSTRUCTIONS FOR PROCESSING XML IN DAV ..........................72 | |||
15 DAV COMPLIANCE CLASSES ..........................................73 | 15 DAV COMPLIANCE CLASSES ..........................................73 | |||
15.1 Class 1 ........................................................73 | 15.1 Class 1 ........................................................73 | |||
15.2 Class 2 ........................................................73 | 15.2 Class 2 ........................................................73 | |||
16 INTERNATIONALIZATION CONSIDERATIONS .............................73 | 16 INTERNATIONALIZATION CONSIDERATIONS .............................73 | |||
skipping to change at page 8, line 48 | skipping to change at page 8, line 48 | |||
[RFC2068]. Since this augmented BNF uses the basic production rules | [RFC2068]. Since this augmented BNF uses the basic production rules | |||
provided in section 2.2 of [RFC2068], these rules apply to this | provided in section 2.2 of [RFC2068], these rules apply to this | |||
document as well. | document as well. | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in RFC 2119 [RFC2119]. | document are to be interpreted as described in RFC 2119 [RFC2119]. | |||
3 Terminology | 3 Terminology | |||
URI/URL - As defined in [RFC2396]. | URI/URL - A Uniform Resource Identifier and Uniform Resource | |||
Locator, respectively. These terms (and the distinction between | ||||
them) are defined in [RFC2396]. | ||||
Collection - A resource that contains member resources and meets the | Collection - A resource that contains a set of URIs, termed member | |||
requirements in section 5 of this specification. | URIs, which identify member resources and meets the requirements in | |||
section 5 of this specification. | ||||
Member Resource - A resource contained by a collection. | Member URI - A URI which is a member of the set of URIs contained by | |||
a collection. | ||||
Internal Member Resource - A member resource of a collection whose | Internal Member URI - A Member URI that is immediately relative to | |||
URI is immediately relative to the URI of the collection. | the URI of the collection (the definition of immediately relative is | |||
given in section 5.2). | ||||
Property - A name/value pair that contains descriptive information | Property - A name/value pair that contains descriptive information | |||
about a resource. | about a resource. | |||
Live Property - A property whose semantics and syntax are enforced | Live Property - A property whose semantics and syntax are enforced | |||
by the server. For example, the live "getcontentlength" property | by the server. For example, the live "getcontentlength" property | |||
has its value, the length of the entity returned by a GET request, | has its value, the length of the entity returned by a GET request, | |||
automatically calculated by the server. | automatically calculated by the server. | |||
Dead Property - A property whose semantics and syntax are not | Dead Property - A property whose semantics and syntax are not | |||
skipping to change at page 10, line 12 | skipping to change at page 10, line 16 | |||
property has its syntax and semantics enforced by the client; the | property has its syntax and semantics enforced by the client; the | |||
server merely records the value of the property verbatim. | server merely records the value of the property verbatim. | |||
4.2 Existing Metadata Proposals | 4.2 Existing Metadata Proposals | |||
Properties have long played an essential role in the maintenance of | Properties have long played an essential role in the maintenance of | |||
large document repositories, and many current proposals contain some | large document repositories, and many current proposals contain some | |||
notion of a property, or discuss web metadata more generally. These | notion of a property, or discuss web metadata more generally. These | |||
include PICS [REC-PICS], PICS-NG, XML, Web Collections, and several | include PICS [REC-PICS], PICS-NG, XML, Web Collections, and several | |||
proposals on representing relationships within HTML. Work on PICS-NG | proposals on representing relationships within HTML. Work on PICS-NG | |||
and Web Collections has been subsumed by the Resource Definition | and Web Collections has been subsumed by the Resource Description | |||
Framework (RDF) metadata activity of the World Wide Web Consortium. | Framework (RDF) metadata activity of the World Wide Web Consortium. | |||
RDF consists of a network-based data model and an XML representation | RDF consists of a network-based data model and an XML representation | |||
of that model. | of that model. | |||
Some proposals come from a digital library perspective. These | Some proposals come from a digital library perspective. These | |||
include the Dublin Core [RFC2413] metadata set and the Warwick | include the Dublin Core [RFC2413] metadata set and the Warwick | |||
Framework [Lagoze, 1996], a container architecture for different | Framework [WF], a container architecture for different metadata | |||
metadata schemas. The literature includes many examples of | schemas. The literature includes many examples of metadata, | |||
metadata, including MARC [USMARC], a bibliographic metadata format, | including MARC [USMARC], a bibliographic metadata format, and a | |||
and a technical report bibliographic format employed by the Dienst | technical report bibliographic format employed by the Dienst system | |||
system [RFC1807]. Additionally, the proceedings from the first IEEE | [RFC1807]. Additionally, the proceedings from the first IEEE | |||
Metadata conference describe many community-specific metadata sets. | Metadata conference describe many community-specific metadata sets. | |||
Participants of the 1996 Metadata II Workshop in Warwick, UK | Participants of the 1996 Metadata II Workshop in Warwick, UK [WF], | |||
[Lagoze, 1996], noted that "new metadata sets will develop as the | noted that "new metadata sets will develop as the networked | |||
networked infrastructure matures" and "different communities will | infrastructure matures" and "different communities will propose, | |||
propose, design, and be responsible for different types of | design, and be responsible for different types of metadata." These | |||
metadata." These observations can be corroborated by noting that | observations can be corroborated by noting that many community- | |||
many community-specific sets of metadata already exist, and there is | specific sets of metadata already exist, and there is significant | |||
significant motivation for the development of new forms of metadata | motivation for the development of new forms of metadata as many | |||
as many communities increasingly make their data available in | communities increasingly make their data available in digital form, | |||
digital form, requiring a metadata format to assist data location | requiring a metadata format to assist data location and cataloging. | |||
and cataloging. | ||||
4.3 Properties and HTTP Headers | 4.3 Properties and HTTP Headers | |||
Properties already exist, in a limited sense, in HTTP message | Properties already exist, in a limited sense, in HTTP message | |||
headers. However, in distributed authoring environments a | headers. However, in distributed authoring environments a | |||
relatively large number of properties are needed to describe the | relatively large number of properties are needed to describe the | |||
state of a resource, and setting/returning them all through HTTP | state of a resource, and setting/returning them all through HTTP | |||
headers is inefficient. Thus a mechanism is needed which allows a | headers is inefficient. Thus a mechanism is needed which allows a | |||
principal to identify a set of properties in which the principal is | principal to identify a set of properties in which the principal is | |||
interested and to set or retrieve just those properties. | interested and to set or retrieve just those properties. | |||
skipping to change at page 11, line 43 | skipping to change at page 11, line 46 | |||
relating to hierarchical properties. | relating to hierarchical properties. | |||
Finally, it is not possible to define the same property twice on a | Finally, it is not possible to define the same property twice on a | |||
single resource, as this would cause a collision in the resource's | single resource, as this would cause a collision in the resource's | |||
property namespace. | property namespace. | |||
4.6 Media Independent Links | 4.6 Media Independent Links | |||
Although HTML resources support links to other resources, the Web | Although HTML resources support links to other resources, the Web | |||
needs more general support for links between resources of any media | needs more general support for links between resources of any media | |||
type. WebDAV provides such links. A WebDAV link is a special type | type (media types are also known as MIME types, or content types). | |||
of property value, formally defined in section 12.4, that allows | WebDAV provides such links. A WebDAV link is a special type of | |||
typed connections to be established between resources of any media | property value, formally defined in section 12.4, that allows typed | |||
type. The property value consists of source and destination Uniform | connections to be established between resources of any media type. | |||
Resource Locators (URLs); the property name identifies the link | The property value consists of source and destination Uniform | |||
Resource Identifiers (URIs); the property name identifies the link | ||||
type. | type. | |||
5 Collections of Web Resources | 5 Collections of Web Resources | |||
This section provides a description of a new type of Web resource, | This section provides a description of a new type of Web resource, | |||
the collection, and discusses its interactions with the HTTP URL | the collection, and discusses its interactions with the HTTP URL | |||
namespace. The purpose of a collection resource is to model | namespace. The purpose of a collection resource is to model | |||
collection-like objects (e.g., file system directories) within a | collection-like objects (e.g., file system directories) within a | |||
server's namespace. | server's namespace. | |||
All DAV compliant resources MUST support the HTTP URL namespace | All DAV compliant resources MUST support the HTTP URL namespace | |||
model specified herein. | model specified herein. | |||
5.1 HTTP URL Namespace Model | 5.1 HTTP URL Namespace Model | |||
The HTTP URL namespace is a hierarchical namespace where the | The HTTP URL namespace is a hierarchical namespace where the | |||
hierarchy is delimited with the "/" character. | hierarchy is delimited with the "/" character. | |||
An HTTP URL namespace is said to be consistent if it meets the | An HTTP URL namespace is said to be consistent if it meets the | |||
following rule: for every non-null resource A, there exists a non- | following conditions: for every URL in the HTTP hierarchy there | |||
null resource B that is a collection and has resource A as an | exists a collection that contains that URL as an internal member. | |||
internal member. The root of the namespace is exempt from the | The root, or top-level collection of the namespace under | |||
previous rule. | consideration is exempt from the previous rule. | |||
Neither HTTP/1.1 nor WebDAV require that the entire HTTP URL | Neither HTTP/1.1 nor WebDAV require that the entire HTTP URL | |||
namespace be consistent. However, certain WebDAV methods are | namespace be consistent. However, certain WebDAV methods are | |||
prohibited from producing results that cause namespace | prohibited from producing results that cause namespace | |||
inconsistencies. | inconsistencies. | |||
Although implicit in [RFC2068] and [RFC2396], any resource, | ||||
including collection resources, MAY be identified by more than one | ||||
URI. For example, a resource could be identified by multiple HTTP | ||||
URLs. | ||||
5.2 Collection Resources | 5.2 Collection Resources | |||
A collection is a resource whose state consists of at least a list | A collection is a resource whose state consists of at least a list | |||
of internal members and a set of properties, but which may have | of internal member URIs and a set of properties, but which may have | |||
additional state such as entity bodies returned by GET. An internal | additional state such as entity bodies returned by GET. An internal | |||
member resource MUST have a URI that is immediately relative to the | member URI MUST be immediately relative to a base URI of the | |||
base URI of the collection. That is, the internal member's URI is | collection. That is, the internal member URI is equal to a | |||
equal to the parent collection's URI plus an additional segment | containing collection's URI plus an additional segment for non- | |||
where segment is defined in section 3.2.1 of RFC 2068 [Fielding et | collection resources, or additional segment plus trailing slash "/" | |||
al., 1996]. | for collection resources, where segment is defined in section 3.3 of | |||
[RFC2396]. | ||||
Any given internal member MUST only belong to the collection once, | Any given internal member URI MUST only belong to the collection | |||
i.e., it is illegal to have multiple instances of the same URI in a | once, i.e., it is illegal to have multiple instances of the same URI | |||
collection. Properties defined on collections behave exactly as do | in a collection. Properties defined on collections behave exactly | |||
properties on non-collection resources. | as do properties on non-collection resources. | |||
For all WebDAV compliant resources A and B for which B is the parent | For all WebDAV compliant resources A and B, identified by URIs U and | |||
of A in the HTTP URL namespace hierarchy, B MUST be a collection | V, for which U is immediately relative to V, B MUST be a collection | |||
which has A as an internal member. So, if http://foo.com/bar/blah is | that has U as an internal member URI. So, if the resource with URL | |||
WebDAV compliant and if http://foo.com/bar/ is WebDAV compliant then | http://foo.com/bar/blah is WebDAV compliant and if the resource with | |||
http://foo.com/bar/ must be a collection and must contain | URL http://foo.com/bar/ is WebDAV compliant then the resource with | |||
URL http://foo.com/bar/ must be a collection and must contain URL | ||||
http://foo.com/bar/blah as an internal member. | http://foo.com/bar/blah as an internal member. | |||
Collection resources MAY list their non-WebDAV compliant children in | Collection resources MAY list the URLs ofnon-WebDAV compliant | |||
the HTTP URL namespace hierarchy as internal members but are not | children in the HTTP URL namespace hierarchy as internal members but | |||
required to do so. For example, if http://foo.com/bar/blah is not | are not required to do so. For example, if the resource with URL | |||
WebDAV compliant and http://foo.com/bar/ is a collection then | http://foo.com/bar/blah is not WebDAV compliant and the URL | |||
http://foo.com/bar/blah may or may not be listed as an internal | http://foo.com/bar/ identifies a collection then URL | |||
member of http://foo.com/bar/. | http://foo.com/bar/blah may or may not be an internal member of the | |||
collection with URL http://foo.com/bar/. | ||||
If a WebDAV compliant resource has no WebDAV compliant children in | If a WebDAV compliant resource has no WebDAV compliant children in | |||
the HTTP URL namespace hierarchy then the WebDAV compliant resource | the HTTP URL namespace hierarchy then the WebDAV compliant resource | |||
is not required to be a collection. | is not required to be a collection. | |||
There is a standing convention that when a collection is referred to | There is a standing convention that when a collection is referred to | |||
by its name without a trailing slash, the trailing slash is | by its name without a trailing slash, the trailing slash is | |||
automatically appended. Due to this, a resource may accept a URI | automatically appended. Due to this, a resource may accept a URI | |||
without a trailing "/" to point to a collection. In this case it | without a trailing "/" to point to a collection. In this case it | |||
SHOULD return a content-location header in the response pointing to | SHOULD return a content-location header in the response pointing to | |||
the URL ending with the "/". For example, if a client invokes a | the URI ending with the "/". For example, if a client invokes a | |||
method on http://foo.bar/blah (no trailing slash), the resource | method on http://foo.bar/blah (no trailing slash), the resource | |||
http://foo.bar/blah/ (trailing slash) may respond as if the | http://foo.bar/blah/ (trailing slash) may respond as if the | |||
operation were invoked on it, and should return a content-location | operation were invoked on it, and should return a content-location | |||
header with http://foo.bar/blah/ in it. In general clients SHOULD | header with http://foo.bar/blah/ in it. In general clients SHOULD | |||
use the "/" form of collection names. | use the "/" form of collection names. | |||
A resource MAY be a collection but not be WebDAV compliant. That | A resource MAY be a collection but not be WebDAV compliant. That | |||
is, the resource may comply with all the rules set out in this | is, the resource may comply with all the rules set out in this | |||
specification regarding how a collection is to behave without | specification regarding how a collection is to behave without | |||
necessarily supporting all methods that a WebDAV compliant resource | necessarily supporting all methods that a WebDAV compliant resource | |||
is required to support. In such a case the resource may return the | is required to support. In such a case the resource may return the | |||
dav:resourcetype property with the value dav:collection but MUST NOT | DAV:resourcetype property with the value DAV:collection but MUST NOT | |||
return a DAV header containing the value "1" on an OPTIONS response. | return a DAV header containing the value "1" on an OPTIONS response. | |||
5.3 Creation and Retrieval of Collection Resources | 5.3 Creation and Retrieval of Collection Resources | |||
This document specifies the MKCOL method to create new collection | This document specifies the MKCOL method to create new collection | |||
resources, rather than using the existing HTTP/1.1 PUT or POST | resources, rather than using the existing HTTP/1.1 PUT or POST | |||
method, for the following reasons: | method, for the following reasons: | |||
In HTTP/1.1, the PUT method is defined to store the request body at | In HTTP/1.1, the PUT method is defined to store the request body at | |||
the location specified by the Request-URI. While a description | the location specified by the Request-URI. While a description | |||
skipping to change at page 14, line 9 | skipping to change at page 14, line 19 | |||
because it would be difficult to separate access control for | because it would be difficult to separate access control for | |||
collection creation from other uses of POST. | collection creation from other uses of POST. | |||
The exact definition of the behavior of GET and PUT on collections | The exact definition of the behavior of GET and PUT on collections | |||
is defined later in this document. | is defined later in this document. | |||
5.4 Source Resources and Output Resources | 5.4 Source Resources and Output Resources | |||
For many resources, the entity returned by a GET method exactly | For many resources, the entity returned by a GET method exactly | |||
matches the persistent state of the resource, for example, a GIF | matches the persistent state of the resource, for example, a GIF | |||
file stored on a disk. For this simple case, the URL at which a | file stored on a disk. For this simple case, the URI at which a | |||
resource is accessed is identical to the URL at which the source | resource is accessed is identical to the URI at which the source | |||
(the persistent state) of the resource is accessed. This is also | (the persistent state) of the resource is accessed. This is also | |||
the case for HTML source files that are not processed by the server | the case for HTML source files that are not processed by the server | |||
prior to transmission. | prior to transmission. | |||
However, the server can sometimes process HTML resources before they | However, the server can sometimes process HTML resources before they | |||
are transmitted as a return entity body. For example, a server- | are transmitted as a return entity body. For example, a server- | |||
side-include directive within an HTML file might instruct a server | side-include directive within an HTML file might instruct a server | |||
to replace the directive with another value, such as the current | to replace the directive with another value, such as the current | |||
date. In this case, what is returned by GET (HTML plus date) | date. In this case, what is returned by GET (HTML plus date) | |||
differs from the persistent state of the resource (HTML plus | differs from the persistent state of the resource (HTML plus | |||
directive). Typically there is no way to access the HTML resource | directive). Typically there is no way to access the HTML resource | |||
containing the unprocessed directive. | containing the unprocessed directive. | |||
Sometimes the entity returned by GET is the output of a data- | Sometimes the entity returned by GET is the output of a data- | |||
producing process that is described by one or more source resources | producing process that is described by one or more source resources | |||
(that may not even have a location in the URL namespace). A single | (that may not even have a location in the URI namespace). A single | |||
data-producing process may dynamically generate the state of a | data-producing process may dynamically generate the state of a | |||
potentially large number of output resources. An example of this is | potentially large number of output resources. An example of this is | |||
a CGI script that describes a "finger" gateway process that maps | a CGI script that describes a "finger" gateway process that maps | |||
part of the namespace of a server into finger requests, such as | part of the namespace of a server into finger requests, such as | |||
http://www.foo.bar.org/finger_gateway/user@host. | http://www.foo.bar.org/finger_gateway/user@host. | |||
In the absence of distributed authoring capabilities, it is | In the absence of distributed authoring capabilities, it is | |||
acceptable to have no mapping of source resource(s) to the URI | acceptable to have no mapping of source resource(s) to the URI | |||
namespace. In fact, preventing access to the source resource(s) has | namespace. In fact, preventing access to the source resource(s) has | |||
desirable security benefits. However, if remote editing of the | desirable security benefits. However, if remote editing of the | |||
skipping to change at page 17, line 20 | skipping to change at page 17, line 31 | |||
The opaquelocktoken URI scheme is designed to be unique across all | The opaquelocktoken URI scheme is designed to be unique across all | |||
resources for all time. Due to this uniqueness quality, a client | resources for all time. Due to this uniqueness quality, a client | |||
may submit an opaque lock token in an If header on a resource other | may submit an opaque lock token in an If header on a resource other | |||
than the one that returned it. | than the one that returned it. | |||
All resources MUST recognize the opaquelocktoken scheme and, at | All resources MUST recognize the opaquelocktoken scheme and, at | |||
minimum, recognize that the lock token does not refer to an | minimum, recognize that the lock token does not refer to an | |||
outstanding lock on the resource. | outstanding lock on the resource. | |||
In order to guarantee uniqueness across all resources for all time | In order to guarantee uniqueness across all resources for all time | |||
the opaquelocktoken requires the use of the globally unique | the opaquelocktoken requires the use of the Universal Unique | |||
identifier (GUID) mechanism, as described in [ISO-11578]. | Identifier (UUID) mechanism, as described in [ISO-11578]. | |||
Opaquelocktoken generators, however, have a choice of how they | Opaquelocktoken generators, however, have a choice of how they | |||
create these tokens. They can either generate a new GUID for every | create these tokens. They can either generate a new UUID for every | |||
lock token they create or they can create a single GUID and then | lock token they create or they can create a single UUID and then | |||
add extension characters. If the second method is selected then the | add extension characters. If the second method is selected then the | |||
program generating the extensions MUST guarantee that the same | program generating the extensions MUST guarantee that the same | |||
extension will never be used twice with the associated GUID. | extension will never be used twice with the associated UUID. | |||
OpaqueLockToken-URI = "opaquelocktoken:" GUID [Extension] ; The | OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension] ; The | |||
GUID production is the string representation of a GUID, as defined | UUID production is the string representation of a UUID, as defined | |||
in [ISO-11578]. Note that white space (LWS) is not allowed between | in [ISO-11578]. Note that white space (LWS) is not allowed between | |||
elements of this production. | elements of this production. | |||
Extension = path ; path is defined in section 3.2.1 of RFC 2068 | Extension = path ; path is defined in section 3.2.1 of RFC 2068 | |||
[Fielding et al., 1996] | [RFC2068] | |||
6.4.1 Node Field Generation Without the IEEE 802 Address | 6.4.1 Node Field Generation Without the IEEE 802 Address | |||
GUIDs, as defined in [ISO-11578], contain a "node" field which | UUIDs, as defined in [ISO-11578], contain a "node" field that | |||
contains one of the IEEE 802 addresses for the server machine. As | contains one of the IEEE 802 addresses for the server machine. As | |||
noted in section 17.8, there are several security risks associated | noted in section 17.8, there are several security risks associated | |||
with exposing a machine's IEEE 802 address. This section provides an | with exposing a machine's IEEE 802 address. This section provides an | |||
alternate mechanism for generating the "node" field of a GUID which | alternate mechanism for generating the "node" field of a UUID which | |||
does not employ an IEEE 802 address. WebDAV servers MAY use this | does not employ an IEEE 802 address. WebDAV servers MAY use this | |||
algorithm for creating the node field when generating GUIDs. The | algorithm for creating the node field when generating UUIDs. The | |||
text in this section is quoted from section 4 of draft-leach-uuids- | text in this section isoriginally from an Internet-Draft by Paul | |||
guids-01 (expired). | Leach and Rich Salz, who are noted here to properly attribute their | |||
work. | ||||
The ideal solution is to obtain a 47 bit cryptographic quality | The ideal solution is to obtain a 47 bit cryptographic quality | |||
random number, and use it as the low 47 bits of the node ID, with | random number, and use it as the low 47 bits of the node ID, with | |||
the most significant bit of the first octet of the node ID set to 1. | the most significant bit of the first octet of the node ID set to 1. | |||
This bit is the unicast/multicast bit, which will never be set in | This bit is the unicast/multicast bit, which will never be set in | |||
IEEE 802 addresses obtained from network cards; hence, there can | IEEE 802 addresses obtained from network cards; hence, there can | |||
never be a conflict between GUIDs generated by machines with and | never be a conflict between UUIDs generated by machines with and | |||
without network cards. | without network cards. | |||
If a system does not have a primitive to generate cryptographic | If a system does not have a primitive to generate cryptographic | |||
quality random numbers, then in most systems there are usually a | quality random numbers, then in most systems there are usually a | |||
fairly large number of sources of randomness available from which | fairly large number of sources of randomness available from which | |||
one can be generated. Such sources are system specific, but often | one can be generated. Such sources are system specific, but often | |||
include: | include: | |||
- the percent of memory in use | - the percent of memory in use | |||
- the size of main memory in bytes | - the size of main memory in bytes | |||
skipping to change at page 21, line 37 | skipping to change at page 21, line 50 | |||
resource the resource ceases to be in the lock-null state. | resource the resource ceases to be in the lock-null state. | |||
If the resource is unlocked, for any reason, without a PUT, MKCOL, | If the resource is unlocked, for any reason, without a PUT, MKCOL, | |||
or similar method having been successfully executed upon it then the | or similar method having been successfully executed upon it then the | |||
resource MUST return to the null state. | resource MUST return to the null state. | |||
7.5 Write Locks and Collections | 7.5 Write Locks and Collections | |||
A write lock on a collection, whether created by a "Depth: 0" or | A write lock on a collection, whether created by a "Depth: 0" or | |||
"Depth: infinity" lock request, prevents the addition or removal of | "Depth: infinity" lock request, prevents the addition or removal of | |||
members of the collection by non-lock owners. As a consequence, | member URIs of the collection by non-lock owners. As a consequence, | |||
when a principal issues a request to create a new internal member of | when a principal issues a PUT or POST request to create a new | |||
a write locked collection using PUT or POST, or to remove an | resource under a URI which needs to be an internal member of a write | |||
existing internal member of a write locked collection using DELETE, | locked collection to maintain HTTP namespace consistency, or issues | |||
this request MUST fail if the principal does not have a write lock | a DELETE to remove a resource which has a URI which is an existing | |||
on the collection. | internal member URI of a write locked collection, this request MUST | |||
fail if the principal does not have a write lock on the collection. | ||||
However, if a write lock request is issued to a collection | However, if a write lock request is issued to a collection | |||
containing internal member resources that are currently locked in a | containing member URIs identifying resources that are currently | |||
manner which conflicts with the write lock, the request MUST fail | locked in a manner which conflicts with the write lock, the request | |||
with a 423 (Locked) status code. | MUST fail with a 423 (Locked) status code. | |||
If a lock owner causes a resource to be added as an internal member | If a lock owner causes the URI of a resource to be added as an | |||
of a locked collection then the new resource MUST be automatically | internal member URI of a locked collection then the new resource | |||
added to the lock. This is the only mechanism that allows a | MUST be automatically added to the lock. This is the only mechanism | |||
resource to be added to a write lock. Thus, for example, if the | that allows a resource to be added to a write lock. Thus, for | |||
collection /a/b/ is write locked and the resource /c is moved to | example, if the collection /a/b/ is write locked and the resource /c | |||
/a/b/c then /a/b/c will be added to the write lock. | is moved to /a/b/c then resource /a/b/c will be added to the write | |||
lock. | ||||
7.6 Write Locks and the If Request Header | 7.6 Write Locks and the If Request Header | |||
If a user agent is not required to have knowledge about a lock when | If a user agent is not required to have knowledge about a lock when | |||
requesting an operation on a locked resource, the following scenario | requesting an operation on a locked resource, the following scenario | |||
might occur. Program A, run by User A, takes out a write lock on a | might occur. Program A, run by User A, takes out a write lock on a | |||
resource. Program B, also run by User A, has no knowledge of the | resource. Program B, also run by User A, has no knowledge of the | |||
lock taken out by Program A, yet performs a PUT to the locked | lock taken out by Program A, yet performs a PUT to the locked | |||
resource. In this scenario, the PUT succeeds because locks are | resource. In this scenario, the PUT succeeds because locks are | |||
associated with a principal, not a program, and thus program B, | associated with a principal, not a program, and thus program B, | |||
skipping to change at page 24, line 7 | skipping to change at page 24, line 19 | |||
parsers that are compliant with [REC-XML]. All XML used in either | parsers that are compliant with [REC-XML]. All XML used in either | |||
requests or responses MUST be, at minimum, well formed. If a server | requests or responses MUST be, at minimum, well formed. If a server | |||
receives ill-formed XML in a request it MUST reject the entire | receives ill-formed XML in a request it MUST reject the entire | |||
request with a 400 (Bad Request). If a client receives ill-formed | request with a 400 (Bad Request). If a client receives ill-formed | |||
XML in a response then it MUST NOT assume anything about the outcome | XML in a response then it MUST NOT assume anything about the outcome | |||
of the executed method and SHOULD treat the server as | of the executed method and SHOULD treat the server as | |||
malfunctioning. | malfunctioning. | |||
8.1 PROPFIND | 8.1 PROPFIND | |||
The PROPFIND method retrieves properties defined on the Request-URI, | The PROPFIND method retrieves properties defined on the resource | |||
if the resource does not have any internal members, or on the | identified by the Request-URI, if the resource does not have any | |||
Request-URI and potentially its member resources, if the resource | internal members, or on the resource identified by the Request-URI | |||
does have internal members. All DAV compliant resources MUST | and potentially its member resources, if the resource is a | |||
support the PROPFIND method and the propfind XML element (section | collection that has internal member URIs. All DAV compliant | |||
12.14) along with all XML elements defined for use with that | resources MUST support the PROPFIND method and the propfind XML | |||
element. | element (section 12.14) along with all XML elements defined for use | |||
with that element. | ||||
A client may submit a Depth header with a value of "0", "1", or | A client may submit a Depth header with a value of "0", "1", or | |||
"infinity" with a PROPFIND on a resource with internal members. DAV | "infinity" with a PROPFIND on a collection resource with internal | |||
compliant servers MUST support the "0", "1" and "infinity" | member URIs. DAV compliant servers MUST support the "0", "1" and | |||
behaviors. By default, the PROPFIND method without a Depth header | "infinity" behaviors. By default, the PROPFIND method without a | |||
MUST act as if a "Depth: infinity" header was included. | Depth header MUST act as if a "Depth: infinity" header was included. | |||
A client may submit a propfind XML element in the body of the | A client may submit a propfind XML element in the body of the | |||
request method describing what information is being requested. It | request method describing what information is being requested. It | |||
is possible to request particular property values, all property | is possible to request particular property values, all property | |||
values, or a list of the names of the resource's properties. A | values, or a list of the names of the resource's properties. A | |||
client may choose not to submit a request body. An empty PROPFIND | client may choose not to submit a request body. An empty PROPFIND | |||
request body MUST be treated as a request for the names and values | request body MUST be treated as a request for the names and values | |||
of all properties. | of all properties. | |||
All servers MUST support returning a response of content type | All servers MUST support returning a response of content type | |||
text/xml or application/xml that contains a multistatus XML element | text/xml or application/xml that contains a multistatus XML element | |||
that describes the results of the attempts to retrieve the various | that describes the results of the attempts to retrieve the various | |||
properties. | properties. | |||
If there is an error retrieving a property then a proper error | If there is an error retrieving a property then a proper error | |||
result MUST be included in the response. A request to retrieve the | result MUST be included in the response. A request to retrieve the | |||
value of a property which does not exist is an error and MUST be | value of a property which does not exist is an error and MUST be | |||
noted, if the response uses a multistatus XML element, with a | noted, if the response uses a multistatus XML element, with a | |||
response XML element which contains a 404 (Not Found) status value. | response XML element which contains a 404 (Not Found) status value. | |||
Consequently, the multistatus XML element for a resource with | Consequently, the multistatus XML element for a collection resource | |||
members MUST include a response XML element for each member of the | with member URIs MUST include a response XML element for each member | |||
resource, to whatever depth was requested. Each response XML element | URI of the collection, to whatever depth was requested. Each | |||
MUST contain an href XML element that identifies the resource on | response XML element MUST contain an href XML element that gives the | |||
which the properties in the prop XML element are defined. Results | URI of the resource on which the properties in the prop XML element | |||
for a PROPFIND on a resource with internal members are returned as a | are defined. Results for a PROPFIND on a collection resource with | |||
flat list whose order of entries is not significant. | internal member URIs are returned as a flat list whose order of | |||
entries is not significant. | ||||
In the case of allprop and propname, if a principal does not have | In the case of allprop and propname, if a principal does not have | |||
the right to know whether a particular property exists then the | the right to know whether a particular property exists then the | |||
property should be silently excluded from the response. | property should be silently excluded from the response. | |||
The results of this method SHOULD NOT be cached. | The results of this method SHOULD NOT be cached. | |||
8.1.1 Example - Retrieving Named Properties | 8.1.1 Example - Retrieving Named Properties | |||
>>Request | >>Request | |||
PROPFIND /file HTTP/1.1 | PROPFIND /file HTTP/1.1 | |||
Host: www.foo.bar | Host: www.foo.bar | |||
Content-type: text/xml; charset="utf-8" | Content-type: text/xml; charset="utf-8" | |||
Content-Length: xyz | Content-Length: xxxx | |||
<?xml version="1.0" encoding="utf-8" ?> | <?xml version="1.0" encoding="utf-8" ?> | |||
<D:propfind xmlns:D="DAV:"> | <D:propfind xmlns:D="DAV:"> | |||
<D:prop xmlns:R="http://www.foo.bar/boxschema/"> | <D:prop xmlns:R="http://www.foo.bar/boxschema/"> | |||
<R:bigbox/> | <R:bigbox/> | |||
<R:author/> | <R:author/> | |||
<R:DingALing/> | <R:DingALing/> | |||
<R:Random/> | <R:Random/> | |||
</D:prop> | </D:prop> | |||
</D:propfind> | </D:propfind> | |||
>>Response | >>Response | |||
HTTP/1.1 207 Multi-Status | HTTP/1.1 207 Multi-Status | |||
Content-Type: text/xml; charset="utf-8" | Content-Type: text/xml; charset="utf-8" | |||
Content-Length: xxxxx | Content-Length: xxxx | |||
<?xml version="1.0" encoding="utf-8" ?> | <?xml version="1.0" encoding="utf-8" ?> | |||
<D:multistatus xmlns:D="DAV:"> | <D:multistatus xmlns:D="DAV:"> | |||
<D:response> | <D:response> | |||
<D:href>http://www.foo.bar/file</D:href> | <D:href>http://www.foo.bar/file</D:href> | |||
<D:propstat> | <D:propstat> | |||
<D:prop xmlns:R="http://www.foo.bar/boxschema/"> | <D:prop xmlns:R="http://www.foo.bar/boxschema/"> | |||
<R:bigbox> | <R:bigbox> | |||
<R:BoxType>Box type A</R:BoxType> | <R:BoxType>Box type A</R:BoxType> | |||
</R:bigbox> | </R:bigbox> | |||
skipping to change at page 26, line 19 | skipping to change at page 26, line 30 | |||
and fourth properties. | and fourth properties. | |||
8.1.2 Example - Using allprop to Retrieve All Properties | 8.1.2 Example - Using allprop to Retrieve All Properties | |||
>>Request | >>Request | |||
PROPFIND /container/ HTTP/1.1 | PROPFIND /container/ HTTP/1.1 | |||
Host: www.foo.bar | Host: www.foo.bar | |||
Depth: 1 | Depth: 1 | |||
Content-Type: text/xml; charset="utf-8" | Content-Type: text/xml; charset="utf-8" | |||
Content-Length: xxxxx | Content-Length: xxxx | |||
<?xml version="1.0" encoding="utf-8" ?> | <?xml version="1.0" encoding="utf-8" ?> | |||
<D:propfind xmlns:D="DAV:"> | <D:propfind xmlns:D="DAV:"> | |||
<D:allprop/> | <D:allprop/> | |||
</D:propfind> | </D:propfind> | |||
>>Response | >>Response | |||
HTTP/1.1 207 Multi-Status | HTTP/1.1 207 Multi-Status | |||
Content-Type: text/xml; charset="utf-8" | Content-Type: text/xml; charset="utf-8" | |||
Content-Length: xxxxx | Content-Length: xxxx | |||
<?xml version="1.0" encoding="utf-8" ?> | <?xml version="1.0" encoding="utf-8" ?> | |||
<D:multistatus xmlns:D="DAV:"> | <D:multistatus xmlns:D="DAV:"> | |||
<D:response> | <D:response> | |||
<D:href>http://www.foo.bar/container/</D:href> | <D:href>http://www.foo.bar/container/</D:href> | |||
<D:propstat> | <D:propstat> | |||
<D:prop xmlns:R="http://www.foo.bar/boxschema/"> | <D:prop xmlns:R="http://www.foo.bar/boxschema/"> | |||
<R:bigbox> | <R:bigbox> | |||
<R:BoxType>Box type A</R:BoxType> | <R:BoxType>Box type A</R:BoxType> | |||
</R:bigbox> | </R:bigbox> | |||
skipping to change at page 29, line 12 | skipping to change at page 29, line 12 | |||
not a collection (resourcetype), and supports both exclusive write | not a collection (resourcetype), and supports both exclusive write | |||
and shared write locks (supportedlock). | and shared write locks (supportedlock). | |||
8.1.3 Example - Using propname to Retrieve all Property Names | 8.1.3 Example - Using propname to Retrieve all Property Names | |||
>>Request | >>Request | |||
PROPFIND /container/ HTTP/1.1 | PROPFIND /container/ HTTP/1.1 | |||
Host: www.foo.bar | Host: www.foo.bar | |||
Content-Type: text/xml; charset="utf-8" | Content-Type: text/xml; charset="utf-8" | |||
Content-Length: xxxxx | Content-Length: xxxx | |||
<?xml version="1.0" encoding="utf-8" ?> | <?xml version="1.0" encoding="utf-8" ?> | |||
<propfind xmlns="DAV:"> | <propfind xmlns="DAV:"> | |||
<propname/> | <propname/> | |||
</propfind> | </propfind> | |||
>>Response | >>Response | |||
HTTP/1.1 207 Multi-Status | HTTP/1.1 207 Multi-Status | |||
Content-Type: text/xml; charset="utf-8" | Content-Type: text/xml; charset="utf-8" | |||
skipping to change at page 31, line 53 | skipping to change at page 32, line 4 | |||
<Z:authors> | <Z:authors> | |||
<Z:Author>Jim Whitehead</Z:Author> | <Z:Author>Jim Whitehead</Z:Author> | |||
<Z:Author>Roy Fielding</Z:Author> | <Z:Author>Roy Fielding</Z:Author> | |||
</Z:authors> | </Z:authors> | |||
</D:prop> | </D:prop> | |||
</D:set> | </D:set> | |||
<D:remove> | <D:remove> | |||
<D:prop><Z:Copyright-Owner/></D:prop> | <D:prop><Z:Copyright-Owner/></D:prop> | |||
</D:remove> | </D:remove> | |||
</D:propertyupdate> | </D:propertyupdate> | |||
>>Response | >>Response | |||
HTTP/1.1 207 Multi-Status | HTTP/1.1 207 Multi-Status | |||
Content-Type: text/xml; charset="utf-8" | Content-Type: text/xml; charset="utf-8" | |||
Content-Length: xxxxx | Content-Length: xxxx | |||
<?xml version="1.0" encoding="utf-8" ?> | <?xml version="1.0" encoding="utf-8" ?> | |||
<D:multistatus xmlns:D="DAV:" | <D:multistatus xmlns:D="DAV:" | |||
xmlns:Z="http://www.w3.com/standards/z39.50"> | xmlns:Z="http://www.w3.com/standards/z39.50"> | |||
<D:response> | <D:response> | |||
<D:href>http://www.foo.com/bar.html</D:href> | <D:href>http://www.foo.com/bar.html</D:href> | |||
<D:propstat> | <D:propstat> | |||
<D:prop><Z:Authors/></D:prop> | <D:prop><Z:Authors/></D:prop> | |||
<D:status>HTTP/1.1 424 Failed Dependency</D:status> | <D:status>HTTP/1.1 424 Failed Dependency</D:status> | |||
</D:propstat> | </D:propstat> | |||
skipping to change at page 34, line 32 | skipping to change at page 34, line 32 | |||
Since by definition the actual function performed by POST is | Since by definition the actual function performed by POST is | |||
determined by the server and often depends on the particular | determined by the server and often depends on the particular | |||
resource, the behavior of POST when applied to collections cannot be | resource, the behavior of POST when applied to collections cannot be | |||
meaningfully modified because it is largely undefined. Thus the | meaningfully modified because it is largely undefined. Thus the | |||
semantics of POST are unmodified when applied to a collection. | semantics of POST are unmodified when applied to a collection. | |||
8.6 DELETE | 8.6 DELETE | |||
8.6.1 DELETE for Non-Collection Resources | 8.6.1 DELETE for Non-Collection Resources | |||
If the DELETE method is issued to a non-collection resource which is | If the DELETE method is issued to a non-collection resource whose | |||
an internal member of a collection, then during DELETE processing a | URIs are an internal member of one or more collections, then during | |||
server MUST remove the Request-URI from its parent collection. | DELETE processing a server MUST remove any URI for the resource | |||
identified by the Request-URI from collections which contain it as a | ||||
member. | ||||
8.6.2 DELETE for Collections | 8.6.2 DELETE for Collections | |||
The DELETE method on a collection MUST act as if a "Depth: infinity" | The DELETE method on a collection MUST act as if a "Depth: infinity" | |||
header was used on it. A client MUST NOT submit a Depth header with | header was used on it. A client MUST NOT submit a Depth header with | |||
a DELETE on a collection with any value but infinity. | a DELETE on a collection with any value but infinity. | |||
DELETE instructs that the collection specified in the Request-URI | DELETE instructs that the collection specified in the Request-URI | |||
and all its internal member resources are to be deleted. | and all resources identified by its internal member URIs are to be | |||
deleted. | ||||
If any member cannot be deleted then all of the member's ancestors | If any resource identified by a member URI cannot be deleted then | |||
MUST NOT be deleted, so as to maintain the namespace. | all of the member's ancestors MUST NOT be deleted, so as to maintain | |||
namespace consistency. | ||||
Any headers included with DELETE MUST be applied in processing every | Any headers included with DELETE MUST be applied in processing every | |||
resource to be deleted. | resource to be deleted. | |||
When the DELETE method has completed processing it MUST return a | When the DELETE method has completed processing it MUST result in a | |||
consistent namespace. | consistent namespace. | |||
If an error occurs with a resource other than the resource | If an error occurs with a resource other than the resource | |||
identified in the Request-URI then the response MUST be a 207 | identified in the Request-URI then the response MUST be a 207 | |||
(Multi-Status). 424 (Failed Dependency) errors SHOULD NOT be in the | (Multi-Status). 424 (Failed Dependency) errors SHOULD NOT be in the | |||
207 (Multi-Status). They can be safely left out because the client | 207 (Multi-Status). They can be safely left out because the client | |||
will know that the ancestors of a resource could not be deleted when | will know that the ancestors of a resource could not be deleted when | |||
the client receives an error for the ancestor's progeny. | the client receives an error for the ancestor's progeny. | |||
Additionally 204 (No Content) errors SHOULD NOT be returned in the | Additionally 204 (No Content) errors SHOULD NOT be returned in the | |||
207 (Multi-Status). The reason for this prohibition is that 204 (No | 207 (Multi-Status). The reason for this prohibition is that 204 (No | |||
skipping to change at page 35, line 20 | skipping to change at page 35, line 29 | |||
>>Request | >>Request | |||
DELETE /container/ HTTP/1.1 | DELETE /container/ HTTP/1.1 | |||
Host: www.foo.bar | Host: www.foo.bar | |||
>>Response | >>Response | |||
HTTP/1.1 207 Multi-Status | HTTP/1.1 207 Multi-Status | |||
Content-Type: text/xml; charset="utf-8" | Content-Type: text/xml; charset="utf-8" | |||
Content-Length: xxxxx | Content-Length: xxxx | |||
<?xml version="1.0" encoding="utf-8" ?> | <?xml version="1.0" encoding="utf-8" ?> | |||
<d:multistatus xmlns:d="DAV:"> | <d:multistatus xmlns:d="DAV:"> | |||
<d:response> | <d:response> | |||
<d:href>http://www.foo.bar/container/resource3</d:href> | <d:href>http://www.foo.bar/container/resource3</d:href> | |||
<d:status>HTTP/1.1 423 Locked</d:status> | <d:status>HTTP/1.1 423 Locked</d:status> | |||
</d:response> | </d:response> | |||
</d:multistatus> | </d:multistatus> | |||
In this example the attempt to delete | In this example the attempt to delete | |||
skipping to change at page 36, line 23 | skipping to change at page 36, line 29 | |||
the MKCOL method is defined to create collections. | the MKCOL method is defined to create collections. | |||
When the PUT operation creates a new non-collection resource all | When the PUT operation creates a new non-collection resource all | |||
ancestors MUST already exist. If all ancestors do not exist, the | ancestors MUST already exist. If all ancestors do not exist, the | |||
method MUST fail with a 409 (Conflict) status code. For example, if | method MUST fail with a 409 (Conflict) status code. For example, if | |||
resource /a/b/c/d.html is to be created and /a/b/c/ does not exist, | resource /a/b/c/d.html is to be created and /a/b/c/ does not exist, | |||
then the request must fail. | then the request must fail. | |||
8.8 COPY Method | 8.8 COPY Method | |||
The COPY method creates a duplicate of the source resource, given by | The COPY method creates a duplicate of the source resource, | |||
the Request-URI, in the destination resource, given by the | identified by the Request-URI, in the destination resource, | |||
Destination header. The Destination header MUST be present. The | identified by the URI in the Destination header. The Destination | |||
exact behavior of the COPY method depends on the type of the source | header MUST be present. The exact behavior of the COPY method | |||
resource. | depends on the type of the source resource. | |||
All WebDAV compliant resources MUST support the COPY method. | All WebDAV compliant resources MUST support the COPY method. | |||
However, support for the COPY method does not guarantee the ability | However, support for the COPY method does not guarantee the ability | |||
to copy a resource. For example, separate programs may control | to copy a resource. For example, separate programs may control | |||
resources on the same server. As a result, it may not be possible | resources on the same server. As a result, it may not be possible | |||
to copy a resource to a location that appears to be on the same | to copy a resource to a location that appears to be on the same | |||
server. | server. | |||
8.8.1 COPY for HTTP/1.1 resources | 8.8.1 COPY for HTTP/1.1 resources | |||
skipping to change at page 37, line 25 | skipping to change at page 37, line 32 | |||
propertybehavior XML element is defined in section 12.12. | propertybehavior XML element is defined in section 12.12. | |||
8.8.3 COPY for Collections | 8.8.3 COPY for Collections | |||
The COPY method on a collection without a Depth header MUST act as | The COPY method on a collection without a Depth header MUST act as | |||
if a Depth header with value "infinity" was included. A client may | if a Depth header with value "infinity" was included. A client may | |||
submit a Depth header on a COPY on a collection with a value of "0" | submit a Depth header on a COPY on a collection with a value of "0" | |||
or "infinity". DAV compliant servers MUST support the "0" and | or "infinity". DAV compliant servers MUST support the "0" and | |||
"infinity" Depth header behaviors. | "infinity" Depth header behaviors. | |||
A COPY of depth infinity instructs that the collection specified in | A COPY of depth infinity instructs that the collection resource | |||
the Request-URI is to be copied to the location specified in the | identified by the Request-URI is to be copied to the location | |||
Destination header, and all its internal member resources are to be | identified by the URI in the Destination header, and all its | |||
copied to a location relative to it, recursively through all levels | internal member resources are to be copied to a location relative to | |||
of the collection hierarchy. | it, recursively through all levels of the collection hierarchy. | |||
A COPY of "Depth: 0" only instructs that the collection and its | A COPY of "Depth: 0" only instructs that the collection and its | |||
properties but not its internal members, are to be copied. | properties but not resources identified by its internal member URIs, | |||
are to be copied. | ||||
Any headers included with a COPY MUST be applied in processing every | Any headers included with a COPY MUST be applied in processing every | |||
resource to be copied with the exception of the Destination header. | resource to be copied with the exception of the Destination header. | |||
The Destination header only specifies the destination for the | The Destination header only specifies the destination URI for the | |||
Request-URI. When applied to members of the collection specified in | Request-URI. When applied to members of the collection identified by | |||
the Request-URI the value of Destination is to be modified to | the Request-URI the value of Destination is to be modified to | |||
reflect the current location in the hierarchy. So, if the Request- | reflect the current location in the hierarchy. So, if the Request- | |||
URI is /a/ and the destination is /b/ then when /a/c/d is processed | URI is /a/ with Host header value http://fun.com/ and the | |||
it must use a destination of /b/c/d. | Destination is http://fun.com/b/ then when http://fun.com/a/c/d is | |||
processed it must use a Destination of http://fun.com/b/c/d. | ||||
When the COPY method has completed processing it MUST have created a | When the COPY method has completed processing it MUST have created a | |||
consistent namespace at the destination (see section 5.1 for the | consistent namespace at the destination (see section 5.1 for the | |||
definition of namespace consistency). However, if an error occurs | definition of namespace consistency). However, if an error occurs | |||
while copying an internal member collection, the server MUST NOT | while copying an internal collection, the server MUST NOT copy any | |||
copy any members of this collection (i.e., the server must skip this | resources identified by members of this collection (i.e., the server | |||
subtree), as this would create an inconsistent namespace. After | must skip this subtree), as this would create an inconsistent | |||
detecting an error, the COPY operation SHOULD try to finish as much | namespace. After detecting an error, the COPY operation SHOULD try | |||
of the original copy operation as possible (i.e., the server should | to finish as much of the original copy operation as possible (i.e., | |||
still attempt to copy other subtrees and their members, that are not | the server should still attempt to copy other subtrees and their | |||
descendents of an error-causing collection). So, for example, if an | members, that are not descendents of an error-causing collection). | |||
infinite depth copy operation is performed on collection /a/, which | So, for example, if an infinite depth copy operation is performed on | |||
contains collections /a/b/ and /a/c/, and an error occurs copying | collection /a/, which contains collections /a/b/ and /a/c/, and an | |||
/a/b/, an attempt should still be made to copy /a/c/. Similarly, | error occurs copying /a/b/, an attempt should still be made to copy | |||
after encountering an error copying a non-collection resource as | /a/c/. Similarly, after encountering an error copying a non- | |||
part of an infinite depth copy, the server SHOULD try to finish as | collection resource as part of an infinite depth copy, the server | |||
much of the original copy operation as possible. | SHOULD try to finish as much of the original copy operation as | |||
possible. | ||||
If an error in executing the COPY method occurs with a resource | If an error in executing the COPY method occurs with a resource | |||
other than the resource identified in the Request-URI then the | other than the resource identified in the Request-URI then the | |||
response MUST be a 207 (Multi-Status). | response MUST be a 207 (Multi-Status). | |||
The 424 (Failed Dependency) status code SHOULD NOT be returned in | The 424 (Failed Dependency) status code SHOULD NOT be returned in | |||
the 207 (Multi-Status) response from a COPY method. These responses | the 207 (Multi-Status) response from a COPY method. These responses | |||
can be safely omitted because the client will know that the progeny | can be safely omitted because the client will know that the progeny | |||
of a resource could not be copied when the client receives an error | of a resource could not be copied when the client receives an error | |||
for the parent. Additionally 201 (Created)/204 (No Content) status | for the parent. Additionally 201 (Created)/204 (No Content) status | |||
skipping to change at page 39, line 50 | skipping to change at page 40, line 14 | |||
8.8.8 Example - COPY of a Collection | 8.8.8 Example - COPY of a Collection | |||
>>Request | >>Request | |||
COPY /container/ HTTP/1.1 | COPY /container/ HTTP/1.1 | |||
Host: www.foo.bar | Host: www.foo.bar | |||
Destination: http://www.foo.bar/othercontainer/ | Destination: http://www.foo.bar/othercontainer/ | |||
Depth: infinity | Depth: infinity | |||
Content-Type: text/xml; charset="utf-8" | Content-Type: text/xml; charset="utf-8" | |||
Content-Length: xxxxx | Content-Length: xxxx | |||
<?xml version="1.0" encoding="utf-8" ?> | <?xml version="1.0" encoding="utf-8" ?> | |||
<d:propertybehavior xmlns:d="DAV:"> | <d:propertybehavior xmlns:d="DAV:"> | |||
<d:keepalive>*</d:keepalive> | <d:keepalive>*</d:keepalive> | |||
</d:propertybehavior> | </d:propertybehavior> | |||
>>Response | >>Response | |||
HTTP/1.1 207 Multi-Status | HTTP/1.1 207 Multi-Status | |||
Content-Type: text/xml; charset="utf-8" | Content-Type: text/xml; charset="utf-8" | |||
Content-Length: xxxxx | Content-Length: xxxx | |||
<?xml version="1.0" encoding="utf-8" ?> | <?xml version="1.0" encoding="utf-8" ?> | |||
<d:multistatus xmlns:d="DAV:"> | <d:multistatus xmlns:d="DAV:"> | |||
<d:response> | <d:response> | |||
<d:href>http://www.foo.bar/othercontainer/R2/</d:href> | <d:href>http://www.foo.bar/othercontainer/R2/</d:href> | |||
<d:status>HTTP/1.1 412 Precondition Failed</d:status> | <d:status>HTTP/1.1 412 Precondition Failed</d:status> | |||
</d:response> | </d:response> | |||
</d:multistatus> | </d:multistatus> | |||
The Depth header is unnecessary as the default behavior of COPY on a | The Depth header is unnecessary as the default behavior of COPY on a | |||
skipping to change at page 40, line 31 | skipping to change at page 40, line 48 | |||
collection, were copied successfully. However the collection R2 | collection, were copied successfully. However the collection R2 | |||
failed, most likely due to a problem with maintaining the liveness | failed, most likely due to a problem with maintaining the liveness | |||
of properties (this is specified by the propertybehavior XML | of properties (this is specified by the propertybehavior XML | |||
element). Because there was an error copying R2, none of R2's | element). Because there was an error copying R2, none of R2's | |||
members were copied. However no errors were listed for those | members were copied. However no errors were listed for those | |||
members due to the error minimization rules given in section 8.8.3. | members due to the error minimization rules given in section 8.8.3. | |||
8.9 MOVE Method | 8.9 MOVE Method | |||
The MOVE operation on a non-collection resource is the logical | The MOVE operation on a non-collection resource is the logical | |||
equivalent of a copy (COPY) followed by a delete of the source, | equivalent of a copy (COPY), followed by consistency maintenance | |||
where the actions are performed atomically. Consequently, the | processing, followed by a delete of the source, where all three | |||
Destination header MUST be present on all MOVE methods and MUST | actions are performed atomically. The consistency maintenance step | |||
follow all COPY requirements for the COPY part of the MOVE method. | allows the server to perform updates caused by the move, such as | |||
All DAV compliant resources MUST support the MOVE method. However, | updating all URIs other than the Request-URI which identify the | |||
support for the MOVE method does not guarantee the ability to move a | source resource, to point to the new destination resource. | |||
resource to a particular destination. | Consequently, the Destination header MUST be present on all MOVE | |||
methods and MUST follow all COPY requirements for the COPY part of | ||||
the MOVE method. All DAV compliant resources MUST support the MOVE | ||||
method. However, support for the MOVE method does not guarantee the | ||||
ability to move a resource to a particular destination. | ||||
For example, separate programs may actually control different sets | For example, separate programs may actually control different sets | |||
of resources on the same server. Therefore, it may not be possible | of resources on the same server. Therefore, it may not be possible | |||
to move a resource within a namespace that appears to belong to the | to move a resource within a namespace that appears to belong to the | |||
same server. | same server. | |||
If a resource exists at the destination, the destination resource | If a resource exists at the destination, the destination resource | |||
will be DELETEd as a side-effect of the MOVE operation, subject to | will be DELETEd as a side-effect of the MOVE operation, subject to | |||
the restrictions of the Overwrite header. | the restrictions of the Overwrite header. | |||
8.9.1 MOVE for Properties | 8.9.1 MOVE for Properties | |||
The behavior of properties on a MOVE, including the effects of the | The behavior of properties on a MOVE, including the effects of the | |||
propertybehavior XML element, MUST be the same as specified in | propertybehavior XML element, MUST be the same as specified in | |||
section 8.8.2. | section 8.8.2. | |||
8.9.2 MOVE for Collections | 8.9.2 MOVE for Collections | |||
A MOVE with "Depth: infinity" instructs that the collection | A MOVE with "Depth: infinity" instructs that the collection | |||
specified in the Request-URI be moved to the location specified in | identified by the Request-URI be moved to the URI specified in the | |||
the Destination header, and all its internal member resources are to | Destination header, and all resources identified by its internal | |||
be moved to locations relative to it, recursively through all levels | member URIs are to be moved to locations relative to it, recursively | |||
of the collection hierarchy. | through all levels of the collection hierarchy. | |||
The MOVE method on a collection MUST act as if a "Depth: infinity" | The MOVE method on a collection MUST act as if a "Depth: infinity" | |||
header was used on it. A client MUST NOT submit a Depth header on a | header was used on it. A client MUST NOT submit a Depth header on a | |||
MOVE on a collection with any value but "infinity". | MOVE on a collection with any value but "infinity". | |||
Any headers included with MOVE MUST be applied in processing every | Any headers included with MOVE MUST be applied in processing every | |||
resource to be moved with the exception of the Destination header. | resource to be moved with the exception of the Destination header. | |||
The behavior of the Destination header is the same as given for COPY | The behavior of the Destination header is the same as given for COPY | |||
on collections. | on collections. | |||
When the MOVE method has completed processing it MUST have created a | When the MOVE method has completed processing it MUST have created a | |||
consistent namespace on both the source and destination (see section | consistent namespace at both the source and destination (see section | |||
5.1 for the definition of namespace consistency). However, if an | 5.1 for the definition of namespace consistency). However, if an | |||
error occurs while moving an internal member collection, the server | error occurs while moving an internal collection, the server MUST | |||
MUST NOT move any members of the failed collection (i.e., the server | NOT move any resources identified by members of the failed | |||
must skip the error-causing subtree), as this would create an | collection (i.e., the server must skip the error-causing subtree), | |||
inconsistent namespace. In this case, after detecting the error, the | as this would create an inconsistent namespace. In this case, after | |||
move operation SHOULD try to finish as much of the original move as | detecting the error, the move operation SHOULD try to finish as much | |||
possible (i.e., the server should still attempt to move other | of the original move as possible (i.e., the server should still | |||
subtrees and their members, that are not descendents of an error- | attempt to move other subtrees and the resources identified by their | |||
causing collection). So, for example, if an infinite depth move is | members, that are not descendents of an error-causing collection). | |||
performed on collection /a/, which contains collections /a/b/ and | So, for example, if an infinite depth move is performed on | |||
/a/c/, and an error occurs moving /a/b/, an attempt should still be | collection /a/, which contains collections /a/b/ and /a/c/, and an | |||
made to try moving /a/c/. Similarly, after encountering an error | error occurs moving /a/b/, an attempt should still be made to try | |||
moving a non-collection resource as part of an infinite depth move, | moving /a/c/. Similarly, after encountering an error moving a non- | |||
the server SHOULD try to finish as much of the original move | collection resource as part of an infinite depth move, the server | |||
operation as possible. | SHOULD try to finish as much of the original move operation as | |||
possible. | ||||
If an error occurs with a resource other than the resource | If an error occurs with a resource other than the resource | |||
identified in the Request-URI then the response MUST be a 207 | identified in the Request-URI then the response MUST be a 207 | |||
(Multi-Status). | (Multi-Status). | |||
The 424 (Failed Dependency) status code SHOULD NOT be returned in | The 424 (Failed Dependency) status code SHOULD NOT be returned in | |||
the 207 (Multi-Status) response from a MOVE method. These errors | the 207 (Multi-Status) response from a MOVE method. These errors | |||
can be safely omitted because the client will know that the progeny | can be safely omitted because the client will know that the progeny | |||
of a resource could not be moved when the client receives an error | of a resource could not be moved when the client receives an error | |||
for the parent. Additionally 201 (Created)/204 (No Content) | for the parent. Additionally 201 (Created)/204 (No Content) | |||
skipping to change at page 43, line 16 | skipping to change at page 43, line 32 | |||
>>Request | >>Request | |||
MOVE /container/ HTTP/1.1 | MOVE /container/ HTTP/1.1 | |||
Host: www.foo.bar | Host: www.foo.bar | |||
Destination: http://www.foo.bar/othercontainer/ | Destination: http://www.foo.bar/othercontainer/ | |||
Overwrite: F | Overwrite: F | |||
If: (<opaquelocktoken:fe184f2e-6eec-41d0-c765-01adc56e6bb4>) | If: (<opaquelocktoken:fe184f2e-6eec-41d0-c765-01adc56e6bb4>) | |||
(<opaquelocktoken:e454f3f3-acdc-452a-56c7-00a5c91e4b77>) | (<opaquelocktoken:e454f3f3-acdc-452a-56c7-00a5c91e4b77>) | |||
Content-Type: text/xml; charset="utf-8" | Content-Type: text/xml; charset="utf-8" | |||
Content-Length: xyz | Content-Length: xxxx | |||
<?xml version="1.0" encoding="utf-8" ?> | <?xml version="1.0" encoding="utf-8" ?> | |||
<d:propertybehavior xmlns:d='DAV:'> | <d:propertybehavior xmlns:d='DAV:'> | |||
<d:keepalive>*</d:keepalive> | <d:keepalive>*</d:keepalive> | |||
</d:propertybehavior> | </d:propertybehavior> | |||
>>Response | >>Response | |||
HTTP/1.1 207 Multi-Status | HTTP/1.1 207 Multi-Status | |||
Content-Type: text/xml; charset="utf-8" | Content-Type: text/xml; charset="utf-8" | |||
Content-Length: zzz | Content-Length: xxxx | |||
<?xml version="1.0" encoding="utf-8" ?> | <?xml version="1.0" encoding="utf-8" ?> | |||
<d:multistatus xmlns:d='DAV:'> | <d:multistatus xmlns:d='DAV:'> | |||
<d:response> | <d:response> | |||
<d:href>http://www.foo.bar/othercontainer/C2/</d:href> | <d:href>http://www.foo.bar/othercontainer/C2/</d:href> | |||
<d:status>HTTP/1.1 423 Locked</d:status> | <d:status>HTTP/1.1 423 Locked</d:status> | |||
</d:response> | </d:response> | |||
</d:multistatus> | </d:multistatus> | |||
In this example the client has submitted a number of lock tokens | In this example the client has submitted a number of lock tokens | |||
with the request. A lock token will need to be submitted for every | with the request. A lock token will need to be submitted for every | |||
resource, both source and destination, anywhere in the scope of the | resource, both source and destination, anywhere in the scope of the | |||
method, that is locked. In this case the proper lock token was not | method, that is locked. In this case the proper lock token was not | |||
submitted for the destination http://www.foo.bar/othercontainer/C2/. | submitted for the destination http://www.foo.bar/othercontainer/C2/. | |||
This means that the resource /container/C2/ could not be moved. | This means that the resource /container/C2/ could not be moved. | |||
Because there was an error copying /container/C2/, none of | Because there was an error copying /container/C2/, none of | |||
/container/C2's members were copied. However no errors were listed | /container/C2's members were copied. However no errors were listed | |||
for those members due to the error minimization rules given in | for those members due to the error minimization rules given in | |||
section 8.8.3. User agent authentication has previously occurred | section 8.8.3. User agent authentication has previously occurred | |||
skipping to change at page 45, line 36 | skipping to change at page 46, line 12 | |||
lock type. However, independent of lock type, a successful DELETE | lock type. However, independent of lock type, a successful DELETE | |||
of a resource MUST cause all of its locks to be removed. | of a resource MUST cause all of its locks to be removed. | |||
8.10.6 Lock Compatibility Table | 8.10.6 Lock Compatibility Table | |||
The table below describes the behavior that occurs when a lock | The table below describes the behavior that occurs when a lock | |||
request is made on a resource. | request is made on a resource. | |||
Current lock state/ | Shared Lock | Exclusive | Current lock state/ | Shared Lock | Exclusive | |||
Lock request | | Lock | Lock request | | Lock | |||
=====================+=================+=============== | =====================+=================+============== | |||
None | True | True | None | True | True | |||
---------------------+-----------------+--------------- | ---------------------+-----------------+-------------- | |||
Shared Lock | True | False | Shared Lock | True | False | |||
---------------------+-----------------+--------------- | ---------------------+-----------------+-------------- | |||
Exclusive Lock | False | False* | Exclusive Lock | False | False* | |||
------------------------------------------------------- | ------------------------------------------------------ | |||
Legend: True = lock may be granted. False = lock MUST NOT be | Legend: True = lock may be granted. False = lock MUST NOT be | |||
granted. *=It is illegal for a principal to request the same lock | granted. *=It is illegal for a principal to request the same lock | |||
twice. | twice. | |||
The current lock state of a resource is given in the leftmost | The current lock state of a resource is given in the leftmost | |||
column, and lock requests are listed in the first row. The | column, and lock requests are listed in the first row. The | |||
intersection of a row and column gives the result of a lock request. | intersection of a row and column gives the result of a lock request. | |||
For example, if a shared lock is held on a resource, and an | For example, if a shared lock is held on a resource, and an | |||
exclusive lock is requested, the table entry is "false", indicating | exclusive lock is requested, the table entry is "false", indicating | |||
skipping to change at page 46, line 25 | skipping to change at page 47, line 13 | |||
rejected. | rejected. | |||
8.10.8 Example - Simple Lock Request | 8.10.8 Example - Simple Lock Request | |||
>>Request | >>Request | |||
LOCK /workspace/webdav/proposal.doc HTTP/1.1 | LOCK /workspace/webdav/proposal.doc HTTP/1.1 | |||
Host: webdav.sb.aol.com | Host: webdav.sb.aol.com | |||
Timeout: Infinite, Second-4100000000 | Timeout: Infinite, Second-4100000000 | |||
Content-Type: text/xml; charset="utf-8" | Content-Type: text/xml; charset="utf-8" | |||
Content-Length: xyz | Content-Length: xxxx | |||
Authorization: Digest username="ejw", | Authorization: Digest username="ejw", | |||
realm="ejw@webdav.sb.aol.com", nonce="...", | realm="ejw@webdav.sb.aol.com", nonce="...", | |||
uri="/workspace/webdav/proposal.doc", | uri="/workspace/webdav/proposal.doc", | |||
response="...", opaque="..." | response="...", opaque="..." | |||
<?xml version="1.0" encoding="utf-8" ?> | <?xml version="1.0" encoding="utf-8" ?> | |||
<D:lockinfo xmlns:D='DAV:'> | <D:lockinfo xmlns:D='DAV:'> | |||
<D:lockscope><D:exclusive/></D:lockscope> | <D:lockscope><D:exclusive/></D:lockscope> | |||
<D:locktype><D:write/></D:locktype> | <D:locktype><D:write/></D:locktype> | |||
<D:owner> | <D:owner> | |||
skipping to change at page 47, line 4 | skipping to change at page 47, line 27 | |||
response="...", opaque="..." | response="...", opaque="..." | |||
<?xml version="1.0" encoding="utf-8" ?> | <?xml version="1.0" encoding="utf-8" ?> | |||
<D:lockinfo xmlns:D='DAV:'> | <D:lockinfo xmlns:D='DAV:'> | |||
<D:lockscope><D:exclusive/></D:lockscope> | <D:lockscope><D:exclusive/></D:lockscope> | |||
<D:locktype><D:write/></D:locktype> | <D:locktype><D:write/></D:locktype> | |||
<D:owner> | <D:owner> | |||
<D:href>http://www.ics.uci.edu/~ejw/contact.html</D:href> | <D:href>http://www.ics.uci.edu/~ejw/contact.html</D:href> | |||
</D:owner> | </D:owner> | |||
</D:lockinfo> | </D:lockinfo> | |||
>>Response | >>Response | |||
HTTP/1.1 200 OK | HTTP/1.1 200 OK | |||
Content-Type: text/xml; charset="utf-8" | Content-Type: text/xml; charset="utf-8" | |||
Content-Length: xxxxx | Content-Length: xxxx | |||
<?xml version="1.0" encoding="utf-8" ?> | <?xml version="1.0" encoding="utf-8" ?> | |||
<D:prop xmlns:D="DAV:"> | <D:prop xmlns:D="DAV:"> | |||
<D:lockdiscovery> | <D:lockdiscovery> | |||
<D:activelock> | <D:activelock> | |||
<D:locktype><D:write/></D:locktype> | <D:locktype><D:write/></D:locktype> | |||
<D:lockscope><D:exclusive/></D:lockscope> | <D:lockscope><D:exclusive/></D:lockscope> | |||
<D:depth>Infinity</D:depth> | <D:depth>Infinity</D:depth> | |||
<D:owner> | <D:owner> | |||
<D:href> | <D:href> | |||
skipping to change at page 48, line 22 | skipping to change at page 48, line 31 | |||
If: (<opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>) | If: (<opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>) | |||
Authorization: Digest username="ejw", | Authorization: Digest username="ejw", | |||
realm="ejw@webdav.sb.aol.com", nonce="...", | realm="ejw@webdav.sb.aol.com", nonce="...", | |||
uri="/workspace/webdav/proposal.doc", | uri="/workspace/webdav/proposal.doc", | |||
response="...", opaque="..." | response="...", opaque="..." | |||
>>Response | >>Response | |||
HTTP/1.1 200 OK | HTTP/1.1 200 OK | |||
Content-Type: text/xml; charset="utf-8" | Content-Type: text/xml; charset="utf-8" | |||
Content-Length: xxxxx | Content-Length: xxxx | |||
<?xml version="1.0" encoding="utf-8" ?> | <?xml version="1.0" encoding="utf-8" ?> | |||
<D:prop xmlns:D="DAV:"> | <D:prop xmlns:D="DAV:"> | |||
<D:lockdiscovery> | <D:lockdiscovery> | |||
<D:activelock> | <D:activelock> | |||
<D:locktype><D:write/></D:locktype> | <D:locktype><D:write/></D:locktype> | |||
<D:lockscope><D:exclusive/></D:lockscope> | <D:lockscope><D:exclusive/></D:lockscope> | |||
<D:depth>Infinity</D:depth> | <D:depth>Infinity</D:depth> | |||
<D:owner> | <D:owner> | |||
<D:href> | <D:href> | |||
skipping to change at page 49, line 14 | skipping to change at page 49, line 19 | |||
8.10.10 Example - Multi-Resource Lock Request | 8.10.10 Example - Multi-Resource Lock Request | |||
>>Request | >>Request | |||
LOCK /webdav/ HTTP/1.1 | LOCK /webdav/ HTTP/1.1 | |||
Host: webdav.sb.aol.com | Host: webdav.sb.aol.com | |||
Timeout: Infinite, Second-4100000000 | Timeout: Infinite, Second-4100000000 | |||
Depth: infinity | Depth: infinity | |||
Content-Type: text/xml; charset="utf-8" | Content-Type: text/xml; charset="utf-8" | |||
Content-Length: xxxxx | Content-Length: xxxx | |||
Authorization: Digest username="ejw", | Authorization: Digest username="ejw", | |||
realm="ejw@webdav.sb.aol.com", nonce="...", | realm="ejw@webdav.sb.aol.com", nonce="...", | |||
uri="/workspace/webdav/proposal.doc", | uri="/workspace/webdav/proposal.doc", | |||
response="...", opaque="..." | response="...", opaque="..." | |||
<?xml version="1.0" encoding="utf-8" ?> | <?xml version="1.0" encoding="utf-8" ?> | |||
<D:lockinfo xmlns:D="DAV:"> | <D:lockinfo xmlns:D="DAV:"> | |||
<D:locktype><D:write/></D:locktype> | <D:locktype><D:write/></D:locktype> | |||
<D:lockscope><D:exclusive/></D:lockscope> | <D:lockscope><D:exclusive/></D:lockscope> | |||
<D:owner> | <D:owner> | |||
<D:href>http://www.ics.uci.edu/~ejw/contact.html</D:href> | <D:href>http://www.ics.uci.edu/~ejw/contact.html</D:href> | |||
</D:owner> | </D:owner> | |||
</D:lockinfo> | </D:lockinfo> | |||
>>Response | >>Response | |||
HTTP/1.1 207 Multi-Status | HTTP/1.1 207 Multi-Status | |||
Content-Type: text/xml; charset="utf-8" | Content-Type: text/xml; charset="utf-8" | |||
Content-Length: xxxxx | Content-Length: xxxx | |||
<?xml version="1.0" encoding="utf-8" ?> | <?xml version="1.0" encoding="utf-8" ?> | |||
<D:multistatus xmlns:D="DAV:"> | <D:multistatus xmlns:D="DAV:"> | |||
<D:response> | <D:response> | |||
<D:href>http://webdav.sb.aol.com/webdav/secret</D:href> | <D:href>http://webdav.sb.aol.com/webdav/secret</D:href> | |||
<D:status>HTTP/1.1 403 Forbidden</D:status> | <D:status>HTTP/1.1 403 Forbidden</D:status> | |||
</D:response> | </D:response> | |||
<D:response> | <D:response> | |||
<D:href>http://webdav.sb.aol.com/webdav/</D:href> | <D:href>http://webdav.sb.aol.com/webdav/</D:href> | |||
<D:propstat> | <D:propstat> | |||
skipping to change at page 52, line 33 | skipping to change at page 52, line 40 | |||
for the Depth header that is not allowed by the method's definition. | for the Depth header that is not allowed by the method's definition. | |||
Thus submitting a "Depth: 1" on a COPY, even if the resource does | Thus submitting a "Depth: 1" on a COPY, even if the resource does | |||
not have internal members, will result in a 400 (Bad Request). The | not have internal members, will result in a 400 (Bad Request). The | |||
method should fail not because the resource doesn't have internal | method should fail not because the resource doesn't have internal | |||
members, but because of the illegal value in the header. | members, but because of the illegal value in the header. | |||
9.3 Destination Header | 9.3 Destination Header | |||
Destination = "Destination" ":" absoluteURI | Destination = "Destination" ":" absoluteURI | |||
The Destination header specifies a destination resource for methods | The Destination header specifies the URI which identifies a | |||
such as COPY and MOVE, which take two URIs as parameters. Note that | destination resource for methods such as COPY and MOVE, which take | |||
the absoluteURI production is defined in [RFC2396]. | two URIs as parameters. Note that the absoluteURI production is | |||
defined in [RFC2396]. | ||||
9.4 If Header | 9.4 If Header | |||
If = "If" ":" ( 1*No-tag-list | 1*Tagged-list) | If = "If" ":" ( 1*No-tag-list | 1*Tagged-list) | |||
No-tag-list = List | No-tag-list = List | |||
Tagged-list = Resource 1*List | Tagged-list = Resource 1*List | |||
Resource = Coded-url | Resource = Coded-URL | |||
List = "(" 1*(["Not"](State-token | "[" entity-tag "]")) ")" | List = "(" 1*(["Not"](State-token | "[" entity-tag "]")) ")" | |||
State-token = Coded-URL | State-token = Coded-URL | |||
Coded-URL = "<" absoluteURI ">" | Coded-URL = "<" absoluteURI ">" | |||
The If header is intended to have similar functionality to the If- | The If header is intended to have similar functionality to the If- | |||
Match header defined in section 14.25 of [RFC2068]. However the If | Match header defined in section 14.25 of [RFC2068]. However the If | |||
header is intended for use with any URI which represents state | header is intended for use with any URI which represents state | |||
information, referred to as a state token, about a resource as well | information, referred to as a state token, about a resource as well | |||
as ETags. A typical example of a state token is a lock token, and | as ETags. A typical example of a state token is a lock token, and | |||
lock tokens are the only state tokens defined in this specification. | lock tokens are the only state tokens defined in this specification. | |||
skipping to change at page 56, line 30 | skipping to change at page 56, line 40 | |||
However, the server is not required to honor or even consider these | However, the server is not required to honor or even consider these | |||
requests. Clients MUST NOT submit a Timeout request header with any | requests. Clients MUST NOT submit a Timeout request header with any | |||
method other than a LOCK method. | method other than a LOCK method. | |||
A Timeout request header MUST contain at least one TimeType and may | A Timeout request header MUST contain at least one TimeType and may | |||
contain multiple TimeType entries. The purpose of listing multiple | contain multiple TimeType entries. The purpose of listing multiple | |||
TimeType entries is to indicate multiple different values and value | TimeType entries is to indicate multiple different values and value | |||
types that are acceptable to the client. The client lists the | types that are acceptable to the client. The client lists the | |||
TimeType entries in order of preference. | TimeType entries in order of preference. | |||
Timeout response valuse MUST use a Second value, Infinite, or a | Timeout response values MUST use a Second value, Infinite, or a | |||
TimeType the client has indicated familiarity with. The server may | TimeType the client has indicated familiarity with. The server may | |||
assume a client is familiar with any TimeType submitted in a Timeout | assume a client is familiar with any TimeType submitted in a Timeout | |||
header. | header. | |||
The "Second" TimeType specifies the number of seconds that will | The "Second" TimeType specifies the number of seconds that will | |||
elapse between granting of the lock at the server, and the automatic | elapse between granting of the lock at the server, and the automatic | |||
removal of the lock. The timeout value for timetype "Second" MUST | removal of the lock. The timeout value for TimeType "Second" MUST | |||
NOT be greater than 2^32-1. | NOT be greater than 2^32-1. | |||
The timeout counter SHOULD be restarted any time an owner of the | The timeout counter SHOULD be restarted any time an owner of the | |||
lock sends a method to any member of the lock, including unsupported | lock sends a method to any member of the lock, including unsupported | |||
methods, or methods which are unsuccessful. However the lock MUST | methods, or methods which are unsuccessful. However the lock MUST | |||
be refreshed if a refresh LOCK method is successfully received. | be refreshed if a refresh LOCK method is successfully received. | |||
If the timeout expires then the lock may be lost. Specifically, if | If the timeout expires then the lock may be lost. Specifically, if | |||
the server wishes to harvest the lock upon time-out, the server | the server wishes to harvest the lock upon time-out, the server | |||
SHOULD act as if an UNLOCK method was executed by the server on the | SHOULD act as if an UNLOCK method was executed by the server on the | |||
skipping to change at page 65, line 26 | skipping to change at page 65, line 26 | |||
<!ELEMENT remove (prop) > | <!ELEMENT remove (prop) > | |||
12.13.2 set XML element | 12.13.2 set XML element | |||
Name: set | Name: set | |||
Namespace: DAV: | Namespace: DAV: | |||
Purpose: Lists the DAV property values to be set for a resource. | Purpose: Lists the DAV property values to be set for a resource. | |||
Description: The set XML element MUST contain only a prop XML | Description: The set XML element MUST contain only a prop XML | |||
element. The elements contained by the prop XML element inside the | element. The elements contained by the prop XML element inside the | |||
set XML element MUST specify the name and value of properties that | set XML element MUST specify the name and value of properties that | |||
are set on the Request-URI. If a property already exists then its | are set on the resource identified by Request-URI. If a property | |||
value is replaced. Language tagging information in the property's | already exists then its value is replaced. Language tagging | |||
value (in the "xml:lang" attribute, if present) MUST be persistently | information in the property's value (in the "xml:lang" attribute, if | |||
stored along with the property, and MUST be subsequently retrievable | present) MUST be persistently stored along with the property, and | |||
using PROPFIND. | MUST be subsequently retrievable using PROPFIND. | |||
<!ELEMENT set (prop) > | <!ELEMENT set (prop) > | |||
12.14 propfind XML Element | 12.14 propfind XML Element | |||
Name: propfind | Name: propfind | |||
Namespace: DAV: | Namespace: DAV: | |||
Purpose: Specifies the properties to be returned from a PROPFIND | Purpose: Specifies the properties to be returned from a PROPFIND | |||
method. Two special elements are specified for use with propfind, | method. Two special elements are specified for use with propfind, | |||
allprop and propname. If prop is used inside propfind it MUST only | allprop and propname. If prop is used inside propfind it MUST only | |||
skipping to change at page 69, line 8 | skipping to change at page 69, line 8 | |||
Content-Type: text/xml; charset="utf-8" | Content-Type: text/xml; charset="utf-8" | |||
<?xml version="1.0" encoding="utf-8" ?> | <?xml version="1.0" encoding="utf-8" ?> | |||
<D:propfind xmlns:D='DAV:'> | <D:propfind xmlns:D='DAV:'> | |||
<D:prop><D:lockdiscovery/></D:prop> | <D:prop><D:lockdiscovery/></D:prop> | |||
</D:propfind> | </D:propfind> | |||
>>Response | >>Response | |||
HTTP/1.1 207 Multi-Status | HTTP/1.1 207 Multi-Status | |||
Content-Type: text/xml; charset="utf-8" | Content-Type: text/xml; charset="utf-8" | |||
Content-Length: xxxxx | Content-Length: xxxx | |||
<?xml version="1.0" encoding="utf-8" ?> | <?xml version="1.0" encoding="utf-8" ?> | |||
<D:multistatus xmlns:D='DAV:'> | <D:multistatus xmlns:D='DAV:'> | |||
<D:response> | <D:response> | |||
<D:href>http://www.foo.bar/container/</D:href> | <D:href>http://www.foo.bar/container/</D:href> | |||
<D:propstat> | <D:propstat> | |||
<D:prop> | <D:prop> | |||
<D:lockdiscovery> | <D:lockdiscovery> | |||
<D:activelock> | <D:activelock> | |||
<D:locktype><D:write/></D:locktype> | <D:locktype><D:write/></D:locktype> | |||
skipping to change at page 72, line 7 | skipping to change at page 72, line 7 | |||
Content-Length: xxxx | Content-Length: xxxx | |||
Content-Type: text/xml; charset="utf-8" | Content-Type: text/xml; charset="utf-8" | |||
<?xml version="1.0" encoding="utf-8" ?> | <?xml version="1.0" encoding="utf-8" ?> | |||
<D:propfind xmlns:D="DAV:"> | <D:propfind xmlns:D="DAV:"> | |||
<D:prop><D:supportedlock/></D:prop> | <D:prop><D:supportedlock/></D:prop> | |||
</D:propfind> | </D:propfind> | |||
>>Response | >>Response | |||
HTTP/1.1 207 Multi-Status | HTTP/1.1 207 Multi-Status | |||
Content-Type: text/xml; charset="utf-8"Content-Length: xxxxx | Content-Type: text/xml; charset="utf-8" | |||
Content-Length: xxxx | ||||
<?xml version="1.0" encoding="utf-8" ?> | <?xml version="1.0" encoding="utf-8" ?> | |||
<D:multistatus xmlns:D="DAV:"> | <D:multistatus xmlns:D="DAV:"> | |||
<D:response> | <D:response> | |||
<D:href>http://www.foo.bar/container/</D:href> | <D:href>http://www.foo.bar/container/</D:href> | |||
<D:propstat> | <D:propstat> | |||
<D:prop> | <D:prop> | |||
<D:supportedlock> | <D:supportedlock> | |||
<D:lockentry> | <D:lockentry> | |||
<D:lockscope><D:exclusive/></D:lockscope> | <D:lockscope><D:exclusive/></D:lockscope> | |||
skipping to change at page 73, line 5 | skipping to change at page 72, line 49 | |||
property values where unknown XML elements SHOULD be ignored unless | property values where unknown XML elements SHOULD be ignored unless | |||
the property's schema declares otherwise. | the property's schema declares otherwise. | |||
This restriction does not apply to setting dead DAV properties on | This restriction does not apply to setting dead DAV properties on | |||
the server where the server MUST record unknown XML elements. | the server where the server MUST record unknown XML elements. | |||
Additionally, this restriction does not apply to the use of XML | Additionally, this restriction does not apply to the use of XML | |||
where XML happens to be the content type of the entity body, for | where XML happens to be the content type of the entity body, for | |||
example, when used as the body of a PUT. | example, when used as the body of a PUT. | |||
Since XML can be transported as text/xml or application/xml, a DAV | ||||
server MUST accept DAV method requests with XML parameters | ||||
transported as either text/xml or application/xml, and DAV client | ||||
MUST accept XML responses using either text/xml or application/xml. | ||||
15 DAV Compliance Classes | 15 DAV Compliance Classes | |||
A DAV compliant resource can choose from two classes of compliance. | A DAV compliant resource can choose from two classes of compliance. | |||
A client can discover the compliance classes of a resource by | A client can discover the compliance classes of a resource by | |||
executing OPTIONS on the resource, and examining the "DAV" header | executing OPTIONS on the resource, and examining the "DAV" header | |||
which is returned. | which is returned. | |||
Since this document describes extensions to the HTTP/1.1 protocol, | Since this document describes extensions to the HTTP/1.1 protocol, | |||
minimally all DAV compliant resources, clients, and proxies MUST be | minimally all DAV compliant resources, clients, and proxies MUST be | |||
compliant with [RFC2068]. | compliant with [RFC2068]. | |||
skipping to change at page 76, line 55 | skipping to change at page 76, line 55 | |||
information via properties, servers are encouraged to develop access | information via properties, servers are encouraged to develop access | |||
control mechanisms that separate read access to the resource body | control mechanisms that separate read access to the resource body | |||
and read access to the resource's properties. This allows a user to | and read access to the resource's properties. This allows a user to | |||
control the dissemination of their property data without overly | control the dissemination of their property data without overly | |||
restricting access to the resource's contents. | restricting access to the resource's contents. | |||
17.6 Reduction of Security due to Source Link | 17.6 Reduction of Security due to Source Link | |||
HTTP/1.1 warns against providing read access to script code because | HTTP/1.1 warns against providing read access to script code because | |||
it may contain sensitive information. Yet WebDAV, via its source | it may contain sensitive information. Yet WebDAV, via its source | |||
link facility, can potentially provide a URL for script resources so | link facility, can potentially provide a URI for script resources so | |||
they may be authored. For HTTP/1.1, a server could reasonably | they may be authored. For HTTP/1.1, a server could reasonably | |||
prevent access to source resources due to the predominance of read- | prevent access to source resources due to the predominance of read- | |||
only access. WebDAV, with its emphasis on authoring, encourages | only access. WebDAV, with its emphasis on authoring, encourages | |||
read and write access to source resources, and provides the source | read and write access to source resources, and provides the source | |||
link facility to identify the source. This reduces the security | link facility to identify the source. This reduces the security | |||
benefits of eliminating access to source resources. Users and | benefits of eliminating access to source resources. Users and | |||
administrators of WebDAV servers should be very cautious when | administrators of WebDAV servers should be very cautious when | |||
allowing remote authoring of scripts, limiting read and write access | allowing remote authoring of scripts, limiting read and write access | |||
to the source resources to authorized principals. | to the source resources to authorized principals. | |||
skipping to change at page 77, line 45 | skipping to change at page 77, line 45 | |||
There is also the scalability risk that would accompany a widely | There is also the scalability risk that would accompany a widely | |||
deployed application which made use of external XML entities. In | deployed application which made use of external XML entities. In | |||
this situation, it is possible that there would be significant | this situation, it is possible that there would be significant | |||
numbers of requests for one external XML entity, potentially | numbers of requests for one external XML entity, potentially | |||
overloading any server which fields requests for the resource | overloading any server which fields requests for the resource | |||
containing the external XML entity. | containing the external XML entity. | |||
17.8 Risks Connected with Lock Tokens | 17.8 Risks Connected with Lock Tokens | |||
This specification, in section 6.4, requires the use of Globally | This specification, in section 6.4, requires the use of Universal | |||
Unique Identifiers (GUIDs) for lock tokens, in order to guarantee | Unique Identifiers (UUIDs) for lock tokens, in order to guarantee | |||
their uniqueness across space and time. GUIDs, as defined in [ISO- | their uniqueness across space and time. UUIDs, as defined in [ISO- | |||
11578], contain a "node" field which "consists of the IEEE address, | 11578], contain a "node" field which "consists of the IEEE address, | |||
usually the host address. For systems with multiple IEEE 802 nodes, | usually the host address. For systems with multiple IEEE 802 nodes, | |||
any available node address can be used." Since a WebDAV server will | any available node address can be used." Since a WebDAV server will | |||
issue many locks over its lifetime, the implication is that it will | issue many locks over its lifetime, the implication is that it will | |||
also be publicly exposing its IEEE 802 address. | also be publicly exposing its IEEE 802 address. | |||
There are several risks associated with exposure of IEEE 802 | There are several risks associated with exposure of IEEE 802 | |||
addresses. Using the IEEE 802 address: | addresses. Using the IEEE 802 address: | |||
* It is possible to track the movement of hardware from subnet to | * It is possible to track the movement of hardware from subnet to | |||
skipping to change at page 78, line 13 | skipping to change at page 78, line 13 | |||
addresses. Using the IEEE 802 address: | addresses. Using the IEEE 802 address: | |||
* It is possible to track the movement of hardware from subnet to | * It is possible to track the movement of hardware from subnet to | |||
subnet. | subnet. | |||
* It may be possible to identify the manufacturer of the hardware | * It may be possible to identify the manufacturer of the hardware | |||
running a WebDAV server. | running a WebDAV server. | |||
* It may be possible to determine the number of each type of | * It may be possible to determine the number of each type of | |||
computer running WebDAV. | computer running WebDAV. | |||
Section 6.4.1 of this specification details an alternate mechanism | Section 6.4.1 of this specification details an alternate mechanism | |||
for generating the "node" field of a GUID without using an IEEE 802 | for generating the "node" field of a UUID without using an IEEE 802 | |||
address, which alleviates the risks associated with exposure of IEEE | address, which alleviates the risks associated with exposure of IEEE | |||
802 addresses by using an alternate source of uniqueness. | 802 addresses by using an alternate source of uniqueness. | |||
18 IANA Considerations | 18 IANA Considerations | |||
This document defines two namespaces, the namespace of property | This document defines two namespaces, the namespace of property | |||
names, and the namespace of WebDAV-specific XML elements used within | names, and the namespace of WebDAV-specific XML elements used within | |||
property values. | property values. | |||
URLs are used for both names, for several reasons. Assignment of a | URIs are used for both names, for several reasons. Assignment of a | |||
URL does not require a request to a central naming authority, and | URI does not require a request to a central naming authority, and | |||
hence allow WebDAV property names and XML elements to be quickly | hence allow WebDAV property names and XML elements to be quickly | |||
defined by any WebDAV user or application. URLs also provide a | defined by any WebDAV user or application. URIs also provide a | |||
unique address space, ensuring that the distributed users of WebDAV | unique address space, ensuring that the distributed users of WebDAV | |||
will not have collisions among the property names and XML elements | will not have collisions among the property names and XML elements | |||
they create. | they create. | |||
This specification defines a distinguished set of property names and | This specification defines a distinguished set of property names and | |||
XML elements that are understood by all WebDAV applications. The | XML elements that are understood by all WebDAV applications. The | |||
property names and XML elements in this specification are all | property names and XML elements in this specification are all | |||
derived from the base URI DAV: by adding a suffix to this URI, for | derived from the base URI DAV: by adding a suffix to this URI, for | |||
example, DAV:creationdate for the "creationdate" property. | example, DAV:creationdate for the "creationdate" property. | |||
skipping to change at page 80, line 20 | skipping to change at page 80, line 20 | |||
valuable at every stage of our work. | valuable at every stage of our work. | |||
Terry Allen, Harald Alvestrand, Jim Amsden, Becky Anderson, Alan | Terry Allen, Harald Alvestrand, Jim Amsden, Becky Anderson, Alan | |||
Babich, Sanford Barr, Dylan Barrell, Bernard Chester, Tim Berners- | Babich, Sanford Barr, Dylan Barrell, Bernard Chester, Tim Berners- | |||
Lee, Dan Connolly, Jim Cunningham, Ron Daniel, Jr., Jim Davis, Keith | Lee, Dan Connolly, Jim Cunningham, Ron Daniel, Jr., Jim Davis, Keith | |||
Dawson, Mark Day, Brian Deen, Martin Duerst, David Durand, Lee | Dawson, Mark Day, Brian Deen, Martin Duerst, David Durand, Lee | |||
Farrell, Chuck Fay, Wesley Felter, Roy Fielding, Mark Fisher, Alan | Farrell, Chuck Fay, Wesley Felter, Roy Fielding, Mark Fisher, Alan | |||
Freier, George Florentine, Jim Gettys, Phill Hallam-Baker, Dennis | Freier, George Florentine, Jim Gettys, Phill Hallam-Baker, Dennis | |||
Hamilton, Steve Henning, Mead Himelstein, Alex Hopmann, Andre van | Hamilton, Steve Henning, Mead Himelstein, Alex Hopmann, Andre van | |||
der Hoek, Ben Laurie, Paul Leach, Ora Lassila, Karen MacArthur, | der Hoek, Ben Laurie, Paul Leach, Ora Lassila, Karen MacArthur, | |||
Steven Martin, Larry Masinter, Michael Mealling, Keith Moore, Henrik | Steven Martin, Larry Masinter, Michael Mealling, Keith Moore, Thomas | |||
Nielsen, Kenji Ota, Bob Parker, Glenn Peterson, Jon Radoff, Saveen | Narten, Henrik Nielsen, Kenji Ota, Bob Parker, Glenn Peterson, Jon | |||
Reddy, Henry Sanders, Christopher Seiwald, Judith Slein, Mike | Radoff, Saveen Reddy, Henry Sanders, Christopher Seiwald, Judith | |||
Spreitzer, Einar Stefferud, Greg Stein, Ralph Swick, Kenji | Slein, Mike Spreitzer, Einar Stefferud, Greg Stein, Ralph Swick, | |||
Takahashi, Richard N. Taylor, Robert Thau, John Turner, Sankar | Kenji Takahashi, Richard N. Taylor, Robert Thau, John Turner, Sankar | |||
Virdhagriswaran, Fabio Vitali, Gregory Woodhouse, and Lauren Wood. | Virdhagriswaran, Fabio Vitali, Gregory Woodhouse, and Lauren Wood. | |||
Two from this list deserve special mention. The contributions by | Two from this list deserve special mention. The contributions by | |||
Larry Masinter have been invaluable, both in helping the formation | Larry Masinter have been invaluable, both in helping the formation | |||
of the working group and in patiently coaching the authors along the | of the working group and in patiently coaching the authors along the | |||
way. In so many ways he has set high standards we have toiled to | way. In so many ways he has set high standards we have toiled to | |||
meet. The contributions of Judith Slein in clarifying the | meet. The contributions of Judith Slein in clarifying the | |||
requirements, and in patiently reviewing draft after draft, both | requirements, and in patiently reviewing draft after draft, both | |||
improved this specification and expanded our minds on document | improved this specification and expanded our minds on document | |||
management. | management. | |||
skipping to change at page 81, line 52 | skipping to change at page 81, line 52 | |||
[ISO-8601] ISO (International Organization for Standardization). ISO | [ISO-8601] ISO (International Organization for Standardization). ISO | |||
8601:1988. "Data elements and interchange formats - | 8601:1988. "Data elements and interchange formats - | |||
Information interchange - Representation of dates and | Information interchange - Representation of dates and | |||
times." | times." | |||
[ISO-11578] ISO (International Organization for Standardization). | [ISO-11578] ISO (International Organization for Standardization). | |||
ISO/IEC 11578:1996. "Information technology - Open Systems | ISO/IEC 11578:1996. "Information technology - Open Systems | |||
Interconnection - Remote Procedure Call (RPC)" | Interconnection - Remote Procedure Call (RPC)" | |||
[RFC2141] R. Moats, "URN Syntax." RFC 2141. AT&T. May, 1997. | ||||
[UTF-8] F. Yergeau, "UTF-8, a transformation format of Unicode and | [UTF-8] F. Yergeau, "UTF-8, a transformation format of Unicode and | |||
ISO 10646." RFC 2279. Alis Technologies. January, 1998. | ISO 10646." RFC 2279. Alis Technologies. January, 1998. | |||
22.2 Informational References | 22.2 Informational References | |||
[RFC2026] S. Bradner, "The Internet Standards Process - Revision 3." | [RFC2026] S. Bradner, "The Internet Standards Process - Revision 3." | |||
RFC 2026, BCP 9. Harvard University. October, 1996. | RFC 2026, BCP 9. Harvard University. October, 1996. | |||
[WD-XML-NAMES] T. Bray, D. Hollander, A. Layman, "Name Spaces in | [WD-XML-NAMES] T. Bray, D. Hollander, A. Layman, "Name Spaces in | |||
XML" World Wide Web Consortium Working Draft, | XML" World Wide Web Consortium Working Draft, | |||
http://www.w3.org/TR/WD-xml-names. | http://www.w3.org/TR/WD-xml-names. | |||
[RFC1807] R. Lasher, D. Cohen, "A Format for Bibliographic Records," | [RFC1807] R. Lasher, D. Cohen, "A Format for Bibliographic Records," | |||
RFC 1807. Stanford, Myricom. June, 1995. | RFC 1807. Stanford, Myricom. June, 1995. | |||
[WF] C. Lagoze, "The Warwick Framework: A Container | ||||
Architecture for Diverse Sets of Metadata", D-Lib | ||||
Magazine, July/August 1996. | ||||
http://www.dlib.org/dlib/july96/lagoze/07lagoze.html | ||||
[USMARC] Network Development and MARC Standards, Office, ed. 1994. | [USMARC] Network Development and MARC Standards, Office, ed. 1994. | |||
"USMARC Format for Bibliographic Data", 1994. Washington, | "USMARC Format for Bibliographic Data", 1994. Washington, | |||
DC: Cataloging Distribution Service, Library of Congress. | DC: Cataloging Distribution Service, Library of Congress. | |||
[REC-PICS] J. Miller, T. Krauskopf, P. Resnick, W. Treese, "PICS | [REC-PICS] J. Miller, T. Krauskopf, P. Resnick, W. Treese, "PICS | |||
Label Distribution Label Syntax and Communication | Label Distribution Label Syntax and Communication | |||
Protocols" Version 1.1, World Wide Web Consortium | Protocols" Version 1.1, World Wide Web Consortium | |||
Recommendation REC-PICS-labels-961031. | Recommendation REC-PICS-labels-961031. | |||
http://www.w3.org/pub/WWW/TR/REC-PICS-labels-961031.html. | http://www.w3.org/pub/WWW/TR/REC-PICS-labels-961031.html. | |||
skipping to change at page 85, line 36 | skipping to change at page 85, line 35 | |||
<!ELEMENT resourcetype ANY > | <!ELEMENT resourcetype ANY > | |||
<!ELEMENT source (link)* > | <!ELEMENT source (link)* > | |||
<!ELEMENT supportedlock (lockentry)* > | <!ELEMENT supportedlock (lockentry)* > | |||
]> | ]> | |||
24.2 Appendix 2 - ISO 8601 Date and Time Profile | 24.2 Appendix 2 - ISO 8601 Date and Time Profile | |||
The creationdate property specifies the use of the ISO 8601 date | The creationdate property specifies the use of the ISO 8601 date | |||
format [ISO-8601]. This section defines a profile of the ISO 8601 | format [ISO-8601]. This section defines a profile of the ISO 8601 | |||
date format for use with this specification. This profile is quoted | date format for use with this specification. This profile is quoted | |||
verbatim from draft-newman-datetime-01.txt (expired). | from an Internet-Draft by Chris Newman, and is mentioned here to | |||
properly attribute his work. | ||||
date-time = full-date "T" full-time | date-time = full-date "T" full-time | |||
full-date = date-fullyear "-" date-month "-" date-mday | full-date = date-fullyear "-" date-month "-" date-mday | |||
full-time = partial-time time-offset | full-time = partial-time time-offset | |||
date-fullyear = 4DIGIT | date-fullyear = 4DIGIT | |||
date-month = 2DIGIT ; 01-12 | date-month = 2DIGIT ; 01-12 | |||
date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on | date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on | |||
month/year | month/year | |||
End of changes. | ||||
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |