mirror of
https://git.friendi.ca/friendica/friendica-addons.git
synced 2024-08-19 08:50:51 +00:00
5268 lines
198 KiB
Text
5268 lines
198 KiB
Text
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Network Working Group Y. Goland
|
|||
|
Request for Comments: 2518 Microsoft
|
|||
|
Category: Standards Track E. Whitehead
|
|||
|
UC Irvine
|
|||
|
A. Faizi
|
|||
|
Netscape
|
|||
|
S. Carter
|
|||
|
Novell
|
|||
|
D. Jensen
|
|||
|
Novell
|
|||
|
February 1999
|
|||
|
|
|||
|
|
|||
|
HTTP Extensions for Distributed Authoring -- WEBDAV
|
|||
|
|
|||
|
Status of this Memo
|
|||
|
|
|||
|
This document specifies an Internet standards track protocol for the
|
|||
|
Internet community, and requests discussion and suggestions for
|
|||
|
improvements. Please refer to the current edition of the "Internet
|
|||
|
Official Protocol Standards" (STD 1) for the standardization state
|
|||
|
and status of this protocol. Distribution of this memo is unlimited.
|
|||
|
|
|||
|
Copyright Notice
|
|||
|
|
|||
|
Copyright (C) The Internet Society (1999). All Rights Reserved.
|
|||
|
|
|||
|
Abstract
|
|||
|
|
|||
|
This document specifies a set of methods, headers, and content-types
|
|||
|
ancillary to HTTP/1.1 for the management of resource properties,
|
|||
|
creation and management of resource collections, namespace
|
|||
|
manipulation, and resource locking (collision avoidance).
|
|||
|
|
|||
|
Table of Contents
|
|||
|
|
|||
|
ABSTRACT............................................................1
|
|||
|
1 INTRODUCTION .....................................................5
|
|||
|
2 NOTATIONAL CONVENTIONS ...........................................7
|
|||
|
3 TERMINOLOGY ......................................................7
|
|||
|
4 DATA MODEL FOR RESOURCE PROPERTIES ...............................8
|
|||
|
4.1 The Resource Property Model ...................................8
|
|||
|
4.2 Existing Metadata Proposals ...................................8
|
|||
|
4.3 Properties and HTTP Headers ...................................9
|
|||
|
4.4 Property Values ...............................................9
|
|||
|
4.5 Property Names ...............................................10
|
|||
|
4.6 Media Independent Links ......................................10
|
|||
|
5 COLLECTIONS OF WEB RESOURCES ....................................11
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 1]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
5.1 HTTP URL Namespace Model .....................................11
|
|||
|
5.2 Collection Resources .........................................11
|
|||
|
5.3 Creation and Retrieval of Collection Resources ...............12
|
|||
|
5.4 Source Resources and Output Resources ........................13
|
|||
|
6 LOCKING .........................................................14
|
|||
|
6.1 Exclusive Vs. Shared Locks ...................................14
|
|||
|
6.2 Required Support .............................................16
|
|||
|
6.3 Lock Tokens ..................................................16
|
|||
|
6.4 opaquelocktoken Lock Token URI Scheme ........................16
|
|||
|
6.4.1 Node Field Generation Without the IEEE 802 Address ........17
|
|||
|
6.5 Lock Capability Discovery ....................................19
|
|||
|
6.6 Active Lock Discovery ........................................19
|
|||
|
6.7 Usage Considerations .........................................19
|
|||
|
7 WRITE LOCK ......................................................20
|
|||
|
7.1 Methods Restricted by Write Locks ............................20
|
|||
|
7.2 Write Locks and Lock Tokens ..................................20
|
|||
|
7.3 Write Locks and Properties ...................................20
|
|||
|
7.4 Write Locks and Null Resources ...............................21
|
|||
|
7.5 Write Locks and Collections ..................................21
|
|||
|
7.6 Write Locks and the If Request Header ........................22
|
|||
|
7.6.1 Example - Write Lock ......................................22
|
|||
|
7.7 Write Locks and COPY/MOVE ....................................23
|
|||
|
7.8 Refreshing Write Locks .......................................23
|
|||
|
8 HTTP METHODS FOR DISTRIBUTED AUTHORING ..........................23
|
|||
|
8.1 PROPFIND .....................................................24
|
|||
|
8.1.1 Example - Retrieving Named Properties .....................25
|
|||
|
8.1.2 Example - Using allprop to Retrieve All Properties ........26
|
|||
|
8.1.3 Example - Using propname to Retrieve all Property Names ...29
|
|||
|
8.2 PROPPATCH ....................................................31
|
|||
|
8.2.1 Status Codes for use with 207 (Multi-Status) ..............31
|
|||
|
8.2.2 Example - PROPPATCH .......................................32
|
|||
|
8.3 MKCOL Method .................................................33
|
|||
|
8.3.1 Request ...................................................33
|
|||
|
8.3.2 Status Codes ..............................................33
|
|||
|
8.3.3 Example - MKCOL ...........................................34
|
|||
|
8.4 GET, HEAD for Collections ....................................34
|
|||
|
8.5 POST for Collections .........................................35
|
|||
|
8.6 DELETE .......................................................35
|
|||
|
8.6.1 DELETE for Non-Collection Resources .......................35
|
|||
|
8.6.2 DELETE for Collections ....................................36
|
|||
|
8.7 PUT ..........................................................36
|
|||
|
8.7.1 PUT for Non-Collection Resources ..........................36
|
|||
|
8.7.2 PUT for Collections .......................................37
|
|||
|
8.8 COPY Method ..................................................37
|
|||
|
8.8.1 COPY for HTTP/1.1 resources ...............................37
|
|||
|
8.8.2 COPY for Properties .......................................38
|
|||
|
8.8.3 COPY for Collections ......................................38
|
|||
|
8.8.4 COPY and the Overwrite Header .............................39
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 2]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
8.8.5 Status Codes ..............................................39
|
|||
|
8.8.6 Example - COPY with Overwrite .............................40
|
|||
|
8.8.7 Example - COPY with No Overwrite ..........................40
|
|||
|
8.8.8 Example - COPY of a Collection ............................41
|
|||
|
8.9 MOVE Method ..................................................42
|
|||
|
8.9.1 MOVE for Properties .......................................42
|
|||
|
8.9.2 MOVE for Collections ......................................42
|
|||
|
8.9.3 MOVE and the Overwrite Header .............................43
|
|||
|
8.9.4 Status Codes ..............................................43
|
|||
|
8.9.5 Example - MOVE of a Non-Collection ........................44
|
|||
|
8.9.6 Example - MOVE of a Collection ............................44
|
|||
|
8.10 LOCK Method ..................................................45
|
|||
|
8.10.1 Operation .................................................46
|
|||
|
8.10.2 The Effect of Locks on Properties and Collections .........46
|
|||
|
8.10.3 Locking Replicated Resources ..............................46
|
|||
|
8.10.4 Depth and Locking .........................................46
|
|||
|
8.10.5 Interaction with other Methods ............................47
|
|||
|
8.10.6 Lock Compatibility Table ..................................47
|
|||
|
8.10.7 Status Codes ..............................................48
|
|||
|
8.10.8 Example - Simple Lock Request .............................48
|
|||
|
8.10.9 Example - Refreshing a Write Lock .........................49
|
|||
|
8.10.10 Example - Multi-Resource Lock Request ....................50
|
|||
|
8.11 UNLOCK Method ................................................51
|
|||
|
8.11.1 Example - UNLOCK ..........................................52
|
|||
|
9 HTTP HEADERS FOR DISTRIBUTED AUTHORING ..........................52
|
|||
|
9.1 DAV Header ...................................................52
|
|||
|
9.2 Depth Header .................................................52
|
|||
|
9.3 Destination Header ...........................................54
|
|||
|
9.4 If Header ....................................................54
|
|||
|
9.4.1 No-tag-list Production ....................................55
|
|||
|
9.4.2 Tagged-list Production ....................................55
|
|||
|
9.4.3 not Production ............................................56
|
|||
|
9.4.4 Matching Function .........................................56
|
|||
|
9.4.5 If Header and Non-DAV Compliant Proxies ...................57
|
|||
|
9.5 Lock-Token Header ............................................57
|
|||
|
9.6 Overwrite Header .............................................57
|
|||
|
9.7 Status-URI Response Header ...................................57
|
|||
|
9.8 Timeout Request Header .......................................58
|
|||
|
10 STATUS CODE EXTENSIONS TO HTTP/1.1 ............................59
|
|||
|
10.1 102 Processing ...............................................59
|
|||
|
10.2 207 Multi-Status .............................................59
|
|||
|
10.3 422 Unprocessable Entity .....................................60
|
|||
|
10.4 423 Locked ...................................................60
|
|||
|
10.5 424 Failed Dependency ........................................60
|
|||
|
10.6 507 Insufficient Storage .....................................60
|
|||
|
11 MULTI-STATUS RESPONSE .........................................60
|
|||
|
12 XML ELEMENT DEFINITIONS .......................................61
|
|||
|
12.1 activelock XML Element .......................................61
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 3]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
12.1.1 depth XML Element .........................................61
|
|||
|
12.1.2 locktoken XML Element .....................................61
|
|||
|
12.1.3 timeout XML Element .......................................61
|
|||
|
12.2 collection XML Element .......................................62
|
|||
|
12.3 href XML Element .............................................62
|
|||
|
12.4 link XML Element .............................................62
|
|||
|
12.4.1 dst XML Element ...........................................62
|
|||
|
12.4.2 src XML Element ...........................................62
|
|||
|
12.5 lockentry XML Element ........................................63
|
|||
|
12.6 lockinfo XML Element .........................................63
|
|||
|
12.7 lockscope XML Element ........................................63
|
|||
|
12.7.1 exclusive XML Element .....................................63
|
|||
|
12.7.2 shared XML Element ........................................63
|
|||
|
12.8 locktype XML Element .........................................64
|
|||
|
12.8.1 write XML Element .........................................64
|
|||
|
12.9 multistatus XML Element ......................................64
|
|||
|
12.9.1 response XML Element ......................................64
|
|||
|
12.9.2 responsedescription XML Element ...........................65
|
|||
|
12.10 owner XML Element ...........................................65
|
|||
|
12.11 prop XML element ............................................66
|
|||
|
12.12 propertybehavior XML element ................................66
|
|||
|
12.12.1 keepalive XML element ....................................66
|
|||
|
12.12.2 omit XML element .........................................67
|
|||
|
12.13 propertyupdate XML element ..................................67
|
|||
|
12.13.1 remove XML element .......................................67
|
|||
|
12.13.2 set XML element ..........................................67
|
|||
|
12.14 propfind XML Element ........................................68
|
|||
|
12.14.1 allprop XML Element ......................................68
|
|||
|
12.14.2 propname XML Element .....................................68
|
|||
|
13 DAV PROPERTIES ................................................68
|
|||
|
13.1 creationdate Property ........................................69
|
|||
|
13.2 displayname Property .........................................69
|
|||
|
13.3 getcontentlanguage Property ..................................69
|
|||
|
13.4 getcontentlength Property ....................................69
|
|||
|
13.5 getcontenttype Property ......................................70
|
|||
|
13.6 getetag Property .............................................70
|
|||
|
13.7 getlastmodified Property .....................................70
|
|||
|
13.8 lockdiscovery Property .......................................71
|
|||
|
13.8.1 Example - Retrieving the lockdiscovery Property ...........71
|
|||
|
13.9 resourcetype Property ........................................72
|
|||
|
13.10 source Property .............................................72
|
|||
|
13.10.1 Example - A source Property ..............................72
|
|||
|
13.11 supportedlock Property ......................................73
|
|||
|
13.11.1 Example - Retrieving the supportedlock Property ..........73
|
|||
|
14 INSTRUCTIONS FOR PROCESSING XML IN DAV ........................74
|
|||
|
15 DAV COMPLIANCE CLASSES ........................................75
|
|||
|
15.1 Class 1 ......................................................75
|
|||
|
15.2 Class 2 ......................................................75
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 4]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
16 INTERNATIONALIZATION CONSIDERATIONS ...........................76
|
|||
|
17 SECURITY CONSIDERATIONS .......................................77
|
|||
|
17.1 Authentication of Clients ....................................77
|
|||
|
17.2 Denial of Service ............................................78
|
|||
|
17.3 Security through Obscurity ...................................78
|
|||
|
17.4 Privacy Issues Connected to Locks ............................78
|
|||
|
17.5 Privacy Issues Connected to Properties .......................79
|
|||
|
17.6 Reduction of Security due to Source Link .....................79
|
|||
|
17.7 Implications of XML External Entities ........................79
|
|||
|
17.8 Risks Connected with Lock Tokens .............................80
|
|||
|
18 IANA CONSIDERATIONS ...........................................80
|
|||
|
19 INTELLECTUAL PROPERTY .........................................81
|
|||
|
20 ACKNOWLEDGEMENTS ..............................................82
|
|||
|
21 REFERENCES ....................................................82
|
|||
|
21.1 Normative References .........................................82
|
|||
|
21.2 Informational References .....................................83
|
|||
|
22 AUTHORS' ADDRESSES ............................................84
|
|||
|
23 APPENDICES ....................................................86
|
|||
|
23.1 Appendix 1 - WebDAV Document Type Definition .................86
|
|||
|
23.2 Appendix 2 - ISO 8601 Date and Time Profile ..................88
|
|||
|
23.3 Appendix 3 - Notes on Processing XML Elements ................89
|
|||
|
23.3.1 Notes on Empty XML Elements ...............................89
|
|||
|
23.3.2 Notes on Illegal XML Processing ...........................89
|
|||
|
23.4 Appendix 4 -- XML Namespaces for WebDAV ......................92
|
|||
|
23.4.1 Introduction ..............................................92
|
|||
|
23.4.2 Meaning of Qualified Names ................................92
|
|||
|
24 FULL COPYRIGHT STATEMENT ......................................94
|
|||
|
|
|||
|
|
|||
|
|
|||
|
1 Introduction
|
|||
|
|
|||
|
This document describes an extension to the HTTP/1.1 protocol that
|
|||
|
allows clients to perform remote web content authoring operations.
|
|||
|
This extension provides a coherent set of methods, headers, request
|
|||
|
entity body formats, and response entity body formats that provide
|
|||
|
operations for:
|
|||
|
|
|||
|
Properties: The ability to create, remove, and query information
|
|||
|
about Web pages, such as their authors, creation dates, etc. Also,
|
|||
|
the ability to link pages of any media type to related pages.
|
|||
|
|
|||
|
Collections: The ability to create sets of documents and to retrieve
|
|||
|
a hierarchical membership listing (like a directory listing in a file
|
|||
|
system).
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 5]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
Locking: The ability to keep more than one person from working on a
|
|||
|
document at the same time. This prevents the "lost update problem,"
|
|||
|
in which modifications are lost as first one author then another
|
|||
|
writes changes without merging the other author's changes.
|
|||
|
|
|||
|
Namespace Operations: The ability to instruct the server to copy and
|
|||
|
move Web resources.
|
|||
|
|
|||
|
Requirements and rationale for these operations are described in a
|
|||
|
companion document, "Requirements for a Distributed Authoring and
|
|||
|
Versioning Protocol for the World Wide Web" [RFC2291].
|
|||
|
|
|||
|
The sections below provide a detailed introduction to resource
|
|||
|
properties (section 4), collections of resources (section 5), and
|
|||
|
locking operations (section 6). These sections introduce the
|
|||
|
abstractions manipulated by the WebDAV-specific HTTP methods
|
|||
|
described in section 8, "HTTP Methods for Distributed Authoring".
|
|||
|
|
|||
|
In HTTP/1.1, method parameter information was exclusively encoded in
|
|||
|
HTTP headers. Unlike HTTP/1.1, WebDAV encodes method parameter
|
|||
|
information either in an Extensible Markup Language (XML) [REC-XML]
|
|||
|
request entity body, or in an HTTP header. The use of XML to encode
|
|||
|
method parameters was motivated by the ability to add extra XML
|
|||
|
elements to existing structures, providing extensibility; and by
|
|||
|
XML's ability to encode information in ISO 10646 character sets,
|
|||
|
providing internationalization support. As a rule of thumb,
|
|||
|
parameters are encoded in XML entity bodies when they have unbounded
|
|||
|
length, or when they may be shown to a human user and hence require
|
|||
|
encoding in an ISO 10646 character set. Otherwise, parameters are
|
|||
|
encoded within HTTP headers. Section 9 describes the new HTTP
|
|||
|
headers used with WebDAV methods.
|
|||
|
|
|||
|
In addition to encoding method parameters, XML is used in WebDAV to
|
|||
|
encode the responses from methods, providing the extensibility and
|
|||
|
internationalization advantages of XML for method output, as well as
|
|||
|
input.
|
|||
|
|
|||
|
XML elements used in this specification are defined in section 12.
|
|||
|
|
|||
|
The XML namespace extension (Appendix 4) is also used in this
|
|||
|
specification in order to allow for new XML elements to be added
|
|||
|
without fear of colliding with other element names.
|
|||
|
|
|||
|
While the status codes provided by HTTP/1.1 are sufficient to
|
|||
|
describe most error conditions encountered by WebDAV methods, there
|
|||
|
are some errors that do not fall neatly into the existing categories.
|
|||
|
New status codes developed for the WebDAV methods are defined in
|
|||
|
section 10. Since some WebDAV methods may operate over many
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 6]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
resources, the Multi-Status response has been introduced to return
|
|||
|
status information for multiple resources. The Multi-Status response
|
|||
|
is described in section 11.
|
|||
|
|
|||
|
WebDAV employs the property mechanism to store information about the
|
|||
|
current state of the resource. For example, when a lock is taken out
|
|||
|
on a resource, a lock information property describes the current
|
|||
|
state of the lock. Section 13 defines the properties used within the
|
|||
|
WebDAV specification.
|
|||
|
|
|||
|
Finishing off the specification are sections on what it means to be
|
|||
|
compliant with this specification (section 15), on
|
|||
|
internationalization support (section 16), and on security (section
|
|||
|
17).
|
|||
|
|
|||
|
2 Notational Conventions
|
|||
|
|
|||
|
Since this document describes a set of extensions to the HTTP/1.1
|
|||
|
protocol, the augmented BNF used herein to describe protocol elements
|
|||
|
is exactly the same as described in section 2.1 of [RFC2068]. Since
|
|||
|
this augmented BNF uses the basic production rules provided in
|
|||
|
section 2.2 of [RFC2068], these rules apply to this document as well.
|
|||
|
|
|||
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|||
|
"SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|||
|
document are to be interpreted as described in RFC 2119 [RFC2119].
|
|||
|
|
|||
|
3 Terminology
|
|||
|
|
|||
|
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 a set of URIs, termed member
|
|||
|
URIs, which identify member resources and meets the requirements in
|
|||
|
section 5 of this specification.
|
|||
|
|
|||
|
Member URI - A URI which is a member of the set of URIs contained by
|
|||
|
a collection.
|
|||
|
|
|||
|
Internal Member URI - A Member URI that is immediately relative to
|
|||
|
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
|
|||
|
about a resource.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 7]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
Live Property - A property whose semantics and syntax are enforced by
|
|||
|
the server. For example, the live "getcontentlength" property has
|
|||
|
its value, the length of the entity returned by a GET request,
|
|||
|
automatically calculated by the server.
|
|||
|
|
|||
|
Dead Property - A property whose semantics and syntax are not
|
|||
|
enforced by the server. The server only records the value of a dead
|
|||
|
property; the client is responsible for maintaining the consistency
|
|||
|
of the syntax and semantics of a dead property.
|
|||
|
|
|||
|
Null Resource - A resource which responds with a 404 (Not Found) to
|
|||
|
any HTTP/1.1 or DAV method except for PUT, MKCOL, OPTIONS and LOCK.
|
|||
|
A NULL resource MUST NOT appear as a member of its parent collection.
|
|||
|
|
|||
|
4 Data Model for Resource Properties
|
|||
|
|
|||
|
4.1 The Resource Property Model
|
|||
|
|
|||
|
Properties are pieces of data that describe the state of a resource.
|
|||
|
Properties are data about data.
|
|||
|
|
|||
|
Properties are used in distributed authoring environments to provide
|
|||
|
for efficient discovery and management of resources. For example, a
|
|||
|
'subject' property might allow for the indexing of all resources by
|
|||
|
their subject, and an 'author' property might allow for the discovery
|
|||
|
of what authors have written which documents.
|
|||
|
|
|||
|
The DAV property model consists of name/value pairs. The name of a
|
|||
|
property identifies the property's syntax and semantics, and provides
|
|||
|
an address by which to refer to its syntax and semantics.
|
|||
|
|
|||
|
There are two categories of properties: "live" and "dead". A live
|
|||
|
property has its syntax and semantics enforced by the server. Live
|
|||
|
properties include cases where a) the value of a property is read-
|
|||
|
only, maintained by the server, and b) the value of the property is
|
|||
|
maintained by the client, but the server performs syntax checking on
|
|||
|
submitted values. All instances of a given live property MUST comply
|
|||
|
with the definition associated with that property name. A dead
|
|||
|
property has its syntax and semantics enforced by the client; the
|
|||
|
server merely records the value of the property verbatim.
|
|||
|
|
|||
|
4.2 Existing Metadata Proposals
|
|||
|
|
|||
|
Properties have long played an essential role in the maintenance of
|
|||
|
large document repositories, and many current proposals contain some
|
|||
|
notion of a property, or discuss web metadata more generally. These
|
|||
|
include PICS [REC-PICS], PICS-NG, XML, Web Collections, and several
|
|||
|
proposals on representing relationships within HTML. Work on PICS-NG
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 8]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
and Web Collections has been subsumed by the Resource Description
|
|||
|
Framework (RDF) metadata activity of the World Wide Web Consortium.
|
|||
|
RDF consists of a network-based data model and an XML representation
|
|||
|
of that model.
|
|||
|
|
|||
|
Some proposals come from a digital library perspective. These
|
|||
|
include the Dublin Core [RFC2413] metadata set and the Warwick
|
|||
|
Framework [WF], a container architecture for different metadata
|
|||
|
schemas. The literature includes many examples of metadata,
|
|||
|
including MARC [USMARC], a bibliographic metadata format, and a
|
|||
|
technical report bibliographic format employed by the Dienst system
|
|||
|
[RFC1807]. Additionally, the proceedings from the first IEEE Metadata
|
|||
|
conference describe many community-specific metadata sets.
|
|||
|
|
|||
|
Participants of the 1996 Metadata II Workshop in Warwick, UK [WF],
|
|||
|
noted that "new metadata sets will develop as the networked
|
|||
|
infrastructure matures" and "different communities will propose,
|
|||
|
design, and be responsible for different types of metadata." These
|
|||
|
observations can be corroborated by noting that many community-
|
|||
|
specific sets of metadata already exist, and there is significant
|
|||
|
motivation for the development of new forms of metadata as many
|
|||
|
communities increasingly make their data available in digital form,
|
|||
|
requiring a metadata format to assist data location and cataloging.
|
|||
|
|
|||
|
4.3 Properties and HTTP Headers
|
|||
|
|
|||
|
Properties already exist, in a limited sense, in HTTP message
|
|||
|
headers. However, in distributed authoring environments a relatively
|
|||
|
large number of properties are needed to describe the state of a
|
|||
|
resource, and setting/returning them all through HTTP headers is
|
|||
|
inefficient. Thus a mechanism is needed which allows a principal to
|
|||
|
identify a set of properties in which the principal is interested and
|
|||
|
to set or retrieve just those properties.
|
|||
|
|
|||
|
4.4 Property Values
|
|||
|
|
|||
|
The value of a property when expressed in XML MUST be well formed.
|
|||
|
|
|||
|
XML has been chosen because it is a flexible, self-describing,
|
|||
|
structured data format that supports rich schema definitions, and
|
|||
|
because of its support for multiple character sets. XML's self-
|
|||
|
describing nature allows any property's value to be extended by
|
|||
|
adding new elements. Older clients will not break when they
|
|||
|
encounter extensions because they will still have the data specified
|
|||
|
in the original schema and will ignore elements they do not
|
|||
|
understand. XML's support for multiple character sets allows any
|
|||
|
human-readable property to be encoded and read in a character set
|
|||
|
familiar to the user. XML's support for multiple human languages,
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 9]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
using the "xml:lang" attribute, handles cases where the same
|
|||
|
character set is employed by multiple human languages.
|
|||
|
|
|||
|
4.5 Property Names
|
|||
|
|
|||
|
A property name is a universally unique identifier that is associated
|
|||
|
with a schema that provides information about the syntax and
|
|||
|
semantics of the property.
|
|||
|
|
|||
|
Because a property's name is universally unique, clients can depend
|
|||
|
upon consistent behavior for a particular property across multiple
|
|||
|
resources, on the same and across different servers, so long as that
|
|||
|
property is "live" on the resources in question, and the
|
|||
|
implementation of the live property is faithful to its definition.
|
|||
|
|
|||
|
The XML namespace mechanism, which is based on URIs [RFC2396], is
|
|||
|
used to name properties because it prevents namespace collisions and
|
|||
|
provides for varying degrees of administrative control.
|
|||
|
|
|||
|
The property namespace is flat; that is, no hierarchy of properties
|
|||
|
is explicitly recognized. Thus, if a property A and a property A/B
|
|||
|
exist on a resource, there is no recognition of any relationship
|
|||
|
between the two properties. It is expected that a separate
|
|||
|
specification will eventually be produced which will address issues
|
|||
|
relating to hierarchical properties.
|
|||
|
|
|||
|
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
|
|||
|
property namespace.
|
|||
|
|
|||
|
4.6 Media Independent Links
|
|||
|
|
|||
|
Although HTML resources support links to other resources, the Web
|
|||
|
needs more general support for links between resources of any media
|
|||
|
type (media types are also known as MIME types, or content types).
|
|||
|
WebDAV provides such links. A WebDAV link is a special type of
|
|||
|
property value, formally defined in section 12.4, that allows typed
|
|||
|
connections to be established between resources of any media type.
|
|||
|
The property value consists of source and destination Uniform
|
|||
|
Resource Identifiers (URIs); the property name identifies the link
|
|||
|
type.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 10]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
5 Collections of Web Resources
|
|||
|
|
|||
|
This section provides a description of a new type of Web resource,
|
|||
|
the collection, and discusses its interactions with the HTTP URL
|
|||
|
namespace. The purpose of a collection resource is to model
|
|||
|
collection-like objects (e.g., file system directories) within a
|
|||
|
server's namespace.
|
|||
|
|
|||
|
All DAV compliant resources MUST support the HTTP URL namespace model
|
|||
|
specified herein.
|
|||
|
|
|||
|
5.1 HTTP URL Namespace Model
|
|||
|
|
|||
|
The HTTP URL namespace is a hierarchical namespace where the
|
|||
|
hierarchy is delimited with the "/" character.
|
|||
|
|
|||
|
An HTTP URL namespace is said to be consistent if it meets the
|
|||
|
following conditions: for every URL in the HTTP hierarchy there
|
|||
|
exists a collection that contains that URL as an internal member.
|
|||
|
The root, or top-level collection of the namespace under
|
|||
|
consideration is exempt from the previous rule.
|
|||
|
|
|||
|
Neither HTTP/1.1 nor WebDAV require that the entire HTTP URL
|
|||
|
namespace be consistent. However, certain WebDAV methods are
|
|||
|
prohibited from producing results that cause namespace
|
|||
|
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
|
|||
|
|
|||
|
A collection is a resource whose state consists of at least a list of
|
|||
|
internal member URIs and a set of properties, but which may have
|
|||
|
additional state such as entity bodies returned by GET. An internal
|
|||
|
member URI MUST be immediately relative to a base URI of the
|
|||
|
collection. That is, the internal member URI is equal to a
|
|||
|
containing collection's URI plus an additional segment for non-
|
|||
|
collection resources, or additional segment plus trailing slash "/"
|
|||
|
for collection resources, where segment is defined in section 3.3 of
|
|||
|
[RFC2396].
|
|||
|
|
|||
|
Any given internal member URI MUST only belong to the collection
|
|||
|
once, i.e., it is illegal to have multiple instances of the same URI
|
|||
|
in a collection. Properties defined on collections behave exactly as
|
|||
|
do properties on non-collection resources.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 11]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
For all WebDAV compliant resources A and B, identified by URIs U and
|
|||
|
V, for which U is immediately relative to V, B MUST be a collection
|
|||
|
that has U as an internal member URI. So, if the resource with URL
|
|||
|
http://foo.com/bar/blah is WebDAV compliant and if the resource with
|
|||
|
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.
|
|||
|
|
|||
|
Collection resources MAY list the URLs of non-WebDAV compliant
|
|||
|
children in the HTTP URL namespace hierarchy as internal members but
|
|||
|
are not required to do so. For example, if the resource with URL
|
|||
|
http://foo.com/bar/blah is not WebDAV compliant and the URL
|
|||
|
http://foo.com/bar/ identifies a collection then URL
|
|||
|
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
|
|||
|
the HTTP URL namespace hierarchy then the WebDAV compliant resource
|
|||
|
is not required to be a collection.
|
|||
|
|
|||
|
There is a standing convention that when a collection is referred to
|
|||
|
by its name without a trailing slash, the trailing slash is
|
|||
|
automatically appended. Due to this, a resource may accept a URI
|
|||
|
without a trailing "/" to point to a collection. In this case it
|
|||
|
SHOULD return a content-location header in the response pointing to
|
|||
|
the URI ending with the "/". For example, if a client invokes a
|
|||
|
method on http://foo.bar/blah (no trailing slash), the resource
|
|||
|
http://foo.bar/blah/ (trailing slash) may respond as if the operation
|
|||
|
were invoked on it, and should return a content-location header with
|
|||
|
http://foo.bar/blah/ in it. In general clients SHOULD use the "/"
|
|||
|
form of collection names.
|
|||
|
|
|||
|
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
|
|||
|
specification regarding how a collection is to behave without
|
|||
|
necessarily supporting all methods that a WebDAV compliant resource
|
|||
|
is required to support. In such a case the resource may return the
|
|||
|
DAV:resourcetype property with the value DAV:collection but MUST NOT
|
|||
|
return a DAV header containing the value "1" on an OPTIONS response.
|
|||
|
|
|||
|
5.3 Creation and Retrieval of Collection Resources
|
|||
|
|
|||
|
This document specifies the MKCOL method to create new collection
|
|||
|
resources, rather than using the existing HTTP/1.1 PUT or POST
|
|||
|
method, for the following reasons:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 12]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
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
|
|||
|
format for a collection can readily be constructed for use with PUT,
|
|||
|
the implications of sending such a description to the server are
|
|||
|
undesirable. For example, if a description of a collection that
|
|||
|
omitted some existing resources were PUT to a server, this might be
|
|||
|
interpreted as a command to remove those members. This would extend
|
|||
|
PUT to perform DELETE functionality, which is undesirable since it
|
|||
|
changes the semantics of PUT, and makes it difficult to control
|
|||
|
DELETE functionality with an access control scheme based on methods.
|
|||
|
|
|||
|
While the POST method is sufficiently open-ended that a "create a
|
|||
|
collection" POST command could be constructed, this is undesirable
|
|||
|
because it would be difficult to separate access control for
|
|||
|
collection creation from other uses of POST.
|
|||
|
|
|||
|
The exact definition of the behavior of GET and PUT on collections is
|
|||
|
defined later in this document.
|
|||
|
|
|||
|
5.4 Source Resources and Output Resources
|
|||
|
|
|||
|
For many resources, the entity returned by a GET method exactly
|
|||
|
matches the persistent state of the resource, for example, a GIF file
|
|||
|
stored on a disk. For this simple case, the URI at which a resource
|
|||
|
is accessed is identical to the URI at which the source (the
|
|||
|
persistent state) of the resource is accessed. This is also the case
|
|||
|
for HTML source files that are not processed by the server prior to
|
|||
|
transmission.
|
|||
|
|
|||
|
However, the server can sometimes process HTML resources before they
|
|||
|
are transmitted as a return entity body. For example, a server-
|
|||
|
side-include directive within an HTML file might instruct a server to
|
|||
|
replace the directive with another value, such as the current date.
|
|||
|
In this case, what is returned by GET (HTML plus date) differs from
|
|||
|
the persistent state of the resource (HTML plus directive).
|
|||
|
Typically there is no way to access the HTML resource containing the
|
|||
|
unprocessed directive.
|
|||
|
|
|||
|
Sometimes the entity returned by GET is the output of a data-
|
|||
|
producing process that is described by one or more source resources
|
|||
|
(that may not even have a location in the URI namespace). A single
|
|||
|
data-producing process may dynamically generate the state of a
|
|||
|
potentially large number of output resources. An example of this is
|
|||
|
a CGI script that describes a "finger" gateway process that maps part
|
|||
|
of the namespace of a server into finger requests, such as
|
|||
|
http://www.foo.bar.org/finger_gateway/user@host.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 13]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
In the absence of distributed authoring capabilities, it is
|
|||
|
acceptable to have no mapping of source resource(s) to the URI
|
|||
|
namespace. In fact, preventing access to the source resource(s) has
|
|||
|
desirable security benefits. However, if remote editing of the
|
|||
|
source resource(s) is desired, the source resource(s) should be given
|
|||
|
a location in the URI namespace. This source location should not be
|
|||
|
one of the locations at which the generated output is retrievable,
|
|||
|
since in general it is impossible for the server to differentiate
|
|||
|
requests for source resources from requests for process output
|
|||
|
resources. There is often a many-to-many relationship between source
|
|||
|
resources and output resources.
|
|||
|
|
|||
|
On WebDAV compliant servers the URI of the source resource(s) may be
|
|||
|
stored in a link on the output resource with type DAV:source (see
|
|||
|
section 13.10 for a description of the source link property).
|
|||
|
Storing the source URIs in links on the output resources places the
|
|||
|
burden of discovering the source on the authoring client. Note that
|
|||
|
the value of a source link is not guaranteed to point to the correct
|
|||
|
source. Source links may break or incorrect values may be entered.
|
|||
|
Also note that not all servers will allow the client to set the
|
|||
|
source link value. For example a server which generates source links
|
|||
|
on the fly for its CGI files will most likely not allow a client to
|
|||
|
set the source link value.
|
|||
|
|
|||
|
6 Locking
|
|||
|
|
|||
|
The ability to lock a resource provides a mechanism for serializing
|
|||
|
access to that resource. Using a lock, an authoring client can
|
|||
|
provide a reasonable guarantee that another principal will not modify
|
|||
|
a resource while it is being edited. In this way, a client can
|
|||
|
prevent the "lost update" problem.
|
|||
|
|
|||
|
This specification allows locks to vary over two client-specified
|
|||
|
parameters, the number of principals involved (exclusive vs. shared)
|
|||
|
and the type of access to be granted. This document defines locking
|
|||
|
for only one access type, write. However, the syntax is extensible,
|
|||
|
and permits the eventual specification of locking for other access
|
|||
|
types.
|
|||
|
|
|||
|
6.1 Exclusive Vs. Shared Locks
|
|||
|
|
|||
|
The most basic form of lock is an exclusive lock. This is a lock
|
|||
|
where the access right in question is only granted to a single
|
|||
|
principal. The need for this arbitration results from a desire to
|
|||
|
avoid having to merge results.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 14]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
However, there are times when the goal of a lock is not to exclude
|
|||
|
others from exercising an access right but rather to provide a
|
|||
|
mechanism for principals to indicate that they intend to exercise
|
|||
|
their access rights. Shared locks are provided for this case. A
|
|||
|
shared lock allows multiple principals to receive a lock. Hence any
|
|||
|
principal with appropriate access can get the lock.
|
|||
|
|
|||
|
With shared locks there are two trust sets that affect a resource.
|
|||
|
The first trust set is created by access permissions. Principals who
|
|||
|
are trusted, for example, may have permission to write to the
|
|||
|
resource. Among those who have access permission to write to the
|
|||
|
resource, the set of principals who have taken out a shared lock also
|
|||
|
must trust each other, creating a (typically) smaller trust set
|
|||
|
within the access permission write set.
|
|||
|
|
|||
|
Starting with every possible principal on the Internet, in most
|
|||
|
situations the vast majority of these principals will not have write
|
|||
|
access to a given resource. Of the small number who do have write
|
|||
|
access, some principals may decide to guarantee their edits are free
|
|||
|
from overwrite conflicts by using exclusive write locks. Others may
|
|||
|
decide they trust their collaborators will not overwrite their work
|
|||
|
(the potential set of collaborators being the set of principals who
|
|||
|
have write permission) and use a shared lock, which informs their
|
|||
|
collaborators that a principal may be working on the resource.
|
|||
|
|
|||
|
The WebDAV extensions to HTTP do not need to provide all of the
|
|||
|
communications paths necessary for principals to coordinate their
|
|||
|
activities. When using shared locks, principals may use any out of
|
|||
|
band communication channel to coordinate their work (e.g., face-to-
|
|||
|
face interaction, written notes, post-it notes on the screen,
|
|||
|
telephone conversation, Email, etc.) The intent of a shared lock is
|
|||
|
to let collaborators know who else may be working on a resource.
|
|||
|
|
|||
|
Shared locks are included because experience from web distributed
|
|||
|
authoring systems has indicated that exclusive locks are often too
|
|||
|
rigid. An exclusive lock is used to enforce a particular editing
|
|||
|
process: take out an exclusive lock, read the resource, perform
|
|||
|
edits, write the resource, release the lock. This editing process
|
|||
|
has the problem that locks are not always properly released, for
|
|||
|
example when a program crashes, or when a lock owner leaves without
|
|||
|
unlocking a resource. While both timeouts and administrative action
|
|||
|
can be used to remove an offending lock, neither mechanism may be
|
|||
|
available when needed; the timeout may be long or the administrator
|
|||
|
may not be available.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 15]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
6.2 Required Support
|
|||
|
|
|||
|
A WebDAV compliant server is not required to support locking in any
|
|||
|
form. If the server does support locking it may choose to support
|
|||
|
any combination of exclusive and shared locks for any access types.
|
|||
|
|
|||
|
The reason for this flexibility is that locking policy strikes to the
|
|||
|
very heart of the resource management and versioning systems employed
|
|||
|
by various storage repositories. These repositories require control
|
|||
|
over what sort of locking will be made available. For example, some
|
|||
|
repositories only support shared write locks while others only
|
|||
|
provide support for exclusive write locks while yet others use no
|
|||
|
locking at all. As each system is sufficiently different to merit
|
|||
|
exclusion of certain locking features, this specification leaves
|
|||
|
locking as the sole axis of negotiation within WebDAV.
|
|||
|
|
|||
|
6.3 Lock Tokens
|
|||
|
|
|||
|
A lock token is a type of state token, represented as a URI, which
|
|||
|
identifies a particular lock. A lock token is returned by every
|
|||
|
successful LOCK operation in the lockdiscovery property in the
|
|||
|
response body, and can also be found through lock discovery on a
|
|||
|
resource.
|
|||
|
|
|||
|
Lock token URIs MUST be unique across all resources for all time.
|
|||
|
This uniqueness constraint allows lock tokens to be submitted across
|
|||
|
resources and servers without fear of confusion.
|
|||
|
|
|||
|
This specification provides a lock token URI scheme called
|
|||
|
opaquelocktoken that meets the uniqueness requirements. However
|
|||
|
resources are free to return any URI scheme so long as it meets the
|
|||
|
uniqueness requirements.
|
|||
|
|
|||
|
Having a lock token provides no special access rights. Anyone can
|
|||
|
find out anyone else's lock token by performing lock discovery.
|
|||
|
Locks MUST be enforced based upon whatever authentication mechanism
|
|||
|
is used by the server, not based on the secrecy of the token values.
|
|||
|
|
|||
|
6.4 opaquelocktoken Lock Token URI Scheme
|
|||
|
|
|||
|
The opaquelocktoken URI scheme is designed to be unique across all
|
|||
|
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 than
|
|||
|
the one that returned it.
|
|||
|
|
|||
|
All resources MUST recognize the opaquelocktoken scheme and, at
|
|||
|
minimum, recognize that the lock token does not refer to an
|
|||
|
outstanding lock on the resource.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 16]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
In order to guarantee uniqueness across all resources for all time
|
|||
|
the opaquelocktoken requires the use of the Universal Unique
|
|||
|
Identifier (UUID) mechanism, as described in [ISO-11578].
|
|||
|
|
|||
|
Opaquelocktoken generators, however, have a choice of how they create
|
|||
|
these tokens. They can either generate a new UUID for every lock
|
|||
|
token they create or they can create a single UUID and then add
|
|||
|
extension characters. If the second method is selected then the
|
|||
|
program generating the extensions MUST guarantee that the same
|
|||
|
extension will never be used twice with the associated UUID.
|
|||
|
|
|||
|
OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension] ; The UUID
|
|||
|
production is the string representation of a UUID, as defined in
|
|||
|
[ISO-11578]. Note that white space (LWS) is not allowed between
|
|||
|
elements of this production.
|
|||
|
|
|||
|
Extension = path ; path is defined in section 3.2.1 of RFC 2068
|
|||
|
[RFC2068]
|
|||
|
|
|||
|
6.4.1 Node Field Generation Without the IEEE 802 Address
|
|||
|
|
|||
|
UUIDs, as defined in [ISO-11578], contain a "node" field that
|
|||
|
contains one of the IEEE 802 addresses for the server machine. As
|
|||
|
noted in section 17.8, there are several security risks associated
|
|||
|
with exposing a machine's IEEE 802 address. This section provides an
|
|||
|
alternate mechanism for generating the "node" field of a UUID which
|
|||
|
does not employ an IEEE 802 address. WebDAV servers MAY use this
|
|||
|
algorithm for creating the node field when generating UUIDs. The
|
|||
|
text in this section is originally from an Internet-Draft by Paul
|
|||
|
Leach and Rich Salz, who are noted here to properly attribute their
|
|||
|
work.
|
|||
|
|
|||
|
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 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 IEEE 802
|
|||
|
addresses obtained from network cards; hence, there can never be a
|
|||
|
conflict between UUIDs generated by machines with and without network
|
|||
|
cards.
|
|||
|
|
|||
|
If a system does not have a primitive to generate cryptographic
|
|||
|
quality random numbers, then in most systems there are usually a
|
|||
|
fairly large number of sources of randomness available from which one
|
|||
|
can be generated. Such sources are system specific, but often
|
|||
|
include:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 17]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
- the percent of memory in use
|
|||
|
- the size of main memory in bytes
|
|||
|
- the amount of free main memory in bytes
|
|||
|
- the size of the paging or swap file in bytes
|
|||
|
- free bytes of paging or swap file
|
|||
|
- the total size of user virtual address space in bytes
|
|||
|
- the total available user address space bytes
|
|||
|
- the size of boot disk drive in bytes
|
|||
|
- the free disk space on boot drive in bytes
|
|||
|
- the current time
|
|||
|
- the amount of time since the system booted
|
|||
|
- the individual sizes of files in various system directories
|
|||
|
- the creation, last read, and modification times of files in
|
|||
|
various system directories
|
|||
|
- the utilization factors of various system resources (heap, etc.)
|
|||
|
- current mouse cursor position
|
|||
|
- current caret position
|
|||
|
- current number of running processes, threads
|
|||
|
- handles or IDs of the desktop window and the active window
|
|||
|
- the value of stack pointer of the caller
|
|||
|
- the process and thread ID of caller
|
|||
|
- various processor architecture specific performance counters
|
|||
|
(instructions executed, cache misses, TLB misses)
|
|||
|
|
|||
|
(Note that it is precisely the above kinds of sources of randomness
|
|||
|
that are used to seed cryptographic quality random number generators
|
|||
|
on systems without special hardware for their construction.)
|
|||
|
|
|||
|
In addition, items such as the computer's name and the name of the
|
|||
|
operating system, while not strictly speaking random, will help
|
|||
|
differentiate the results from those obtained by other systems.
|
|||
|
|
|||
|
The exact algorithm to generate a node ID using these data is system
|
|||
|
specific, because both the data available and the functions to obtain
|
|||
|
them are often very system specific. However, assuming that one can
|
|||
|
concatenate all the values from the randomness sources into a buffer,
|
|||
|
and that a cryptographic hash function such as MD5 is available, then
|
|||
|
any 6 bytes of the MD5 hash of the buffer, with the multicast bit
|
|||
|
(the high bit of the first byte) set will be an appropriately random
|
|||
|
node ID.
|
|||
|
|
|||
|
Other hash functions, such as SHA-1, can also be used. The only
|
|||
|
requirement is that the result be suitably random _ in the sense that
|
|||
|
the outputs from a set uniformly distributed inputs are themselves
|
|||
|
uniformly distributed, and that a single bit change in the input can
|
|||
|
be expected to cause half of the output bits to change.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 18]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
6.5 Lock Capability Discovery
|
|||
|
|
|||
|
Since server lock support is optional, a client trying to lock a
|
|||
|
resource on a server can either try the lock and hope for the best,
|
|||
|
or perform some form of discovery to determine what lock capabilities
|
|||
|
the server supports. This is known as lock capability discovery.
|
|||
|
Lock capability discovery differs from discovery of supported access
|
|||
|
control types, since there may be access control types without
|
|||
|
corresponding lock types. A client can determine what lock types the
|
|||
|
server supports by retrieving the supportedlock property.
|
|||
|
|
|||
|
Any DAV compliant resource that supports the LOCK method MUST support
|
|||
|
the supportedlock property.
|
|||
|
|
|||
|
6.6 Active Lock Discovery
|
|||
|
|
|||
|
If another principal locks a resource that a principal wishes to
|
|||
|
access, it is useful for the second principal to be able to find out
|
|||
|
who the first principal is. For this purpose the lockdiscovery
|
|||
|
property is provided. This property lists all outstanding locks,
|
|||
|
describes their type, and where available, provides their lock token.
|
|||
|
|
|||
|
Any DAV compliant resource that supports the LOCK method MUST support
|
|||
|
the lockdiscovery property.
|
|||
|
|
|||
|
6.7 Usage Considerations
|
|||
|
|
|||
|
Although the locking mechanisms specified here provide some help in
|
|||
|
preventing lost updates, they cannot guarantee that updates will
|
|||
|
never be lost. Consider the following scenario:
|
|||
|
|
|||
|
Two clients A and B are interested in editing the resource '
|
|||
|
index.html'. Client A is an HTTP client rather than a WebDAV client,
|
|||
|
and so does not know how to perform locking.
|
|||
|
Client A doesn't lock the document, but does a GET and begins
|
|||
|
editing.
|
|||
|
Client B does LOCK, performs a GET and begins editing.
|
|||
|
Client B finishes editing, performs a PUT, then an UNLOCK.
|
|||
|
Client A performs a PUT, overwriting and losing all of B's changes.
|
|||
|
|
|||
|
There are several reasons why the WebDAV protocol itself cannot
|
|||
|
prevent this situation. First, it cannot force all clients to use
|
|||
|
locking because it must be compatible with HTTP clients that do not
|
|||
|
comprehend locking. Second, it cannot require servers to support
|
|||
|
locking because of the variety of repository implementations, some of
|
|||
|
which rely on reservations and merging rather than on locking.
|
|||
|
Finally, being stateless, it cannot enforce a sequence of operations
|
|||
|
like LOCK / GET / PUT / UNLOCK.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 19]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
WebDAV servers that support locking can reduce the likelihood that
|
|||
|
clients will accidentally overwrite each other's changes by requiring
|
|||
|
clients to lock resources before modifying them. Such servers would
|
|||
|
effectively prevent HTTP 1.0 and HTTP 1.1 clients from modifying
|
|||
|
resources.
|
|||
|
|
|||
|
WebDAV clients can be good citizens by using a lock / retrieve /
|
|||
|
write /unlock sequence of operations (at least by default) whenever
|
|||
|
they interact with a WebDAV server that supports locking.
|
|||
|
|
|||
|
HTTP 1.1 clients can be good citizens, avoiding overwriting other
|
|||
|
clients' changes, by using entity tags in If-Match headers with any
|
|||
|
requests that would modify resources.
|
|||
|
|
|||
|
Information managers may attempt to prevent overwrites by
|
|||
|
implementing client-side procedures requiring locking before
|
|||
|
modifying WebDAV resources.
|
|||
|
|
|||
|
7 Write Lock
|
|||
|
|
|||
|
This section describes the semantics specific to the write lock type.
|
|||
|
The write lock is a specific instance of a lock type, and is the only
|
|||
|
lock type described in this specification.
|
|||
|
|
|||
|
7.1 Methods Restricted by Write Locks
|
|||
|
|
|||
|
A write lock MUST prevent a principal without the lock from
|
|||
|
successfully executing a PUT, POST, PROPPATCH, LOCK, UNLOCK, MOVE,
|
|||
|
DELETE, or MKCOL on the locked resource. All other current methods,
|
|||
|
GET in particular, function independently of the lock.
|
|||
|
|
|||
|
Note, however, that as new methods are created it will be necessary
|
|||
|
to specify how they interact with a write lock.
|
|||
|
|
|||
|
7.2 Write Locks and Lock Tokens
|
|||
|
|
|||
|
A successful request for an exclusive or shared write lock MUST
|
|||
|
result in the generation of a unique lock token associated with the
|
|||
|
requesting principal. Thus if five principals have a shared write
|
|||
|
lock on the same resource there will be five lock tokens, one for
|
|||
|
each principal.
|
|||
|
|
|||
|
7.3 Write Locks and Properties
|
|||
|
|
|||
|
While those without a write lock may not alter a property on a
|
|||
|
resource it is still possible for the values of live properties to
|
|||
|
change, even while locked, due to the requirements of their schemas.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 20]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
Only dead properties and live properties defined to respect locks are
|
|||
|
guaranteed not to change while write locked.
|
|||
|
|
|||
|
7.4 Write Locks and Null Resources
|
|||
|
|
|||
|
It is possible to assert a write lock on a null resource in order to
|
|||
|
lock the name.
|
|||
|
|
|||
|
A write locked null resource, referred to as a lock-null resource,
|
|||
|
MUST respond with a 404 (Not Found) or 405 (Method Not Allowed) to
|
|||
|
any HTTP/1.1 or DAV methods except for PUT, MKCOL, OPTIONS, PROPFIND,
|
|||
|
LOCK, and UNLOCK. A lock-null resource MUST appear as a member of
|
|||
|
its parent collection. Additionally the lock-null resource MUST have
|
|||
|
defined on it all mandatory DAV properties. Most of these
|
|||
|
properties, such as all the get* properties, will have no value as a
|
|||
|
lock-null resource does not support the GET method. Lock-Null
|
|||
|
resources MUST have defined values for lockdiscovery and
|
|||
|
supportedlock properties.
|
|||
|
|
|||
|
Until a method such as PUT or MKCOL is successfully executed on the
|
|||
|
lock-null resource the resource MUST stay in the lock-null state.
|
|||
|
However, once a PUT or MKCOL is successfully executed on a lock-null
|
|||
|
resource the resource ceases to be in the lock-null state.
|
|||
|
|
|||
|
If the resource is unlocked, for any reason, without a PUT, MKCOL, or
|
|||
|
similar method having been successfully executed upon it then the
|
|||
|
resource MUST return to the null state.
|
|||
|
|
|||
|
7.5 Write Locks and Collections
|
|||
|
|
|||
|
A write lock on a collection, whether created by a "Depth: 0" or
|
|||
|
"Depth: infinity" lock request, prevents the addition or removal of
|
|||
|
member URIs of the collection by non-lock owners. As a consequence,
|
|||
|
when a principal issues a PUT or POST request to create a new
|
|||
|
resource under a URI which needs to be an internal member of a write
|
|||
|
locked collection to maintain HTTP namespace consistency, or issues a
|
|||
|
DELETE to remove a resource which has a URI which is an existing
|
|||
|
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 containing
|
|||
|
member URIs identifying resources that are currently locked in a
|
|||
|
manner which conflicts with the write lock, the request MUST fail
|
|||
|
with a 423 (Locked) status code.
|
|||
|
|
|||
|
If a lock owner causes the URI of a resource to be added as an
|
|||
|
internal member URI of a locked collection then the new resource MUST
|
|||
|
be automatically added to the lock. This is the only mechanism that
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 21]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
allows a resource to be added to a write lock. Thus, for example, if
|
|||
|
the collection /a/b/ is write locked and the resource /c 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
|
|||
|
|
|||
|
If a user agent is not required to have knowledge about a lock when
|
|||
|
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
|
|||
|
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
|
|||
|
resource. In this scenario, the PUT succeeds because locks are
|
|||
|
associated with a principal, not a program, and thus program B,
|
|||
|
because it is acting with principal A's credential, is allowed to
|
|||
|
perform the PUT. However, had program B known about the lock, it
|
|||
|
would not have overwritten the resource, preferring instead to
|
|||
|
present a dialog box describing the conflict to the user. Due to
|
|||
|
this scenario, a mechanism is needed to prevent different programs
|
|||
|
from accidentally ignoring locks taken out by other programs with the
|
|||
|
same authorization.
|
|||
|
|
|||
|
In order to prevent these collisions a lock token MUST be submitted
|
|||
|
by an authorized principal in the If header for all locked resources
|
|||
|
that a method may interact with or the method MUST fail. For
|
|||
|
example, if a resource is to be moved and both the source and
|
|||
|
destination are locked then two lock tokens must be submitted, one
|
|||
|
for the source and the other for the destination.
|
|||
|
|
|||
|
7.6.1 Example - Write Lock
|
|||
|
|
|||
|
>>Request
|
|||
|
|
|||
|
COPY /~fielding/index.html HTTP/1.1
|
|||
|
Host: www.ics.uci.edu
|
|||
|
Destination: http://www.ics.uci.edu/users/f/fielding/index.html
|
|||
|
If: <http://www.ics.uci.edu/users/f/fielding/index.html>
|
|||
|
(<opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>)
|
|||
|
|
|||
|
>>Response
|
|||
|
|
|||
|
HTTP/1.1 204 No Content
|
|||
|
|
|||
|
In this example, even though both the source and destination are
|
|||
|
locked, only one lock token must be submitted, for the lock on the
|
|||
|
destination. This is because the source resource is not modified by
|
|||
|
a COPY, and hence unaffected by the write lock. In this example, user
|
|||
|
agent authentication has previously occurred via a mechanism outside
|
|||
|
the scope of the HTTP protocol, in the underlying transport layer.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 22]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
7.7 Write Locks and COPY/MOVE
|
|||
|
|
|||
|
A COPY method invocation MUST NOT duplicate any write locks active on
|
|||
|
the source. However, as previously noted, if the COPY copies the
|
|||
|
resource into a collection that is locked with "Depth: infinity",
|
|||
|
then the resource will be added to the lock.
|
|||
|
|
|||
|
A successful MOVE request on a write locked resource MUST NOT move
|
|||
|
the write lock with the resource. However, the resource is subject to
|
|||
|
being added to an existing lock at the destination, as specified in
|
|||
|
section 7.5. For example, if the MOVE makes the resource a child of a
|
|||
|
collection that is locked with "Depth: infinity", then the resource
|
|||
|
will be added to that collection's lock. Additionally, if a resource
|
|||
|
locked with "Depth: infinity" is moved to a destination that is
|
|||
|
within the scope of the same lock (e.g., within the namespace tree
|
|||
|
covered by the lock), the moved resource will again be a added to the
|
|||
|
lock. In both these examples, as specified in section 7.6, an If
|
|||
|
header must be submitted containing a lock token for both the source
|
|||
|
and destination.
|
|||
|
|
|||
|
7.8 Refreshing Write Locks
|
|||
|
|
|||
|
A client MUST NOT submit the same write lock request twice. Note
|
|||
|
that a client is always aware it is resubmitting the same lock
|
|||
|
request because it must include the lock token in the If header in
|
|||
|
order to make the request for a resource that is already locked.
|
|||
|
|
|||
|
However, a client may submit a LOCK method with an If header but
|
|||
|
without a body. This form of LOCK MUST only be used to "refresh" a
|
|||
|
lock. Meaning, at minimum, that any timers associated with the lock
|
|||
|
MUST be re-set.
|
|||
|
|
|||
|
A server may return a Timeout header with a lock refresh that is
|
|||
|
different than the Timeout header returned when the lock was
|
|||
|
originally requested. Additionally clients may submit Timeout
|
|||
|
headers of arbitrary value with their lock refresh requests.
|
|||
|
Servers, as always, may ignore Timeout headers submitted by the
|
|||
|
client.
|
|||
|
|
|||
|
If an error is received in response to a refresh LOCK request the
|
|||
|
client SHOULD assume that the lock was not refreshed.
|
|||
|
|
|||
|
8 HTTP Methods for Distributed Authoring
|
|||
|
|
|||
|
The following new HTTP methods use XML as a request and response
|
|||
|
format. All DAV compliant clients and resources MUST use XML parsers
|
|||
|
that are compliant with [REC-XML]. All XML used in either requests
|
|||
|
or responses MUST be, at minimum, well formed. If a server receives
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 23]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
ill-formed XML in a request it MUST reject the entire 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 of the executed
|
|||
|
method and SHOULD treat the server as malfunctioning.
|
|||
|
|
|||
|
8.1 PROPFIND
|
|||
|
|
|||
|
The PROPFIND method retrieves properties defined on the resource
|
|||
|
identified by the Request-URI, if the resource does not have any
|
|||
|
internal members, or on the resource identified by the Request-URI
|
|||
|
and potentially its member resources, if the resource is a collection
|
|||
|
that has internal member URIs. All DAV compliant resources MUST
|
|||
|
support the PROPFIND method and the propfind XML 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
|
|||
|
"infinity" with a PROPFIND on a collection resource with internal
|
|||
|
member URIs. DAV compliant servers MUST support the "0", "1" and
|
|||
|
"infinity" behaviors. By default, the PROPFIND method without a 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 request
|
|||
|
method describing what information is being requested. It is
|
|||
|
possible to request particular property values, all property 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 request body
|
|||
|
MUST be treated as a request for the names and values of all
|
|||
|
properties.
|
|||
|
|
|||
|
All servers MUST support returning a response of content type
|
|||
|
text/xml or application/xml that contains a multistatus XML element
|
|||
|
that describes the results of the attempts to retrieve the various
|
|||
|
properties.
|
|||
|
|
|||
|
If there is an error retrieving a property then a proper error 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 noted, if the
|
|||
|
response uses a multistatus XML element, with a response XML element
|
|||
|
which contains a 404 (Not Found) status value.
|
|||
|
|
|||
|
Consequently, the multistatus XML element for a collection resource
|
|||
|
with member URIs MUST include a response XML element for each member
|
|||
|
URI of the collection, to whatever depth was requested. Each response
|
|||
|
XML element MUST contain an href XML element that gives the URI of
|
|||
|
the resource on which the properties in the prop XML element are
|
|||
|
defined. Results for a PROPFIND on a collection resource with
|
|||
|
internal member URIs are returned as a flat list whose order of
|
|||
|
entries is not significant.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 24]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
In the case of allprop and propname, if a principal does not have the
|
|||
|
right to know whether a particular property exists then the property
|
|||
|
should be silently excluded from the response.
|
|||
|
|
|||
|
The results of this method SHOULD NOT be cached.
|
|||
|
|
|||
|
8.1.1 Example - Retrieving Named Properties
|
|||
|
|
|||
|
>>Request
|
|||
|
|
|||
|
PROPFIND /file HTTP/1.1
|
|||
|
Host: www.foo.bar
|
|||
|
Content-type: text/xml; charset="utf-8"
|
|||
|
Content-Length: xxxx
|
|||
|
|
|||
|
<?xml version="1.0" encoding="utf-8" ?>
|
|||
|
<D:propfind xmlns:D="DAV:">
|
|||
|
<D:prop xmlns:R="http://www.foo.bar/boxschema/">
|
|||
|
<R:bigbox/>
|
|||
|
<R:author/>
|
|||
|
<R:DingALing/>
|
|||
|
<R:Random/>
|
|||
|
</D:prop>
|
|||
|
</D:propfind>
|
|||
|
|
|||
|
>>Response
|
|||
|
|
|||
|
HTTP/1.1 207 Multi-Status
|
|||
|
Content-Type: text/xml; charset="utf-8"
|
|||
|
Content-Length: xxxx
|
|||
|
|
|||
|
<?xml version="1.0" encoding="utf-8" ?>
|
|||
|
<D:multistatus xmlns:D="DAV:">
|
|||
|
<D:response>
|
|||
|
<D:href>http://www.foo.bar/file</D:href>
|
|||
|
<D:propstat>
|
|||
|
<D:prop xmlns:R="http://www.foo.bar/boxschema/">
|
|||
|
<R:bigbox>
|
|||
|
<R:BoxType>Box type A</R:BoxType>
|
|||
|
</R:bigbox>
|
|||
|
<R:author>
|
|||
|
<R:Name>J.J. Johnson</R:Name>
|
|||
|
</R:author>
|
|||
|
</D:prop>
|
|||
|
<D:status>HTTP/1.1 200 OK</D:status>
|
|||
|
</D:propstat>
|
|||
|
<D:propstat>
|
|||
|
<D:prop><R:DingALing/><R:Random/></D:prop>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 25]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
<D:status>HTTP/1.1 403 Forbidden</D:status>
|
|||
|
<D:responsedescription> The user does not have access to
|
|||
|
the DingALing property.
|
|||
|
</D:responsedescription>
|
|||
|
</D:propstat>
|
|||
|
</D:response>
|
|||
|
<D:responsedescription> There has been an access violation error.
|
|||
|
</D:responsedescription>
|
|||
|
</D:multistatus>
|
|||
|
|
|||
|
In this example, PROPFIND is executed on a non-collection resource
|
|||
|
http://www.foo.bar/file. The propfind XML element specifies the name
|
|||
|
of four properties whose values are being requested. In this case
|
|||
|
only two properties were returned, since the principal issuing the
|
|||
|
request did not have sufficient access rights to see the third and
|
|||
|
fourth properties.
|
|||
|
|
|||
|
8.1.2 Example - Using allprop to Retrieve All Properties
|
|||
|
|
|||
|
>>Request
|
|||
|
|
|||
|
PROPFIND /container/ HTTP/1.1
|
|||
|
Host: www.foo.bar
|
|||
|
Depth: 1
|
|||
|
Content-Type: text/xml; charset="utf-8"
|
|||
|
Content-Length: xxxx
|
|||
|
|
|||
|
<?xml version="1.0" encoding="utf-8" ?>
|
|||
|
<D:propfind xmlns:D="DAV:">
|
|||
|
<D:allprop/>
|
|||
|
</D:propfind>
|
|||
|
|
|||
|
>>Response
|
|||
|
|
|||
|
HTTP/1.1 207 Multi-Status
|
|||
|
Content-Type: text/xml; charset="utf-8"
|
|||
|
Content-Length: xxxx
|
|||
|
|
|||
|
<?xml version="1.0" encoding="utf-8" ?>
|
|||
|
<D:multistatus xmlns:D="DAV:">
|
|||
|
<D:response>
|
|||
|
<D:href>http://www.foo.bar/container/</D:href>
|
|||
|
<D:propstat>
|
|||
|
<D:prop xmlns:R="http://www.foo.bar/boxschema/">
|
|||
|
<R:bigbox>
|
|||
|
<R:BoxType>Box type A</R:BoxType>
|
|||
|
</R:bigbox>
|
|||
|
<R:author>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 26]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
<R:Name>Hadrian</R:Name>
|
|||
|
</R:author>
|
|||
|
<D:creationdate>
|
|||
|
1997-12-01T17:42:21-08:00
|
|||
|
</D:creationdate>
|
|||
|
<D:displayname>
|
|||
|
Example collection
|
|||
|
</D:displayname>
|
|||
|
<D:resourcetype><D:collection/></D:resourcetype>
|
|||
|
<D:supportedlock>
|
|||
|
<D:lockentry>
|
|||
|
<D:lockscope><D:exclusive/></D:lockscope>
|
|||
|
<D:locktype><D:write/></D:locktype>
|
|||
|
</D:lockentry>
|
|||
|
<D:lockentry>
|
|||
|
<D:lockscope><D:shared/></D:lockscope>
|
|||
|
<D:locktype><D:write/></D:locktype>
|
|||
|
</D:lockentry>
|
|||
|
</D:supportedlock>
|
|||
|
</D:prop>
|
|||
|
<D:status>HTTP/1.1 200 OK</D:status>
|
|||
|
</D:propstat>
|
|||
|
</D:response>
|
|||
|
<D:response>
|
|||
|
<D:href>http://www.foo.bar/container/front.html</D:href>
|
|||
|
<D:propstat>
|
|||
|
<D:prop xmlns:R="http://www.foo.bar/boxschema/">
|
|||
|
<R:bigbox>
|
|||
|
<R:BoxType>Box type B</R:BoxType>
|
|||
|
</R:bigbox>
|
|||
|
<D:creationdate>
|
|||
|
1997-12-01T18:27:21-08:00
|
|||
|
</D:creationdate>
|
|||
|
<D:displayname>
|
|||
|
Example HTML resource
|
|||
|
</D:displayname>
|
|||
|
<D:getcontentlength>
|
|||
|
4525
|
|||
|
</D:getcontentlength>
|
|||
|
<D:getcontenttype>
|
|||
|
text/html
|
|||
|
</D:getcontenttype>
|
|||
|
<D:getetag>
|
|||
|
zzyzx
|
|||
|
</D:getetag>
|
|||
|
<D:getlastmodified>
|
|||
|
Monday, 12-Jan-98 09:25:56 GMT
|
|||
|
</D:getlastmodified>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 27]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
<D:resourcetype/>
|
|||
|
<D:supportedlock>
|
|||
|
<D:lockentry>
|
|||
|
<D:lockscope><D:exclusive/></D:lockscope>
|
|||
|
<D:locktype><D:write/></D:locktype>
|
|||
|
</D:lockentry>
|
|||
|
<D:lockentry>
|
|||
|
<D:lockscope><D:shared/></D:lockscope>
|
|||
|
<D:locktype><D:write/></D:locktype>
|
|||
|
</D:lockentry>
|
|||
|
</D:supportedlock>
|
|||
|
</D:prop>
|
|||
|
<D:status>HTTP/1.1 200 OK</D:status>
|
|||
|
</D:propstat>
|
|||
|
</D:response>
|
|||
|
</D:multistatus>
|
|||
|
|
|||
|
In this example, PROPFIND was invoked on the resource
|
|||
|
http://www.foo.bar/container/ with a Depth header of 1, meaning the
|
|||
|
request applies to the resource and its children, and a propfind XML
|
|||
|
element containing the allprop XML element, meaning the request
|
|||
|
should return the name and value of all properties defined on each
|
|||
|
resource.
|
|||
|
|
|||
|
The resource http://www.foo.bar/container/ has six properties defined
|
|||
|
on it:
|
|||
|
|
|||
|
http://www.foo.bar/boxschema/bigbox,
|
|||
|
http://www.foo.bar/boxschema/author, DAV:creationdate,
|
|||
|
DAV:displayname, DAV:resourcetype, and DAV:supportedlock.
|
|||
|
|
|||
|
The last four properties are WebDAV-specific, defined in section 13.
|
|||
|
Since GET is not supported on this resource, the get* properties
|
|||
|
(e.g., getcontentlength) are not defined on this resource. The DAV-
|
|||
|
specific properties assert that "container" was created on December
|
|||
|
1, 1997, at 5:42:21PM, in a time zone 8 hours west of GMT
|
|||
|
(creationdate), has a name of "Example collection" (displayname), a
|
|||
|
collection resource type (resourcetype), and supports exclusive write
|
|||
|
and shared write locks (supportedlock).
|
|||
|
|
|||
|
The resource http://www.foo.bar/container/front.html has nine
|
|||
|
properties defined on it:
|
|||
|
|
|||
|
http://www.foo.bar/boxschema/bigbox (another instance of the "bigbox"
|
|||
|
property type), DAV:creationdate, DAV:displayname,
|
|||
|
DAV:getcontentlength, DAV:getcontenttype, DAV:getetag,
|
|||
|
DAV:getlastmodified, DAV:resourcetype, and DAV:supportedlock.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 28]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
The DAV-specific properties assert that "front.html" was created on
|
|||
|
December 1, 1997, at 6:27:21PM, in a time zone 8 hours west of GMT
|
|||
|
(creationdate), has a name of "Example HTML resource" (displayname),
|
|||
|
a content length of 4525 bytes (getcontentlength), a MIME type of
|
|||
|
"text/html" (getcontenttype), an entity tag of "zzyzx" (getetag), was
|
|||
|
last modified on Monday, January 12, 1998, at 09:25:56 GMT
|
|||
|
(getlastmodified), has an empty resource type, meaning that it is not
|
|||
|
a collection (resourcetype), and supports both exclusive write and
|
|||
|
shared write locks (supportedlock).
|
|||
|
|
|||
|
8.1.3 Example - Using propname to Retrieve all Property Names
|
|||
|
|
|||
|
>>Request
|
|||
|
|
|||
|
PROPFIND /container/ HTTP/1.1
|
|||
|
Host: www.foo.bar
|
|||
|
Content-Type: text/xml; charset="utf-8"
|
|||
|
Content-Length: xxxx
|
|||
|
|
|||
|
<?xml version="1.0" encoding="utf-8" ?>
|
|||
|
<propfind xmlns="DAV:">
|
|||
|
<propname/>
|
|||
|
</propfind>
|
|||
|
|
|||
|
>>Response
|
|||
|
|
|||
|
HTTP/1.1 207 Multi-Status
|
|||
|
Content-Type: text/xml; charset="utf-8"
|
|||
|
Content-Length: xxxx
|
|||
|
|
|||
|
<?xml version="1.0" encoding="utf-8" ?>
|
|||
|
<multistatus xmlns="DAV:">
|
|||
|
<response>
|
|||
|
<href>http://www.foo.bar/container/</href>
|
|||
|
<propstat>
|
|||
|
<prop xmlns:R="http://www.foo.bar/boxschema/">
|
|||
|
<R:bigbox/>
|
|||
|
<R:author/>
|
|||
|
<creationdate/>
|
|||
|
<displayname/>
|
|||
|
<resourcetype/>
|
|||
|
<supportedlock/>
|
|||
|
</prop>
|
|||
|
<status>HTTP/1.1 200 OK</status>
|
|||
|
</propstat>
|
|||
|
</response>
|
|||
|
<response>
|
|||
|
<href>http://www.foo.bar/container/front.html</href>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 29]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
<propstat>
|
|||
|
<prop xmlns:R="http://www.foo.bar/boxschema/">
|
|||
|
<R:bigbox/>
|
|||
|
<creationdate/>
|
|||
|
<displayname/>
|
|||
|
<getcontentlength/>
|
|||
|
<getcontenttype/>
|
|||
|
<getetag/>
|
|||
|
<getlastmodified/>
|
|||
|
<resourcetype/>
|
|||
|
<supportedlock/>
|
|||
|
</prop>
|
|||
|
<status>HTTP/1.1 200 OK</status>
|
|||
|
</propstat>
|
|||
|
</response>
|
|||
|
</multistatus>
|
|||
|
|
|||
|
|
|||
|
In this example, PROPFIND is invoked on the collection resource
|
|||
|
http://www.foo.bar/container/, with a propfind XML element containing
|
|||
|
the propname XML element, meaning the name of all properties should
|
|||
|
be returned. Since no Depth header is present, it assumes its
|
|||
|
default value of "infinity", meaning the name of the properties on
|
|||
|
the collection and all its progeny should be returned.
|
|||
|
|
|||
|
Consistent with the previous example, resource
|
|||
|
http://www.foo.bar/container/ has six properties defined on it,
|
|||
|
http://www.foo.bar/boxschema/bigbox,
|
|||
|
http://www.foo.bar/boxschema/author, DAV:creationdate,
|
|||
|
DAV:displayname, DAV:resourcetype, and DAV:supportedlock.
|
|||
|
|
|||
|
The resource http://www.foo.bar/container/index.html, a member of the
|
|||
|
"container" collection, has nine properties defined on it,
|
|||
|
http://www.foo.bar/boxschema/bigbox, DAV:creationdate,
|
|||
|
DAV:displayname, DAV:getcontentlength, DAV:getcontenttype,
|
|||
|
DAV:getetag, DAV:getlastmodified, DAV:resourcetype, and
|
|||
|
DAV:supportedlock.
|
|||
|
|
|||
|
This example also demonstrates the use of XML namespace scoping, and
|
|||
|
the default namespace. Since the "xmlns" attribute does not contain
|
|||
|
an explicit "shorthand name" (prefix) letter, the namespace applies
|
|||
|
by default to all enclosed elements. Hence, all elements which do
|
|||
|
not explicitly state the namespace to which they belong are members
|
|||
|
of the "DAV:" namespace schema.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 30]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
8.2 PROPPATCH
|
|||
|
|
|||
|
The PROPPATCH method processes instructions specified in the request
|
|||
|
body to set and/or remove properties defined on the resource
|
|||
|
identified by the Request-URI.
|
|||
|
|
|||
|
All DAV compliant resources MUST support the PROPPATCH method and
|
|||
|
MUST process instructions that are specified using the
|
|||
|
propertyupdate, set, and remove XML elements of the DAV schema.
|
|||
|
Execution of the directives in this method is, of course, subject to
|
|||
|
access control constraints. DAV compliant resources SHOULD support
|
|||
|
the setting of arbitrary dead properties.
|
|||
|
|
|||
|
The request message body of a PROPPATCH method MUST contain the
|
|||
|
propertyupdate XML element. Instruction processing MUST occur in the
|
|||
|
order instructions are received (i.e., from top to bottom).
|
|||
|
Instructions MUST either all be executed or none executed. Thus if
|
|||
|
any error occurs during processing all executed instructions MUST be
|
|||
|
undone and a proper error result returned. Instruction processing
|
|||
|
details can be found in the definition of the set and remove
|
|||
|
instructions in section 12.13.
|
|||
|
|
|||
|
8.2.1 Status Codes for use with 207 (Multi-Status)
|
|||
|
|
|||
|
The following are examples of response codes one would expect to be
|
|||
|
used in a 207 (Multi-Status) response for this method. Note,
|
|||
|
however, that unless explicitly prohibited any 2/3/4/5xx series
|
|||
|
response code may be used in a 207 (Multi-Status) response.
|
|||
|
|
|||
|
200 (OK) - The command succeeded. As there can be a mixture of sets
|
|||
|
and removes in a body, a 201 (Created) seems inappropriate.
|
|||
|
|
|||
|
403 (Forbidden) - The client, for reasons the server chooses not to
|
|||
|
specify, cannot alter one of the properties.
|
|||
|
|
|||
|
409 (Conflict) - The client has provided a value whose semantics are
|
|||
|
not appropriate for the property. This includes trying to set read-
|
|||
|
only properties.
|
|||
|
|
|||
|
423 (Locked) - The specified resource is locked and the client either
|
|||
|
is not a lock owner or the lock type requires a lock token to be
|
|||
|
submitted and the client did not submit it.
|
|||
|
|
|||
|
507 (Insufficient Storage) - The server did not have sufficient space
|
|||
|
to record the property.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 31]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
8.2.2 Example - PROPPATCH
|
|||
|
|
|||
|
>>Request
|
|||
|
|
|||
|
PROPPATCH /bar.html HTTP/1.1
|
|||
|
Host: www.foo.com
|
|||
|
Content-Type: text/xml; charset="utf-8"
|
|||
|
Content-Length: xxxx
|
|||
|
|
|||
|
<?xml version="1.0" encoding="utf-8" ?>
|
|||
|
<D:propertyupdate xmlns:D="DAV:"
|
|||
|
xmlns:Z="http://www.w3.com/standards/z39.50/">
|
|||
|
<D:set>
|
|||
|
<D:prop>
|
|||
|
<Z:authors>
|
|||
|
<Z:Author>Jim Whitehead</Z:Author>
|
|||
|
<Z:Author>Roy Fielding</Z:Author>
|
|||
|
</Z:authors>
|
|||
|
</D:prop>
|
|||
|
</D:set>
|
|||
|
<D:remove>
|
|||
|
<D:prop><Z:Copyright-Owner/></D:prop>
|
|||
|
</D:remove>
|
|||
|
</D:propertyupdate>
|
|||
|
|
|||
|
>>Response
|
|||
|
|
|||
|
HTTP/1.1 207 Multi-Status
|
|||
|
Content-Type: text/xml; charset="utf-8"
|
|||
|
Content-Length: xxxx
|
|||
|
|
|||
|
<?xml version="1.0" encoding="utf-8" ?>
|
|||
|
<D:multistatus xmlns:D="DAV:"
|
|||
|
xmlns:Z="http://www.w3.com/standards/z39.50">
|
|||
|
<D:response>
|
|||
|
<D:href>http://www.foo.com/bar.html</D:href>
|
|||
|
<D:propstat>
|
|||
|
<D:prop><Z:Authors/></D:prop>
|
|||
|
<D:status>HTTP/1.1 424 Failed Dependency</D:status>
|
|||
|
</D:propstat>
|
|||
|
<D:propstat>
|
|||
|
<D:prop><Z:Copyright-Owner/></D:prop>
|
|||
|
<D:status>HTTP/1.1 409 Conflict</D:status>
|
|||
|
</D:propstat>
|
|||
|
<D:responsedescription> Copyright Owner can not be deleted or
|
|||
|
altered.</D:responsedescription>
|
|||
|
</D:response>
|
|||
|
</D:multistatus>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 32]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
In this example, the client requests the server to set the value of
|
|||
|
the http://www.w3.com/standards/z39.50/Authors property, and to
|
|||
|
remove the property http://www.w3.com/standards/z39.50/Copyright-
|
|||
|
Owner. Since the Copyright-Owner property could not be removed, no
|
|||
|
property modifications occur. The 424 (Failed Dependency) status
|
|||
|
code for the Authors property indicates this action would have
|
|||
|
succeeded if it were not for the conflict with removing the
|
|||
|
Copyright-Owner property.
|
|||
|
|
|||
|
8.3 MKCOL Method
|
|||
|
|
|||
|
The MKCOL method is used to create a new collection. All DAV
|
|||
|
compliant resources MUST support the MKCOL method.
|
|||
|
|
|||
|
8.3.1 Request
|
|||
|
|
|||
|
MKCOL creates a new collection resource at the location specified by
|
|||
|
the Request-URI. If the resource identified by the Request-URI is
|
|||
|
non-null then the MKCOL MUST fail. During MKCOL processing, a server
|
|||
|
MUST make the Request-URI a member of its parent collection, unless
|
|||
|
the Request-URI is "/". If no such ancestor exists, the method MUST
|
|||
|
fail. When the MKCOL operation creates a new collection resource,
|
|||
|
all ancestors MUST already exist, or the method MUST fail with a 409
|
|||
|
(Conflict) status code. For example, if a request to create
|
|||
|
collection /a/b/c/d/ is made, and neither /a/b/ nor /a/b/c/ exists,
|
|||
|
the request must fail.
|
|||
|
|
|||
|
When MKCOL is invoked without a request body, the newly created
|
|||
|
collection SHOULD have no members.
|
|||
|
|
|||
|
A MKCOL request message may contain a message body. The behavior of
|
|||
|
a MKCOL request when the body is present is limited to creating
|
|||
|
collections, members of a collection, bodies of members and
|
|||
|
properties on the collections or members. If the server receives a
|
|||
|
MKCOL request entity type it does not support or understand it MUST
|
|||
|
respond with a 415 (Unsupported Media Type) status code. The exact
|
|||
|
behavior of MKCOL for various request media types is undefined in
|
|||
|
this document, and will be specified in separate documents.
|
|||
|
|
|||
|
8.3.2 Status Codes
|
|||
|
|
|||
|
Responses from a MKCOL request MUST NOT be cached as MKCOL has non-
|
|||
|
idempotent semantics.
|
|||
|
|
|||
|
201 (Created) - The collection or structured resource was created in
|
|||
|
its entirety.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 33]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
403 (Forbidden) - This indicates at least one of two conditions: 1)
|
|||
|
the server does not allow the creation of collections at the given
|
|||
|
location in its namespace, or 2) the parent collection of the
|
|||
|
Request-URI exists but cannot accept members.
|
|||
|
|
|||
|
405 (Method Not Allowed) - MKCOL can only be executed on a
|
|||
|
deleted/non-existent resource.
|
|||
|
|
|||
|
409 (Conflict) - A collection cannot be made at the Request-URI until
|
|||
|
one or more intermediate collections have been created.
|
|||
|
|
|||
|
415 (Unsupported Media Type)- The server does not support the request
|
|||
|
type of the body.
|
|||
|
|
|||
|
507 (Insufficient Storage) - The resource does not have sufficient
|
|||
|
space to record the state of the resource after the execution of this
|
|||
|
method.
|
|||
|
|
|||
|
8.3.3 Example - MKCOL
|
|||
|
|
|||
|
This example creates a collection called /webdisc/xfiles/ on the
|
|||
|
server www.server.org.
|
|||
|
|
|||
|
>>Request
|
|||
|
|
|||
|
MKCOL /webdisc/xfiles/ HTTP/1.1
|
|||
|
Host: www.server.org
|
|||
|
|
|||
|
>>Response
|
|||
|
|
|||
|
HTTP/1.1 201 Created
|
|||
|
|
|||
|
8.4 GET, HEAD for Collections
|
|||
|
|
|||
|
The semantics of GET are unchanged when applied to a collection,
|
|||
|
since GET is defined as, "retrieve whatever information (in the form
|
|||
|
of an entity) is identified by the Request-URI" [RFC2068]. GET when
|
|||
|
applied to a collection may return the contents of an "index.html"
|
|||
|
resource, a human-readable view of the contents of the collection, or
|
|||
|
something else altogether. Hence it is possible that the result of a
|
|||
|
GET on a collection will bear no correlation to the membership of the
|
|||
|
collection.
|
|||
|
|
|||
|
Similarly, since the definition of HEAD is a GET without a response
|
|||
|
message body, the semantics of HEAD are unmodified when applied to
|
|||
|
collection resources.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 34]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
8.5 POST for Collections
|
|||
|
|
|||
|
Since by definition the actual function performed by POST is
|
|||
|
determined by the server and often depends on the particular
|
|||
|
resource, the behavior of POST when applied to collections cannot be
|
|||
|
meaningfully modified because it is largely undefined. Thus the
|
|||
|
semantics of POST are unmodified when applied to a collection.
|
|||
|
|
|||
|
8.6 DELETE
|
|||
|
|
|||
|
8.6.1 DELETE for Non-Collection Resources
|
|||
|
|
|||
|
If the DELETE method is issued to a non-collection resource whose
|
|||
|
URIs are an internal member of one or more collections, then during
|
|||
|
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
|
|||
|
|
|||
|
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
|
|||
|
a DELETE on a collection with any value but infinity.
|
|||
|
|
|||
|
DELETE instructs that the collection specified in the Request-URI and
|
|||
|
all resources identified by its internal member URIs are to be
|
|||
|
deleted.
|
|||
|
|
|||
|
If any resource identified by a member URI cannot be deleted then 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
|
|||
|
resource to be deleted.
|
|||
|
|
|||
|
When the DELETE method has completed processing it MUST result in a
|
|||
|
consistent namespace.
|
|||
|
|
|||
|
If an error occurs with a resource other than the resource identified
|
|||
|
in the Request-URI then the response MUST be a 207 (Multi-Status).
|
|||
|
424 (Failed Dependency) errors SHOULD NOT be in the 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 the client
|
|||
|
receives an error for the ancestor's progeny. Additionally 204 (No
|
|||
|
Content) errors SHOULD NOT be returned in the 207 (Multi-Status).
|
|||
|
The reason for this prohibition is that 204 (No Content) is the
|
|||
|
default success code.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 35]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
8.6.2.1 Example - DELETE
|
|||
|
|
|||
|
>>Request
|
|||
|
|
|||
|
DELETE /container/ HTTP/1.1
|
|||
|
Host: www.foo.bar
|
|||
|
|
|||
|
>>Response
|
|||
|
|
|||
|
HTTP/1.1 207 Multi-Status
|
|||
|
Content-Type: text/xml; charset="utf-8"
|
|||
|
Content-Length: xxxx
|
|||
|
|
|||
|
<?xml version="1.0" encoding="utf-8" ?>
|
|||
|
<d:multistatus xmlns:d="DAV:">
|
|||
|
<d:response>
|
|||
|
<d:href>http://www.foo.bar/container/resource3</d:href>
|
|||
|
<d:status>HTTP/1.1 423 Locked</d:status>
|
|||
|
</d:response>
|
|||
|
</d:multistatus>
|
|||
|
|
|||
|
In this example the attempt to delete
|
|||
|
http://www.foo.bar/container/resource3 failed because it is locked,
|
|||
|
and no lock token was submitted with the request. Consequently, the
|
|||
|
attempt to delete http://www.foo.bar/container/ also failed. Thus the
|
|||
|
client knows that the attempt to delete http://www.foo.bar/container/
|
|||
|
must have also failed since the parent can not be deleted unless its
|
|||
|
child has also been deleted. Even though a Depth header has not been
|
|||
|
included, a depth of infinity is assumed because the method is on a
|
|||
|
collection.
|
|||
|
|
|||
|
8.7 PUT
|
|||
|
|
|||
|
8.7.1 PUT for Non-Collection Resources
|
|||
|
|
|||
|
A PUT performed on an existing resource replaces the GET response
|
|||
|
entity of the resource. Properties defined on the resource may be
|
|||
|
recomputed during PUT processing but are not otherwise affected. For
|
|||
|
example, if a server recognizes the content type of the request body,
|
|||
|
it may be able to automatically extract information that could be
|
|||
|
profitably exposed as properties.
|
|||
|
|
|||
|
A PUT that would result in the creation of a resource without an
|
|||
|
appropriately scoped parent collection MUST fail with a 409
|
|||
|
(Conflict).
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 36]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
8.7.2 PUT for Collections
|
|||
|
|
|||
|
As defined in the HTTP/1.1 specification [RFC2068], the "PUT method
|
|||
|
requests that the enclosed entity be stored under the supplied
|
|||
|
Request-URI." Since submission of an entity representing a
|
|||
|
collection would implicitly encode creation and deletion of
|
|||
|
resources, this specification intentionally does not define a
|
|||
|
transmission format for creating a collection using PUT. Instead,
|
|||
|
the MKCOL method is defined to create collections.
|
|||
|
|
|||
|
When the PUT operation creates a new non-collection resource all
|
|||
|
ancestors MUST already exist. If all ancestors do not exist, the
|
|||
|
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,
|
|||
|
then the request must fail.
|
|||
|
|
|||
|
8.8 COPY Method
|
|||
|
|
|||
|
The COPY method creates a duplicate of the source resource,
|
|||
|
identified by the Request-URI, in the destination resource,
|
|||
|
identified by the URI in the Destination header. The Destination
|
|||
|
header MUST be present. The exact behavior of the COPY method
|
|||
|
depends on the type of the source resource.
|
|||
|
|
|||
|
All WebDAV compliant resources MUST support the COPY method.
|
|||
|
However, support for the COPY method does not guarantee the ability
|
|||
|
to copy a resource. For example, separate programs may control
|
|||
|
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 server.
|
|||
|
|
|||
|
8.8.1 COPY for HTTP/1.1 resources
|
|||
|
|
|||
|
When the source resource is not a collection the result of the COPY
|
|||
|
method is the creation of a new resource at the destination whose
|
|||
|
state and behavior match that of the source resource as closely as
|
|||
|
possible. After a successful COPY invocation, all properties on the
|
|||
|
source resource MUST be duplicated on the destination resource,
|
|||
|
subject to modifying headers and XML elements, following the
|
|||
|
definition for copying properties. Since the environment at the
|
|||
|
destination may be different than at the source due to factors
|
|||
|
outside the scope of control of the server, such as the absence of
|
|||
|
resources required for correct operation, it may not be possible to
|
|||
|
completely duplicate the behavior of the resource at the destination.
|
|||
|
Subsequent alterations to the destination resource will not modify
|
|||
|
the source resource. Subsequent alterations to the source resource
|
|||
|
will not modify the destination resource.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 37]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
8.8.2. COPY for Properties
|
|||
|
|
|||
|
The following section defines how properties on a resource are
|
|||
|
handled during a COPY operation.
|
|||
|
|
|||
|
Live properties SHOULD be duplicated as identically behaving live
|
|||
|
properties at the destination resource. If a property cannot be
|
|||
|
copied live, then its value MUST be duplicated, octet-for-octet, in
|
|||
|
an identically named, dead property on the destination resource
|
|||
|
subject to the effects of the propertybehavior XML element.
|
|||
|
|
|||
|
The propertybehavior XML element can specify that properties are
|
|||
|
copied on best effort, that all live properties must be successfully
|
|||
|
copied or the method must fail, or that a specified list of live
|
|||
|
properties must be successfully copied or the method must fail. The
|
|||
|
propertybehavior XML element is defined in section 12.12.
|
|||
|
|
|||
|
8.8.3 COPY for Collections
|
|||
|
|
|||
|
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
|
|||
|
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
|
|||
|
"infinity" Depth header behaviors.
|
|||
|
|
|||
|
A COPY of depth infinity instructs that the collection resource
|
|||
|
identified by the Request-URI is to be copied to the location
|
|||
|
identified by the URI in the Destination header, and all its internal
|
|||
|
member resources are to be copied to a location relative to it,
|
|||
|
recursively through all levels of the collection hierarchy.
|
|||
|
|
|||
|
A COPY of "Depth: 0" only instructs that the collection and its
|
|||
|
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
|
|||
|
resource to be copied with the exception of the Destination header.
|
|||
|
|
|||
|
The Destination header only specifies the destination URI for the
|
|||
|
Request-URI. When applied to members of the collection identified by
|
|||
|
the Request-URI the value of Destination is to be modified to reflect
|
|||
|
the current location in the hierarchy. So, if the Request- URI is
|
|||
|
/a/ with Host header value http://fun.com/ and the 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.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 38]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
When the COPY method has completed processing it MUST have created a
|
|||
|
consistent namespace at the destination (see section 5.1 for the
|
|||
|
definition of namespace consistency). However, if an error occurs
|
|||
|
while copying an internal collection, the server MUST NOT copy any
|
|||
|
resources identified by members of this collection (i.e., the server
|
|||
|
must skip this subtree), as this would create an inconsistent
|
|||
|
namespace. After detecting an error, the COPY operation SHOULD try to
|
|||
|
finish as much of the original copy operation as possible (i.e., the
|
|||
|
server should still attempt to copy other subtrees and their members,
|
|||
|
that are not descendents of an error-causing collection). So, for
|
|||
|
example, if an infinite depth copy operation is performed on
|
|||
|
collection /a/, which contains collections /a/b/ and /a/c/, and an
|
|||
|
error occurs copying /a/b/, an attempt should still be made to copy
|
|||
|
/a/c/. Similarly, after encountering an error copying a non-
|
|||
|
collection resource as part of an infinite depth copy, the server
|
|||
|
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 other
|
|||
|
than the resource identified in the Request-URI then the response
|
|||
|
MUST be a 207 (Multi-Status).
|
|||
|
|
|||
|
The 424 (Failed Dependency) status code SHOULD NOT be returned in the
|
|||
|
207 (Multi-Status) response from a COPY method. These responses 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 for
|
|||
|
the parent. Additionally 201 (Created)/204 (No Content) status codes
|
|||
|
SHOULD NOT be returned as values in 207 (Multi-Status) responses from
|
|||
|
COPY methods. They, too, can be safely omitted because they are the
|
|||
|
default success codes.
|
|||
|
|
|||
|
8.8.4 COPY and the Overwrite Header
|
|||
|
|
|||
|
If a resource exists at the destination and the Overwrite header is
|
|||
|
"T" then prior to performing the copy the server MUST perform a
|
|||
|
DELETE with "Depth: infinity" on the destination resource. If the
|
|||
|
Overwrite header is set to "F" then the operation will fail.
|
|||
|
|
|||
|
8.8.5 Status Codes
|
|||
|
|
|||
|
201 (Created) - The source resource was successfully copied. The
|
|||
|
copy operation resulted in the creation of a new resource.
|
|||
|
|
|||
|
204 (No Content) - The source resource was successfully copied to a
|
|||
|
pre-existing destination resource.
|
|||
|
|
|||
|
403 (Forbidden) _ The source and destination URIs are the same.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 39]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
409 (Conflict) _ A resource cannot be created at the destination
|
|||
|
until one or more intermediate collections have been created.
|
|||
|
|
|||
|
412 (Precondition Failed) - The server was unable to maintain the
|
|||
|
liveness of the properties listed in the propertybehavior XML element
|
|||
|
or the Overwrite header is "F" and the state of the destination
|
|||
|
resource is non-null.
|
|||
|
|
|||
|
423 (Locked) - The destination resource was locked.
|
|||
|
|
|||
|
502 (Bad Gateway) - This may occur when the destination is on another
|
|||
|
server and the destination server refuses to accept the resource.
|
|||
|
|
|||
|
507 (Insufficient Storage) - The destination resource does not have
|
|||
|
sufficient space to record the state of the resource after the
|
|||
|
execution of this method.
|
|||
|
|
|||
|
8.8.6 Example - COPY with Overwrite
|
|||
|
|
|||
|
This example shows resource
|
|||
|
http://www.ics.uci.edu/~fielding/index.html being copied to the
|
|||
|
location http://www.ics.uci.edu/users/f/fielding/index.html. The 204
|
|||
|
(No Content) status code indicates the existing resource at the
|
|||
|
destination was overwritten.
|
|||
|
|
|||
|
>>Request
|
|||
|
|
|||
|
COPY /~fielding/index.html HTTP/1.1
|
|||
|
Host: www.ics.uci.edu
|
|||
|
Destination: http://www.ics.uci.edu/users/f/fielding/index.html
|
|||
|
|
|||
|
>>Response
|
|||
|
|
|||
|
HTTP/1.1 204 No Content
|
|||
|
|
|||
|
8.8.7 Example - COPY with No Overwrite
|
|||
|
|
|||
|
The following example shows the same copy operation being performed,
|
|||
|
but with the Overwrite header set to "F." A response of 412
|
|||
|
(Precondition Failed) is returned because the destination resource
|
|||
|
has a non-null state.
|
|||
|
|
|||
|
>>Request
|
|||
|
|
|||
|
COPY /~fielding/index.html HTTP/1.1
|
|||
|
Host: www.ics.uci.edu
|
|||
|
Destination: http://www.ics.uci.edu/users/f/fielding/index.html
|
|||
|
Overwrite: F
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 40]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
>>Response
|
|||
|
|
|||
|
HTTP/1.1 412 Precondition Failed
|
|||
|
|
|||
|
8.8.8 Example - COPY of a Collection
|
|||
|
|
|||
|
>>Request
|
|||
|
|
|||
|
COPY /container/ HTTP/1.1
|
|||
|
Host: www.foo.bar
|
|||
|
Destination: http://www.foo.bar/othercontainer/
|
|||
|
Depth: infinity
|
|||
|
Content-Type: text/xml; charset="utf-8"
|
|||
|
Content-Length: xxxx
|
|||
|
|
|||
|
<?xml version="1.0" encoding="utf-8" ?>
|
|||
|
<d:propertybehavior xmlns:d="DAV:">
|
|||
|
<d:keepalive>*</d:keepalive>
|
|||
|
</d:propertybehavior>
|
|||
|
|
|||
|
>>Response
|
|||
|
|
|||
|
HTTP/1.1 207 Multi-Status
|
|||
|
Content-Type: text/xml; charset="utf-8"
|
|||
|
Content-Length: xxxx
|
|||
|
|
|||
|
<?xml version="1.0" encoding="utf-8" ?>
|
|||
|
<d:multistatus xmlns:d="DAV:">
|
|||
|
<d:response>
|
|||
|
<d:href>http://www.foo.bar/othercontainer/R2/</d:href>
|
|||
|
<d:status>HTTP/1.1 412 Precondition Failed</d:status>
|
|||
|
</d:response>
|
|||
|
</d:multistatus>
|
|||
|
|
|||
|
The Depth header is unnecessary as the default behavior of COPY on a
|
|||
|
collection is to act as if a "Depth: infinity" header had been
|
|||
|
submitted. In this example most of the resources, along with the
|
|||
|
collection, were copied successfully. However the collection R2
|
|||
|
failed, most likely due to a problem with maintaining the liveness of
|
|||
|
properties (this is specified by the propertybehavior XML element).
|
|||
|
Because there was an error copying R2, none of R2's members were
|
|||
|
copied. However no errors were listed for those members due to the
|
|||
|
error minimization rules given in section 8.8.3.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 41]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
8.9 MOVE Method
|
|||
|
|
|||
|
The MOVE operation on a non-collection resource is the logical
|
|||
|
equivalent of a copy (COPY), followed by consistency maintenance
|
|||
|
processing, followed by a delete of the source, where all three
|
|||
|
actions are performed atomically. The consistency maintenance step
|
|||
|
allows the server to perform updates caused by the move, such as
|
|||
|
updating all URIs other than the Request-URI which identify the
|
|||
|
source resource, to point to the new destination resource.
|
|||
|
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 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 same
|
|||
|
server.
|
|||
|
|
|||
|
If a resource exists at the destination, the destination resource
|
|||
|
will be DELETEd as a side-effect of the MOVE operation, subject to
|
|||
|
the restrictions of the Overwrite header.
|
|||
|
|
|||
|
8.9.1 MOVE for Properties
|
|||
|
|
|||
|
The behavior of properties on a MOVE, including the effects of the
|
|||
|
propertybehavior XML element, MUST be the same as specified in
|
|||
|
section 8.8.2.
|
|||
|
|
|||
|
8.9.2 MOVE for Collections
|
|||
|
|
|||
|
A MOVE with "Depth: infinity" instructs that the collection
|
|||
|
identified by the Request-URI be moved to the URI specified in the
|
|||
|
Destination header, and all resources identified by its internal
|
|||
|
member URIs are to be moved to locations relative to it, recursively
|
|||
|
through all levels of the collection hierarchy.
|
|||
|
|
|||
|
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
|
|||
|
MOVE on a collection with any value but "infinity".
|
|||
|
|
|||
|
Any headers included with MOVE MUST be applied in processing every
|
|||
|
resource to be moved with the exception of the Destination header.
|
|||
|
|
|||
|
The behavior of the Destination header is the same as given for COPY
|
|||
|
on collections.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 42]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
When the MOVE method has completed processing it MUST have created a
|
|||
|
consistent namespace at both the source and destination (see section
|
|||
|
5.1 for the definition of namespace consistency). However, if an
|
|||
|
error occurs while moving an internal collection, the server MUST NOT
|
|||
|
move any resources identified by members of the failed collection
|
|||
|
(i.e., the server must skip the error-causing subtree), as this would
|
|||
|
create an inconsistent namespace. In this case, after detecting the
|
|||
|
error, the move operation SHOULD try to finish as much of the
|
|||
|
original move as possible (i.e., the server should still attempt to
|
|||
|
move other subtrees and the resources identified by their members,
|
|||
|
that are not descendents of an error-causing collection). So, for
|
|||
|
example, if an infinite depth move is performed on collection /a/,
|
|||
|
which contains collections /a/b/ and /a/c/, and an error occurs
|
|||
|
moving /a/b/, an attempt should still be made to try moving /a/c/.
|
|||
|
Similarly, after encountering an error moving a non-collection
|
|||
|
resource as part of an infinite depth move, the server SHOULD try to
|
|||
|
finish as much of the original move operation as possible.
|
|||
|
|
|||
|
If an error occurs with a resource other than the resource identified
|
|||
|
in the Request-URI then the response MUST be a 207 (Multi-Status).
|
|||
|
|
|||
|
The 424 (Failed Dependency) status code SHOULD NOT be returned in the
|
|||
|
207 (Multi-Status) response from a MOVE method. These errors 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 for the
|
|||
|
parent. Additionally 201 (Created)/204 (No Content) responses SHOULD
|
|||
|
NOT be returned as values in 207 (Multi-Status) responses from a
|
|||
|
MOVE. These responses can be safely omitted because they are the
|
|||
|
default success codes.
|
|||
|
|
|||
|
8.9.3 MOVE and the Overwrite Header
|
|||
|
|
|||
|
If a resource exists at the destination and the Overwrite header is
|
|||
|
"T" then prior to performing the move the server MUST perform a
|
|||
|
DELETE with "Depth: infinity" on the destination resource. If the
|
|||
|
Overwrite header is set to "F" then the operation will fail.
|
|||
|
|
|||
|
8.9.4 Status Codes
|
|||
|
|
|||
|
201 (Created) - The source resource was successfully moved, and a new
|
|||
|
resource was created at the destination.
|
|||
|
|
|||
|
204 (No Content) - The source resource was successfully moved to a
|
|||
|
pre-existing destination resource.
|
|||
|
|
|||
|
403 (Forbidden) _ The source and destination URIs are the same.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 43]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
409 (Conflict) _ A resource cannot be created at the destination
|
|||
|
until one or more intermediate collections have been created.
|
|||
|
|
|||
|
412 (Precondition Failed) - The server was unable to maintain the
|
|||
|
liveness of the properties listed in the propertybehavior XML element
|
|||
|
or the Overwrite header is "F" and the state of the destination
|
|||
|
resource is non-null.
|
|||
|
|
|||
|
423 (Locked) - The source or the destination resource was locked.
|
|||
|
|
|||
|
502 (Bad Gateway) - This may occur when the destination is on another
|
|||
|
server and the destination server refuses to accept the resource.
|
|||
|
|
|||
|
8.9.5 Example - MOVE of a Non-Collection
|
|||
|
|
|||
|
This example shows resource
|
|||
|
http://www.ics.uci.edu/~fielding/index.html being moved to the
|
|||
|
location http://www.ics.uci.edu/users/f/fielding/index.html. The
|
|||
|
contents of the destination resource would have been overwritten if
|
|||
|
the destination resource had been non-null. In this case, since
|
|||
|
there was nothing at the destination resource, the response code is
|
|||
|
201 (Created).
|
|||
|
|
|||
|
>>Request
|
|||
|
|
|||
|
MOVE /~fielding/index.html HTTP/1.1
|
|||
|
Host: www.ics.uci.edu
|
|||
|
Destination: http://www.ics.uci.edu/users/f/fielding/index.html
|
|||
|
|
|||
|
>>Response
|
|||
|
|
|||
|
HTTP/1.1 201 Created
|
|||
|
Location: http://www.ics.uci.edu/users/f/fielding/index.html
|
|||
|
|
|||
|
|
|||
|
8.9.6 Example - MOVE of a Collection
|
|||
|
|
|||
|
>>Request
|
|||
|
|
|||
|
MOVE /container/ HTTP/1.1
|
|||
|
Host: www.foo.bar
|
|||
|
Destination: http://www.foo.bar/othercontainer/
|
|||
|
Overwrite: F
|
|||
|
If: (<opaquelocktoken:fe184f2e-6eec-41d0-c765-01adc56e6bb4>)
|
|||
|
(<opaquelocktoken:e454f3f3-acdc-452a-56c7-00a5c91e4b77>)
|
|||
|
Content-Type: text/xml; charset="utf-8"
|
|||
|
Content-Length: xxxx
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 44]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
<?xml version="1.0" encoding="utf-8" ?>
|
|||
|
<d:propertybehavior xmlns:d='DAV:'>
|
|||
|
<d:keepalive>*</d:keepalive>
|
|||
|
</d:propertybehavior>
|
|||
|
|
|||
|
>>Response
|
|||
|
|
|||
|
HTTP/1.1 207 Multi-Status
|
|||
|
Content-Type: text/xml; charset="utf-8"
|
|||
|
Content-Length: xxxx
|
|||
|
|
|||
|
<?xml version="1.0" encoding="utf-8" ?>
|
|||
|
<d:multistatus xmlns:d='DAV:'>
|
|||
|
<d:response>
|
|||
|
<d:href>http://www.foo.bar/othercontainer/C2/</d:href>
|
|||
|
<d:status>HTTP/1.1 423 Locked</d:status>
|
|||
|
</d:response>
|
|||
|
</d:multistatus>
|
|||
|
|
|||
|
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
|
|||
|
resource, both source and destination, anywhere in the scope of the
|
|||
|
method, that is locked. In this case the proper lock token was not
|
|||
|
submitted for the destination http://www.foo.bar/othercontainer/C2/.
|
|||
|
This means that the resource /container/C2/ could not be moved.
|
|||
|
Because there was an error copying /container/C2/, none of
|
|||
|
/container/C2's members were copied. However no errors were listed
|
|||
|
for those members due to the error minimization rules given in
|
|||
|
section 8.8.3. User agent authentication has previously occurred via
|
|||
|
a mechanism outside the scope of the HTTP protocol, in an underlying
|
|||
|
transport layer.
|
|||
|
|
|||
|
8.10 LOCK Method
|
|||
|
|
|||
|
The following sections describe the LOCK method, which is used to
|
|||
|
take out a lock of any access type. These sections on the LOCK
|
|||
|
method describe only those semantics that are specific to the LOCK
|
|||
|
method and are independent of the access type of the lock being
|
|||
|
requested.
|
|||
|
|
|||
|
Any resource which supports the LOCK method MUST, at minimum, support
|
|||
|
the XML request and response formats defined herein.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 45]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
8.10.1 Operation
|
|||
|
|
|||
|
A LOCK method invocation creates the lock specified by the lockinfo
|
|||
|
XML element on the Request-URI. Lock method requests SHOULD have a
|
|||
|
XML request body which contains an owner XML element for this lock
|
|||
|
request, unless this is a refresh request. The LOCK request may have
|
|||
|
a Timeout header.
|
|||
|
|
|||
|
Clients MUST assume that locks may arbitrarily disappear at any time,
|
|||
|
regardless of the value given in the Timeout header. The Timeout
|
|||
|
header only indicates the behavior of the server if "extraordinary"
|
|||
|
circumstances do not occur. For example, an administrator may remove
|
|||
|
a lock at any time or the system may crash in such a way that it
|
|||
|
loses the record of the lock's existence. The response MUST contain
|
|||
|
the value of the lockdiscovery property in a prop XML element.
|
|||
|
|
|||
|
In order to indicate the lock token associated with a newly created
|
|||
|
lock, a Lock-Token response header MUST be included in the response
|
|||
|
for every successful LOCK request for a new lock. Note that the
|
|||
|
Lock-Token header would not be returned in the response for a
|
|||
|
successful refresh LOCK request because a new lock was not created.
|
|||
|
|
|||
|
8.10.2 The Effect of Locks on Properties and Collections
|
|||
|
|
|||
|
The scope of a lock is the entire state of the resource, including
|
|||
|
its body and associated properties. As a result, a lock on a
|
|||
|
resource MUST also lock the resource's properties.
|
|||
|
|
|||
|
For collections, a lock also affects the ability to add or remove
|
|||
|
members. The nature of the effect depends upon the type of access
|
|||
|
control involved.
|
|||
|
|
|||
|
8.10.3 Locking Replicated Resources
|
|||
|
|
|||
|
A resource may be made available through more than one URI. However
|
|||
|
locks apply to resources, not URIs. Therefore a LOCK request on a
|
|||
|
resource MUST NOT succeed if can not be honored by all the URIs
|
|||
|
through which the resource is addressable.
|
|||
|
|
|||
|
8.10.4 Depth and Locking
|
|||
|
|
|||
|
The Depth header may be used with the LOCK method. Values other than
|
|||
|
0 or infinity MUST NOT be used with the Depth header on a LOCK
|
|||
|
method. All resources that support the LOCK method MUST support the
|
|||
|
Depth header.
|
|||
|
|
|||
|
A Depth header of value 0 means to just lock the resource specified
|
|||
|
by the Request-URI.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 46]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
If the Depth header is set to infinity then the resource specified in
|
|||
|
the Request-URI along with all its internal members, all the way down
|
|||
|
the hierarchy, are to be locked. A successful result MUST return a
|
|||
|
single lock token which represents all the resources that have been
|
|||
|
locked. If an UNLOCK is successfully executed on this token, all
|
|||
|
associated resources are unlocked. If the lock cannot be granted to
|
|||
|
all resources, a 409 (Conflict) status code MUST be returned with a
|
|||
|
response entity body containing a multistatus XML element describing
|
|||
|
which resource(s) prevented the lock from being granted. Hence,
|
|||
|
partial success is not an option. Either the entire hierarchy is
|
|||
|
locked or no resources are locked.
|
|||
|
|
|||
|
If no Depth header is submitted on a LOCK request then the request
|
|||
|
MUST act as if a "Depth:infinity" had been submitted.
|
|||
|
|
|||
|
8.10.5 Interaction with other Methods
|
|||
|
|
|||
|
The interaction of a LOCK with various methods is dependent upon the
|
|||
|
lock type. However, independent of lock type, a successful DELETE of
|
|||
|
a resource MUST cause all of its locks to be removed.
|
|||
|
|
|||
|
8.10.6 Lock Compatibility Table
|
|||
|
|
|||
|
The table below describes the behavior that occurs when a lock
|
|||
|
request is made on a resource.
|
|||
|
|
|||
|
Current lock state/ | Shared Lock | Exclusive
|
|||
|
Lock request | | Lock
|
|||
|
=====================+=================+==============
|
|||
|
None | True | True
|
|||
|
---------------------+-----------------+--------------
|
|||
|
Shared Lock | True | False
|
|||
|
---------------------+-----------------+--------------
|
|||
|
Exclusive Lock | False | False*
|
|||
|
------------------------------------------------------
|
|||
|
|
|||
|
Legend: True = lock may be granted. False = lock MUST NOT be
|
|||
|
granted. *=It is illegal for a principal to request the same lock
|
|||
|
twice.
|
|||
|
|
|||
|
The current lock state of a resource is given in the leftmost column,
|
|||
|
and lock requests are listed in the first row. The 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 exclusive lock is
|
|||
|
requested, the table entry is "false", indicating the lock must not
|
|||
|
be granted.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 47]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
8.10.7 Status Codes
|
|||
|
|
|||
|
200 (OK) - The lock request succeeded and the value of the
|
|||
|
lockdiscovery property is included in the body.
|
|||
|
|
|||
|
412 (Precondition Failed) - The included lock token was not
|
|||
|
enforceable on this resource or the server could not satisfy the
|
|||
|
request in the lockinfo XML element.
|
|||
|
|
|||
|
423 (Locked) - The resource is locked, so the method has been
|
|||
|
rejected.
|
|||
|
|
|||
|
8.10.8 Example - Simple Lock Request
|
|||
|
|
|||
|
>>Request
|
|||
|
|
|||
|
LOCK /workspace/webdav/proposal.doc HTTP/1.1
|
|||
|
Host: webdav.sb.aol.com
|
|||
|
Timeout: Infinite, Second-4100000000
|
|||
|
Content-Type: text/xml; charset="utf-8"
|
|||
|
Content-Length: xxxx
|
|||
|
Authorization: Digest username="ejw",
|
|||
|
realm="ejw@webdav.sb.aol.com", nonce="...",
|
|||
|
uri="/workspace/webdav/proposal.doc",
|
|||
|
response="...", opaque="..."
|
|||
|
|
|||
|
<?xml version="1.0" encoding="utf-8" ?>
|
|||
|
<D:lockinfo xmlns:D='DAV:'>
|
|||
|
<D:lockscope><D:exclusive/></D:lockscope>
|
|||
|
<D:locktype><D:write/></D:locktype>
|
|||
|
<D:owner>
|
|||
|
<D:href>http://www.ics.uci.edu/~ejw/contact.html</D:href>
|
|||
|
</D:owner>
|
|||
|
</D:lockinfo>
|
|||
|
|
|||
|
>>Response
|
|||
|
|
|||
|
HTTP/1.1 200 OK
|
|||
|
Content-Type: text/xml; charset="utf-8"
|
|||
|
Content-Length: xxxx
|
|||
|
|
|||
|
<?xml version="1.0" encoding="utf-8" ?>
|
|||
|
<D:prop xmlns:D="DAV:">
|
|||
|
<D:lockdiscovery>
|
|||
|
<D:activelock>
|
|||
|
<D:locktype><D:write/></D:locktype>
|
|||
|
<D:lockscope><D:exclusive/></D:lockscope>
|
|||
|
<D:depth>Infinity</D:depth>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 48]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
<D:owner>
|
|||
|
<D:href>
|
|||
|
http://www.ics.uci.edu/~ejw/contact.html
|
|||
|
</D:href>
|
|||
|
</D:owner>
|
|||
|
<D:timeout>Second-604800</D:timeout>
|
|||
|
<D:locktoken>
|
|||
|
<D:href>
|
|||
|
opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4
|
|||
|
</D:href>
|
|||
|
</D:locktoken>
|
|||
|
</D:activelock>
|
|||
|
</D:lockdiscovery>
|
|||
|
</D:prop>
|
|||
|
|
|||
|
This example shows the successful creation of an exclusive write lock
|
|||
|
on resource http://webdav.sb.aol.com/workspace/webdav/proposal.doc.
|
|||
|
The resource http://www.ics.uci.edu/~ejw/contact.html contains
|
|||
|
contact information for the owner of the lock. The server has an
|
|||
|
activity-based timeout policy in place on this resource, which causes
|
|||
|
the lock to automatically be removed after 1 week (604800 seconds).
|
|||
|
Note that the nonce, response, and opaque fields have not been
|
|||
|
calculated in the Authorization request header.
|
|||
|
|
|||
|
8.10.9 Example - Refreshing a Write Lock
|
|||
|
|
|||
|
>>Request
|
|||
|
|
|||
|
LOCK /workspace/webdav/proposal.doc HTTP/1.1
|
|||
|
Host: webdav.sb.aol.com
|
|||
|
Timeout: Infinite, Second-4100000000
|
|||
|
If: (<opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>)
|
|||
|
Authorization: Digest username="ejw",
|
|||
|
realm="ejw@webdav.sb.aol.com", nonce="...",
|
|||
|
uri="/workspace/webdav/proposal.doc",
|
|||
|
response="...", opaque="..."
|
|||
|
|
|||
|
>>Response
|
|||
|
|
|||
|
HTTP/1.1 200 OK
|
|||
|
Content-Type: text/xml; charset="utf-8"
|
|||
|
Content-Length: xxxx
|
|||
|
|
|||
|
<?xml version="1.0" encoding="utf-8" ?>
|
|||
|
<D:prop xmlns:D="DAV:">
|
|||
|
<D:lockdiscovery>
|
|||
|
<D:activelock>
|
|||
|
<D:locktype><D:write/></D:locktype>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 49]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
<D:lockscope><D:exclusive/></D:lockscope>
|
|||
|
<D:depth>Infinity</D:depth>
|
|||
|
<D:owner>
|
|||
|
<D:href>
|
|||
|
http://www.ics.uci.edu/~ejw/contact.html
|
|||
|
</D:href>
|
|||
|
</D:owner>
|
|||
|
<D:timeout>Second-604800</D:timeout>
|
|||
|
<D:locktoken>
|
|||
|
<D:href>
|
|||
|
opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4
|
|||
|
</D:href>
|
|||
|
</D:locktoken>
|
|||
|
</D:activelock>
|
|||
|
</D:lockdiscovery>
|
|||
|
</D:prop>
|
|||
|
|
|||
|
This request would refresh the lock, resetting any time outs. Notice
|
|||
|
that the client asked for an infinite time out but the server choose
|
|||
|
to ignore the request. In this example, the nonce, response, and
|
|||
|
opaque fields have not been calculated in the Authorization request
|
|||
|
header.
|
|||
|
|
|||
|
8.10.10 Example - Multi-Resource Lock Request
|
|||
|
|
|||
|
>>Request
|
|||
|
|
|||
|
LOCK /webdav/ HTTP/1.1
|
|||
|
Host: webdav.sb.aol.com
|
|||
|
Timeout: Infinite, Second-4100000000
|
|||
|
Depth: infinity
|
|||
|
Content-Type: text/xml; charset="utf-8"
|
|||
|
Content-Length: xxxx
|
|||
|
Authorization: Digest username="ejw",
|
|||
|
realm="ejw@webdav.sb.aol.com", nonce="...",
|
|||
|
uri="/workspace/webdav/proposal.doc",
|
|||
|
response="...", opaque="..."
|
|||
|
|
|||
|
<?xml version="1.0" encoding="utf-8" ?>
|
|||
|
<D:lockinfo xmlns:D="DAV:">
|
|||
|
<D:locktype><D:write/></D:locktype>
|
|||
|
<D:lockscope><D:exclusive/></D:lockscope>
|
|||
|
<D:owner>
|
|||
|
<D:href>http://www.ics.uci.edu/~ejw/contact.html</D:href>
|
|||
|
</D:owner>
|
|||
|
</D:lockinfo>
|
|||
|
|
|||
|
>>Response
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 50]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
HTTP/1.1 207 Multi-Status
|
|||
|
Content-Type: text/xml; charset="utf-8"
|
|||
|
Content-Length: xxxx
|
|||
|
|
|||
|
<?xml version="1.0" encoding="utf-8" ?>
|
|||
|
<D:multistatus xmlns:D="DAV:">
|
|||
|
<D:response>
|
|||
|
<D:href>http://webdav.sb.aol.com/webdav/secret</D:href>
|
|||
|
<D:status>HTTP/1.1 403 Forbidden</D:status>
|
|||
|
</D:response>
|
|||
|
<D:response>
|
|||
|
<D:href>http://webdav.sb.aol.com/webdav/</D:href>
|
|||
|
<D:propstat>
|
|||
|
<D:prop><D:lockdiscovery/></D:prop>
|
|||
|
<D:status>HTTP/1.1 424 Failed Dependency</D:status>
|
|||
|
</D:propstat>
|
|||
|
</D:response>
|
|||
|
</D:multistatus>
|
|||
|
|
|||
|
This example shows a request for an exclusive write lock on a
|
|||
|
collection and all its children. In this request, the client has
|
|||
|
specified that it desires an infinite length lock, if available,
|
|||
|
otherwise a timeout of 4.1 billion seconds, if available. The request
|
|||
|
entity body contains the contact information for the principal taking
|
|||
|
out the lock, in this case a web page URL.
|
|||
|
|
|||
|
The error is a 403 (Forbidden) response on the resource
|
|||
|
http://webdav.sb.aol.com/webdav/secret. Because this resource could
|
|||
|
not be locked, none of the resources were locked. Note also that the
|
|||
|
lockdiscovery property for the Request-URI has been included as
|
|||
|
required. In this example the lockdiscovery property is empty which
|
|||
|
means that there are no outstanding locks on the resource.
|
|||
|
|
|||
|
In this example, the nonce, response, and opaque fields have not been
|
|||
|
calculated in the Authorization request header.
|
|||
|
|
|||
|
8.11 UNLOCK Method
|
|||
|
|
|||
|
The UNLOCK method removes the lock identified by the lock token in
|
|||
|
the Lock-Token request header from the Request-URI, and all other
|
|||
|
resources included in the lock. If all resources which have been
|
|||
|
locked under the submitted lock token can not be unlocked then the
|
|||
|
UNLOCK request MUST fail.
|
|||
|
|
|||
|
Any DAV compliant resource which supports the LOCK method MUST
|
|||
|
support the UNLOCK method.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 51]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
8.11.1 Example - UNLOCK
|
|||
|
|
|||
|
>>Request
|
|||
|
|
|||
|
UNLOCK /workspace/webdav/info.doc HTTP/1.1
|
|||
|
Host: webdav.sb.aol.com
|
|||
|
Lock-Token: <opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7>
|
|||
|
Authorization: Digest username="ejw",
|
|||
|
realm="ejw@webdav.sb.aol.com", nonce="...",
|
|||
|
uri="/workspace/webdav/proposal.doc",
|
|||
|
response="...", opaque="..."
|
|||
|
|
|||
|
>>Response
|
|||
|
|
|||
|
HTTP/1.1 204 No Content
|
|||
|
|
|||
|
In this example, the lock identified by the lock token
|
|||
|
"opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is
|
|||
|
successfully removed from the resource
|
|||
|
http://webdav.sb.aol.com/workspace/webdav/info.doc. If this lock
|
|||
|
included more than just one resource, the lock is removed from all
|
|||
|
resources included in the lock. The 204 (No Content) status code is
|
|||
|
used instead of 200 (OK) because there is no response entity body.
|
|||
|
|
|||
|
In this example, the nonce, response, and opaque fields have not been
|
|||
|
calculated in the Authorization request header.
|
|||
|
|
|||
|
9 HTTP Headers for Distributed Authoring
|
|||
|
|
|||
|
9.1 DAV Header
|
|||
|
|
|||
|
DAV = "DAV" ":" "1" ["," "2"] ["," 1#extend]
|
|||
|
|
|||
|
This header indicates that the resource supports the DAV schema and
|
|||
|
protocol as specified. All DAV compliant resources MUST return the
|
|||
|
DAV header on all OPTIONS responses.
|
|||
|
|
|||
|
The value is a list of all compliance classes that the resource
|
|||
|
supports. Note that above a comma has already been added to the 2.
|
|||
|
This is because a resource can not be level 2 compliant unless it is
|
|||
|
also level 1 compliant. Please refer to section 15 for more details.
|
|||
|
In general, however, support for one compliance class does not entail
|
|||
|
support for any other.
|
|||
|
|
|||
|
9.2 Depth Header
|
|||
|
|
|||
|
Depth = "Depth" ":" ("0" | "1" | "infinity")
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 52]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
The Depth header is used with methods executed on resources which
|
|||
|
could potentially have internal members to indicate whether the
|
|||
|
method is to be applied only to the resource ("Depth: 0"), to the
|
|||
|
resource and its immediate children, ("Depth: 1"), or the resource
|
|||
|
and all its progeny ("Depth: infinity").
|
|||
|
|
|||
|
The Depth header is only supported if a method's definition
|
|||
|
explicitly provides for such support.
|
|||
|
|
|||
|
The following rules are the default behavior for any method that
|
|||
|
supports the Depth header. A method may override these defaults by
|
|||
|
defining different behavior in its definition.
|
|||
|
|
|||
|
Methods which support the Depth header may choose not to support all
|
|||
|
of the header's values and may define, on a case by case basis, the
|
|||
|
behavior of the method if a Depth header is not present. For example,
|
|||
|
the MOVE method only supports "Depth: infinity" and if a Depth header
|
|||
|
is not present will act as if a "Depth: infinity" header had been
|
|||
|
applied.
|
|||
|
|
|||
|
Clients MUST NOT rely upon methods executing on members of their
|
|||
|
hierarchies in any particular order or on the execution being atomic
|
|||
|
unless the particular method explicitly provides such guarantees.
|
|||
|
|
|||
|
Upon execution, a method with a Depth header will perform as much of
|
|||
|
its assigned task as possible and then return a response specifying
|
|||
|
what it was able to accomplish and what it failed to do.
|
|||
|
|
|||
|
So, for example, an attempt to COPY a hierarchy may result in some of
|
|||
|
the members being copied and some not.
|
|||
|
|
|||
|
Any headers on a method that has a defined interaction with the Depth
|
|||
|
header MUST be applied to all resources in the scope of the method
|
|||
|
except where alternative behavior is explicitly defined. For example,
|
|||
|
an If-Match header will have its value applied against every resource
|
|||
|
in the method's scope and will cause the method to fail if the header
|
|||
|
fails to match.
|
|||
|
|
|||
|
If a resource, source or destination, within the scope of the method
|
|||
|
with a Depth header is locked in such a way as to prevent the
|
|||
|
successful execution of the method, then the lock token for that
|
|||
|
resource MUST be submitted with the request in the If request header.
|
|||
|
|
|||
|
The Depth header only specifies the behavior of the method with
|
|||
|
regards to internal children. If a resource does not have internal
|
|||
|
children then the Depth header MUST be ignored.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 53]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
Please note, however, that it is always an error to submit a value
|
|||
|
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 not
|
|||
|
have internal members, will result in a 400 (Bad Request). The method
|
|||
|
should fail not because the resource doesn't have internal members,
|
|||
|
but because of the illegal value in the header.
|
|||
|
|
|||
|
9.3 Destination Header
|
|||
|
|
|||
|
Destination = "Destination" ":" absoluteURI
|
|||
|
|
|||
|
The Destination header specifies the URI which identifies a
|
|||
|
destination resource for methods such as COPY and MOVE, which take
|
|||
|
two URIs as parameters. Note that the absoluteURI production is
|
|||
|
defined in [RFC2396].
|
|||
|
|
|||
|
9.4 If Header
|
|||
|
|
|||
|
If = "If" ":" ( 1*No-tag-list | 1*Tagged-list)
|
|||
|
No-tag-list = List
|
|||
|
Tagged-list = Resource 1*List
|
|||
|
Resource = Coded-URL
|
|||
|
List = "(" 1*(["Not"](State-token | "[" entity-tag "]")) ")"
|
|||
|
State-token = Coded-URL
|
|||
|
Coded-URL = "<" absoluteURI ">"
|
|||
|
|
|||
|
The If header is intended to have similar functionality to 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
|
|||
|
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
|
|||
|
lock tokens are the only state tokens defined in this specification.
|
|||
|
|
|||
|
All DAV compliant resources MUST honor the If header.
|
|||
|
|
|||
|
The If header's purpose is to describe a series of state lists. If
|
|||
|
the state of the resource to which the header is applied does not
|
|||
|
match any of the specified state lists then the request MUST fail
|
|||
|
with a 412 (Precondition Failed). If one of the described state
|
|||
|
lists matches the state of the resource then the request may succeed.
|
|||
|
|
|||
|
Note that the absoluteURI production is defined in [RFC2396].
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 54]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
9.4.1 No-tag-list Production
|
|||
|
|
|||
|
The No-tag-list production describes a series of state tokens and
|
|||
|
ETags. If multiple No-tag-list productions are used then one only
|
|||
|
needs to match the state of the resource for the method to be allowed
|
|||
|
to continue.
|
|||
|
|
|||
|
If a method, due to the presence of a Depth or Destination header, is
|
|||
|
applied to multiple resources then the No-tag-list production MUST be
|
|||
|
applied to each resource the method is applied to.
|
|||
|
|
|||
|
9.4.1.1 Example - No-tag-list If Header
|
|||
|
|
|||
|
If: (<locktoken:a-write-lock-token> ["I am an ETag"]) (["I am another
|
|||
|
ETag"])
|
|||
|
|
|||
|
The previous header would require that any resources within the scope
|
|||
|
of the method must either be locked with the specified lock token and
|
|||
|
in the state identified by the "I am an ETag" ETag or in the state
|
|||
|
identified by the second ETag "I am another ETag". To put the matter
|
|||
|
more plainly one can think of the previous If header as being in the
|
|||
|
form (or (and <locktoken:a-write-lock-token> ["I am an ETag"]) (and
|
|||
|
["I am another ETag"])).
|
|||
|
|
|||
|
9.4.2 Tagged-list Production
|
|||
|
|
|||
|
The tagged-list production scopes a list production. That is, it
|
|||
|
specifies that the lists following the resource specification only
|
|||
|
apply to the specified resource. The scope of the resource
|
|||
|
production begins with the list production immediately following the
|
|||
|
resource production and ends with the next resource production, if
|
|||
|
any.
|
|||
|
|
|||
|
When the If header is applied to a particular resource, the Tagged-
|
|||
|
list productions MUST be searched to determine if any of the listed
|
|||
|
resources match the operand resource(s) for the current method. If
|
|||
|
none of the resource productions match the current resource then the
|
|||
|
header MUST be ignored. If one of the resource productions does
|
|||
|
match the name of the resource under consideration then the list
|
|||
|
productions following the resource production MUST be applied to the
|
|||
|
resource in the manner specified in the previous section.
|
|||
|
|
|||
|
The same URI MUST NOT appear more than once in a resource production
|
|||
|
in an If header.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 55]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
9.4.2.1 Example - Tagged List If header
|
|||
|
|
|||
|
COPY /resource1 HTTP/1.1
|
|||
|
Host: www.foo.bar
|
|||
|
Destination: http://www.foo.bar/resource2
|
|||
|
If: <http://www.foo.bar/resource1> (<locktoken:a-write-lock-token>
|
|||
|
[W/"A weak ETag"]) (["strong ETag"])
|
|||
|
<http://www.bar.bar/random>(["another strong ETag"])
|
|||
|
|
|||
|
In this example http://www.foo.bar/resource1 is being copied to
|
|||
|
http://www.foo.bar/resource2. When the method is first applied to
|
|||
|
http://www.foo.bar/resource1, resource1 must be in the state
|
|||
|
specified by "(<locktoken:a-write-lock-token> [W/"A weak ETag"])
|
|||
|
(["strong ETag"])", that is, it either must be locked with a lock
|
|||
|
token of "locktoken:a-write-lock-token" and have a weak entity tag
|
|||
|
W/"A weak ETag" or it must have a strong entity tag "strong ETag".
|
|||
|
|
|||
|
That is the only success condition since the resource
|
|||
|
http://www.bar.bar/random never has the method applied to it (the
|
|||
|
only other resource listed in the If header) and
|
|||
|
http://www.foo.bar/resource2 is not listed in the If header.
|
|||
|
|
|||
|
9.4.3 not Production
|
|||
|
|
|||
|
Every state token or ETag is either current, and hence describes the
|
|||
|
state of a resource, or is not current, and does not describe the
|
|||
|
state of a resource. The boolean operation of matching a state token
|
|||
|
or ETag to the current state of a resource thus resolves to a true or
|
|||
|
false value. The not production is used to reverse that value. The
|
|||
|
scope of the not production is the state-token or entity-tag
|
|||
|
immediately following it.
|
|||
|
|
|||
|
If: (Not <locktoken:write1> <locktoken:write2>)
|
|||
|
|
|||
|
When submitted with a request, this If header requires that all
|
|||
|
operand resources must not be locked with locktoken:write1 and must
|
|||
|
be locked with locktoken:write2.
|
|||
|
|
|||
|
9.4.4 Matching Function
|
|||
|
|
|||
|
When performing If header processing, the definition of a matching
|
|||
|
state token or entity tag is as follows.
|
|||
|
|
|||
|
Matching entity tag: Where the entity tag matches an entity tag
|
|||
|
associated with that resource.
|
|||
|
|
|||
|
Matching state token: Where there is an exact match between the state
|
|||
|
token in the If header and any state token on the resource.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 56]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
9.4.5 If Header and Non-DAV Compliant Proxies
|
|||
|
|
|||
|
Non-DAV compliant proxies will not honor the If header, since they
|
|||
|
will not understand the If header, and HTTP requires non-understood
|
|||
|
headers to be ignored. When communicating with HTTP/1.1 proxies, the
|
|||
|
"Cache-Control: no-cache" request header MUST be used so as to
|
|||
|
prevent the proxy from improperly trying to service the request from
|
|||
|
its cache. When dealing with HTTP/1.0 proxies the "Pragma: no-cache"
|
|||
|
request header MUST be used for the same reason.
|
|||
|
|
|||
|
9.5 Lock-Token Header
|
|||
|
|
|||
|
Lock-Token = "Lock-Token" ":" Coded-URL
|
|||
|
|
|||
|
The Lock-Token request header is used with the UNLOCK method to
|
|||
|
identify the lock to be removed. The lock token in the Lock-Token
|
|||
|
request header MUST identify a lock that contains the resource
|
|||
|
identified by Request-URI as a member.
|
|||
|
|
|||
|
The Lock-Token response header is used with the LOCK method to
|
|||
|
indicate the lock token created as a result of a successful LOCK
|
|||
|
request to create a new lock.
|
|||
|
|
|||
|
9.6 Overwrite Header
|
|||
|
|
|||
|
Overwrite = "Overwrite" ":" ("T" | "F")
|
|||
|
|
|||
|
The Overwrite header specifies whether the server should overwrite
|
|||
|
the state of a non-null destination resource during a COPY or MOVE.
|
|||
|
A value of "F" states that the server must not perform the COPY or
|
|||
|
MOVE operation if the state of the destination resource is non-null.
|
|||
|
If the overwrite header is not included in a COPY or MOVE request
|
|||
|
then the resource MUST treat the request as if it has an overwrite
|
|||
|
header of value "T". While the Overwrite header appears to duplicate
|
|||
|
the functionality of the If-Match: * header of HTTP/1.1, If-Match
|
|||
|
applies only to the Request-URI, and not to the Destination of a COPY
|
|||
|
or MOVE.
|
|||
|
|
|||
|
If a COPY or MOVE is not performed due to the value of the Overwrite
|
|||
|
header, the method MUST fail with a 412 (Precondition Failed) status
|
|||
|
code.
|
|||
|
|
|||
|
All DAV compliant resources MUST support the Overwrite header.
|
|||
|
|
|||
|
9.7 Status-URI Response Header
|
|||
|
|
|||
|
The Status-URI response header may be used with the 102 (Processing)
|
|||
|
status code to inform the client as to the status of a method.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 57]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
Status-URI = "Status-URI" ":" *(Status-Code Coded-URL) ; Status-Code
|
|||
|
is defined in 6.1.1 of [RFC2068]
|
|||
|
|
|||
|
The URIs listed in the header are source resources which have been
|
|||
|
affected by the outstanding method. The status code indicates the
|
|||
|
resolution of the method on the identified resource. So, for
|
|||
|
example, if a MOVE method on a collection is outstanding and a 102
|
|||
|
(Processing) response with a Status-URI response header is returned,
|
|||
|
the included URIs will indicate resources that have had move
|
|||
|
attempted on them and what the result was.
|
|||
|
|
|||
|
9.8 Timeout Request Header
|
|||
|
|
|||
|
TimeOut = "Timeout" ":" 1#TimeType
|
|||
|
TimeType = ("Second-" DAVTimeOutVal | "Infinite" | Other)
|
|||
|
DAVTimeOutVal = 1*digit
|
|||
|
Other = "Extend" field-value ; See section 4.2 of [RFC2068]
|
|||
|
|
|||
|
Clients may include Timeout headers in their LOCK requests. However,
|
|||
|
the server is not required to honor or even consider these requests.
|
|||
|
Clients MUST NOT submit a Timeout request header with any method
|
|||
|
other than a LOCK method.
|
|||
|
|
|||
|
A Timeout request header MUST contain at least one TimeType and may
|
|||
|
contain multiple TimeType entries. The purpose of listing multiple
|
|||
|
TimeType entries is to indicate multiple different values and value
|
|||
|
types that are acceptable to the client. The client lists the
|
|||
|
TimeType entries in order of preference.
|
|||
|
|
|||
|
Timeout response values MUST use a Second value, Infinite, or a
|
|||
|
TimeType the client has indicated familiarity with. The server may
|
|||
|
assume a client is familiar with any TimeType submitted in a Timeout
|
|||
|
header.
|
|||
|
|
|||
|
The "Second" TimeType specifies the number of seconds that will
|
|||
|
elapse between granting of the lock at the server, and the automatic
|
|||
|
removal of the lock. The timeout value for TimeType "Second" MUST
|
|||
|
NOT be greater than 2^32-1.
|
|||
|
|
|||
|
The timeout counter SHOULD be restarted any time an owner of the lock
|
|||
|
sends a method to any member of the lock, including unsupported
|
|||
|
methods, or methods which are unsuccessful. However the lock MUST be
|
|||
|
refreshed if a refresh LOCK method is successfully received.
|
|||
|
|
|||
|
If the timeout expires then the lock may be lost. Specifically, if
|
|||
|
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
|
|||
|
resource using the lock token of the timed-out lock, performed with
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 58]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
its override authority. Thus logs should be updated with the
|
|||
|
disposition of the lock, notifications should be sent, etc., just as
|
|||
|
they would be for an UNLOCK request.
|
|||
|
|
|||
|
Servers are advised to pay close attention to the values submitted by
|
|||
|
clients, as they will be indicative of the type of activity the
|
|||
|
client intends to perform. For example, an applet running in a
|
|||
|
browser may need to lock a resource, but because of the instability
|
|||
|
of the environment within which the applet is running, the applet may
|
|||
|
be turned off without warning. As a result, the applet is likely to
|
|||
|
ask for a relatively small timeout value so that if the applet dies,
|
|||
|
the lock can be quickly harvested. However, a document management
|
|||
|
system is likely to ask for an extremely long timeout because its
|
|||
|
user may be planning on going off-line.
|
|||
|
|
|||
|
A client MUST NOT assume that just because the time-out has expired
|
|||
|
the lock has been lost.
|
|||
|
|
|||
|
10 Status Code Extensions to HTTP/1.1
|
|||
|
|
|||
|
The following status codes are added to those defined in HTTP/1.1
|
|||
|
[RFC2068].
|
|||
|
|
|||
|
10.1 102 Processing
|
|||
|
|
|||
|
The 102 (Processing) status code is an interim response used to
|
|||
|
inform the client that the server has accepted the complete request,
|
|||
|
but has not yet completed it. This status code SHOULD only be sent
|
|||
|
when the server has a reasonable expectation that the request will
|
|||
|
take significant time to complete. As guidance, if a method is taking
|
|||
|
longer than 20 seconds (a reasonable, but arbitrary value) to process
|
|||
|
the server SHOULD return a 102 (Processing) response. The server MUST
|
|||
|
send a final response after the request has been completed.
|
|||
|
|
|||
|
Methods can potentially take a long period of time to process,
|
|||
|
especially methods that support the Depth header. In such cases the
|
|||
|
client may time-out the connection while waiting for a response. To
|
|||
|
prevent this the server may return a 102 (Processing) status code to
|
|||
|
indicate to the client that the server is still processing the
|
|||
|
method.
|
|||
|
|
|||
|
10.2 207 Multi-Status
|
|||
|
|
|||
|
The 207 (Multi-Status) status code provides status for multiple
|
|||
|
independent operations (see section 11 for more information).
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 59]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
10.3 422 Unprocessable Entity
|
|||
|
|
|||
|
The 422 (Unprocessable Entity) status code means the server
|
|||
|
understands the content type of the request entity (hence a
|
|||
|
415(Unsupported Media Type) status code is inappropriate), and the
|
|||
|
syntax of the request entity is correct (thus a 400 (Bad Request)
|
|||
|
status code is inappropriate) but was unable to process the contained
|
|||
|
instructions. For example, this error condition may occur if an XML
|
|||
|
request body contains well-formed (i.e., syntactically correct), but
|
|||
|
semantically erroneous XML instructions.
|
|||
|
|
|||
|
10.4 423 Locked
|
|||
|
|
|||
|
The 423 (Locked) status code means the source or destination resource
|
|||
|
of a method is locked.
|
|||
|
|
|||
|
10.5 424 Failed Dependency
|
|||
|
|
|||
|
The 424 (Failed Dependency) status code means that the method could
|
|||
|
not be performed on the resource because the requested action
|
|||
|
depended on another action and that action failed. For example, if a
|
|||
|
command in a PROPPATCH method fails then, at minimum, the rest of the
|
|||
|
commands will also fail with 424 (Failed Dependency).
|
|||
|
|
|||
|
10.6 507 Insufficient Storage
|
|||
|
|
|||
|
The 507 (Insufficient Storage) status code means the method could not
|
|||
|
be performed on the resource because the server is unable to store
|
|||
|
the representation needed to successfully complete the request. This
|
|||
|
condition is considered to be temporary. If the request which
|
|||
|
received this status code was the result of a user action, the
|
|||
|
request MUST NOT be repeated until it is requested by a separate user
|
|||
|
action.
|
|||
|
|
|||
|
11 Multi-Status Response
|
|||
|
|
|||
|
The default 207 (Multi-Status) response body is a text/xml or
|
|||
|
application/xml HTTP entity that contains a single XML element called
|
|||
|
multistatus, which contains a set of XML elements called response
|
|||
|
which contain 200, 300, 400, and 500 series status codes generated
|
|||
|
during the method invocation. 100 series status codes SHOULD NOT be
|
|||
|
recorded in a response XML element.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 60]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
12 XML Element Definitions
|
|||
|
|
|||
|
In the section below, the final line of each section gives the
|
|||
|
element type declaration using the format defined in [REC-XML]. The
|
|||
|
"Value" field, where present, specifies further restrictions on the
|
|||
|
allowable contents of the XML element using BNF (i.e., to further
|
|||
|
restrict the values of a PCDATA element).
|
|||
|
|
|||
|
12.1 activelock XML Element
|
|||
|
|
|||
|
Name: activelock
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: Describes a lock on a resource.
|
|||
|
|
|||
|
<!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?,
|
|||
|
locktoken?) >
|
|||
|
|
|||
|
12.1.1 depth XML Element
|
|||
|
|
|||
|
Name: depth
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: The value of the Depth header.
|
|||
|
Value: "0" | "1" | "infinity"
|
|||
|
|
|||
|
<!ELEMENT depth (#PCDATA) >
|
|||
|
|
|||
|
12.1.2 locktoken XML Element
|
|||
|
|
|||
|
Name: locktoken
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: The lock token associated with a lock.
|
|||
|
Description: The href contains one or more opaque lock token URIs
|
|||
|
which all refer to the same lock (i.e., the OpaqueLockToken-URI
|
|||
|
production in section 6.4).
|
|||
|
|
|||
|
<!ELEMENT locktoken (href+) >
|
|||
|
|
|||
|
12.1.3 timeout XML Element
|
|||
|
|
|||
|
Name: timeout
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: The timeout associated with a lock
|
|||
|
Value: TimeType ;Defined in section 9.8
|
|||
|
|
|||
|
<!ELEMENT timeout (#PCDATA) >
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 61]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
12.2 collection XML Element
|
|||
|
|
|||
|
Name: collection
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: Identifies the associated resource as a collection. The
|
|||
|
resourcetype property of a collection resource MUST have this value.
|
|||
|
|
|||
|
<!ELEMENT collection EMPTY >
|
|||
|
|
|||
|
12.3 href XML Element
|
|||
|
|
|||
|
Name: href
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: Identifies the content of the element as a URI.
|
|||
|
Value: URI ; See section 3.2.1 of [RFC2068]
|
|||
|
|
|||
|
<!ELEMENT href (#PCDATA)>
|
|||
|
|
|||
|
12.4 link XML Element
|
|||
|
|
|||
|
Name: link
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: Identifies the property as a link and contains the source
|
|||
|
and destination of that link.
|
|||
|
Description: The link XML element is used to provide the sources and
|
|||
|
destinations of a link. The name of the property containing the link
|
|||
|
XML element provides the type of the link. Link is a multi-valued
|
|||
|
element, so multiple links may be used together to indicate multiple
|
|||
|
links with the same type. The values in the href XML elements inside
|
|||
|
the src and dst XML elements of the link XML element MUST NOT be
|
|||
|
rejected if they point to resources which do not exist.
|
|||
|
|
|||
|
<!ELEMENT link (src+, dst+) >
|
|||
|
|
|||
|
12.4.1 dst XML Element
|
|||
|
|
|||
|
Name: dst
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: Indicates the destination of a link
|
|||
|
Value: URI
|
|||
|
|
|||
|
<!ELEMENT dst (#PCDATA) >
|
|||
|
|
|||
|
12.4.2 src XML Element
|
|||
|
|
|||
|
Name: src
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: Indicates the source of a link.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 62]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
Value: URI
|
|||
|
|
|||
|
<!ELEMENT src (#PCDATA) >
|
|||
|
|
|||
|
12.5 lockentry XML Element
|
|||
|
|
|||
|
Name: lockentry
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: Defines the types of locks that can be used with the
|
|||
|
resource.
|
|||
|
|
|||
|
<!ELEMENT lockentry (lockscope, locktype) >
|
|||
|
|
|||
|
12.6 lockinfo XML Element
|
|||
|
|
|||
|
Name: lockinfo
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: The lockinfo XML element is used with a LOCK method to
|
|||
|
specify the type of lock the client wishes to have created.
|
|||
|
|
|||
|
<!ELEMENT lockinfo (lockscope, locktype, owner?) >
|
|||
|
|
|||
|
12.7 lockscope XML Element
|
|||
|
|
|||
|
Name: lockscope
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: Specifies whether a lock is an exclusive lock, or a
|
|||
|
shared lock.
|
|||
|
|
|||
|
<!ELEMENT lockscope (exclusive | shared) >
|
|||
|
|
|||
|
12.7.1 exclusive XML Element
|
|||
|
|
|||
|
Name: exclusive
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: Specifies an exclusive lock
|
|||
|
|
|||
|
<!ELEMENT exclusive EMPTY >
|
|||
|
|
|||
|
12.7.2 shared XML Element
|
|||
|
|
|||
|
Name: shared
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: Specifies a shared lock
|
|||
|
|
|||
|
<!ELEMENT shared EMPTY >
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 63]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
12.8 locktype XML Element
|
|||
|
|
|||
|
Name: locktype
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: Specifies the access type of a lock. At present, this
|
|||
|
specification only defines one lock type, the write lock.
|
|||
|
|
|||
|
<!ELEMENT locktype (write) >
|
|||
|
|
|||
|
12.8.1 write XML Element
|
|||
|
|
|||
|
Name: write
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: Specifies a write lock.
|
|||
|
|
|||
|
<!ELEMENT write EMPTY >
|
|||
|
|
|||
|
12.9 multistatus XML Element
|
|||
|
|
|||
|
Name: multistatus
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: Contains multiple response messages.
|
|||
|
Description: The responsedescription at the top level is used to
|
|||
|
provide a general message describing the overarching nature of the
|
|||
|
response. If this value is available an application may use it
|
|||
|
instead of presenting the individual response descriptions contained
|
|||
|
within the responses.
|
|||
|
|
|||
|
<!ELEMENT multistatus (response+, responsedescription?) >
|
|||
|
|
|||
|
12.9.1 response XML Element
|
|||
|
|
|||
|
Name: response
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: Holds a single response describing the effect of a
|
|||
|
method on resource and/or its properties.
|
|||
|
Description: A particular href MUST NOT appear more than once as the
|
|||
|
child of a response XML element under a multistatus XML element.
|
|||
|
This requirement is necessary in order to keep processing costs for a
|
|||
|
response to linear time. Essentially, this prevents having to search
|
|||
|
in order to group together all the responses by href. There are,
|
|||
|
however, no requirements regarding ordering based on href values.
|
|||
|
|
|||
|
<!ELEMENT response (href, ((href*, status)|(propstat+)),
|
|||
|
responsedescription?) >
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 64]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
12.9.1.1 propstat XML Element
|
|||
|
|
|||
|
Name: propstat
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: Groups together a prop and status element that is
|
|||
|
associated with a particular href element.
|
|||
|
Description: The propstat XML element MUST contain one prop XML
|
|||
|
element and one status XML element. The contents of the prop XML
|
|||
|
element MUST only list the names of properties to which the result in
|
|||
|
the status element applies.
|
|||
|
|
|||
|
<!ELEMENT propstat (prop, status, responsedescription?) >
|
|||
|
|
|||
|
12.9.1.2 status XML Element
|
|||
|
|
|||
|
Name: status
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: Holds a single HTTP status-line
|
|||
|
Value: status-line ;status-line defined in [RFC2068]
|
|||
|
|
|||
|
<!ELEMENT status (#PCDATA) >
|
|||
|
|
|||
|
12.9.2 responsedescription XML Element
|
|||
|
|
|||
|
Name: responsedescription
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: Contains a message that can be displayed to the user
|
|||
|
explaining the nature of the response.
|
|||
|
Description: This XML element provides information suitable to be
|
|||
|
presented to a user.
|
|||
|
|
|||
|
<!ELEMENT responsedescription (#PCDATA) >
|
|||
|
|
|||
|
12.10 owner XML Element
|
|||
|
|
|||
|
Name: owner
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: Provides information about the principal taking out a
|
|||
|
lock.
|
|||
|
Description: The owner XML element provides information sufficient
|
|||
|
for either directly contacting a principal (such as a telephone
|
|||
|
number or Email URI), or for discovering the principal (such as the
|
|||
|
URL of a homepage) who owns a lock.
|
|||
|
|
|||
|
<!ELEMENT owner ANY>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 65]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
12.11 prop XML element
|
|||
|
|
|||
|
Name: prop
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: Contains properties related to a resource.
|
|||
|
Description: The prop XML element is a generic container for
|
|||
|
properties defined on resources. All elements inside a prop XML
|
|||
|
element MUST define properties related to the resource. No other
|
|||
|
elements may be used inside of a prop element.
|
|||
|
|
|||
|
<!ELEMENT prop ANY>
|
|||
|
|
|||
|
12.12 propertybehavior XML element
|
|||
|
|
|||
|
Name: propertybehavior Namespace: DAV: Purpose: Specifies
|
|||
|
how properties are handled during a COPY or MOVE.
|
|||
|
Description: The propertybehavior XML element specifies how
|
|||
|
properties are handled during a COPY or MOVE. If this XML element is
|
|||
|
not included in the request body then the server is expected to act
|
|||
|
as defined by the default property handling behavior of the
|
|||
|
associated method. All WebDAV compliant resources MUST support the
|
|||
|
propertybehavior XML element.
|
|||
|
|
|||
|
<!ELEMENT propertybehavior (omit | keepalive) >
|
|||
|
|
|||
|
12.12.1 keepalive XML element
|
|||
|
|
|||
|
Name: keepalive
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: Specifies requirements for the copying/moving of live
|
|||
|
properties.
|
|||
|
Description: If a list of URIs is included as the value of keepalive
|
|||
|
then the named properties MUST be "live" after they are copied
|
|||
|
(moved) to the destination resource of a COPY (or MOVE). If the
|
|||
|
value "*" is given for the keepalive XML element, this designates
|
|||
|
that all live properties on the source resource MUST be live on the
|
|||
|
destination. If the requirements specified by the keepalive element
|
|||
|
can not be honored then the method MUST fail with a 412 (Precondition
|
|||
|
Failed). All DAV compliant resources MUST support the keepalive XML
|
|||
|
element for use with the COPY and MOVE methods.
|
|||
|
Value: "*" ; #PCDATA value can only be "*"
|
|||
|
|
|||
|
<!ELEMENT keepalive (#PCDATA | href+) >
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 66]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
12.12.2 omit XML element
|
|||
|
|
|||
|
Name: omit
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: The omit XML element instructs the server that it should
|
|||
|
use best effort to copy properties but a failure to copy a property
|
|||
|
MUST NOT cause the method to fail. Description: The default behavior
|
|||
|
for a COPY or MOVE is to copy/move all properties or fail the method.
|
|||
|
In certain circumstances, such as when a server copies a resource
|
|||
|
over another protocol such as FTP, it may not be possible to
|
|||
|
copy/move the properties associated with the resource. Thus any
|
|||
|
attempt to copy/move over FTP would always have to fail because
|
|||
|
properties could not be moved over, even as dead properties. All DAV
|
|||
|
compliant resources MUST support the omit XML element on COPY/MOVE
|
|||
|
methods.
|
|||
|
|
|||
|
<!ELEMENT omit EMPTY >
|
|||
|
|
|||
|
12.13 propertyupdate XML element
|
|||
|
|
|||
|
Name: propertyupdate
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: Contains a request to alter the properties on a
|
|||
|
resource.
|
|||
|
Description: This XML element is a container for the information
|
|||
|
required to modify the properties on the resource. This XML element
|
|||
|
is multi-valued.
|
|||
|
|
|||
|
<!ELEMENT propertyupdate (remove | set)+ >
|
|||
|
|
|||
|
12.13.1 remove XML element
|
|||
|
|
|||
|
Name: remove
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: Lists the DAV properties to be removed from a resource.
|
|||
|
Description: Remove instructs that the properties specified in prop
|
|||
|
should be removed. Specifying the removal of a property that does
|
|||
|
not exist is not an error. All the XML elements in a prop XML
|
|||
|
element inside of a remove XML element MUST be empty, as only the
|
|||
|
names of properties to be removed are required.
|
|||
|
|
|||
|
<!ELEMENT remove (prop) >
|
|||
|
|
|||
|
12.13.2 set XML element
|
|||
|
|
|||
|
Name: set
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: Lists the DAV property values to be set for a resource.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 67]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
Description: The set XML element MUST contain only a prop XML
|
|||
|
element. The elements contained by the prop XML element inside the
|
|||
|
set XML element MUST specify the name and value of properties that
|
|||
|
are set on the resource identified by Request-URI. If a property
|
|||
|
already exists then its value is replaced. Language tagging
|
|||
|
information in the property's value (in the "xml:lang" attribute, if
|
|||
|
present) MUST be persistently stored along with the property, and
|
|||
|
MUST be subsequently retrievable using PROPFIND.
|
|||
|
|
|||
|
<!ELEMENT set (prop) >
|
|||
|
|
|||
|
12.14 propfind XML Element
|
|||
|
|
|||
|
Name: propfind
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: Specifies the properties to be returned from a PROPFIND
|
|||
|
method. Two special elements are specified for use with propfind,
|
|||
|
allprop and propname. If prop is used inside propfind it MUST only
|
|||
|
contain property names, not values.
|
|||
|
|
|||
|
<!ELEMENT propfind (allprop | propname | prop) >
|
|||
|
|
|||
|
12.14.1 allprop XML Element
|
|||
|
|
|||
|
Name: allprop Namespace: DAV: Purpose: The allprop XML
|
|||
|
element specifies that all property names and values on the resource
|
|||
|
are to be returned.
|
|||
|
|
|||
|
<!ELEMENT allprop EMPTY >
|
|||
|
|
|||
|
12.14.2 propname XML Element
|
|||
|
|
|||
|
Name: propname Namespace: DAV: Purpose: The propname XML
|
|||
|
element specifies that only a list of property names on the resource
|
|||
|
is to be returned.
|
|||
|
|
|||
|
<!ELEMENT propname EMPTY >
|
|||
|
|
|||
|
13 DAV Properties
|
|||
|
|
|||
|
For DAV properties, the name of the property is also the same as the
|
|||
|
name of the XML element that contains its value. In the section
|
|||
|
below, the final line of each section gives the element type
|
|||
|
declaration using the format defined in [REC-XML]. The "Value" field,
|
|||
|
where present, specifies further restrictions on the allowable
|
|||
|
contents of the XML element using BNF (i.e., to further restrict the
|
|||
|
values of a PCDATA element).
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 68]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
13.1 creationdate Property
|
|||
|
|
|||
|
Name: creationdate
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: Records the time and date the resource was created.
|
|||
|
Value: date-time ; See Appendix 2
|
|||
|
Description: The creationdate property should be defined on all DAV
|
|||
|
compliant resources. If present, it contains a timestamp of the
|
|||
|
moment when the resource was created (i.e., the moment it had non-
|
|||
|
null state).
|
|||
|
|
|||
|
<!ELEMENT creationdate (#PCDATA) >
|
|||
|
|
|||
|
13.2 displayname Property
|
|||
|
|
|||
|
Name: displayname
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: Provides a name for the resource that is suitable for
|
|||
|
presentation to a user.
|
|||
|
Description: The displayname property should be defined on all DAV
|
|||
|
compliant resources. If present, the property contains a description
|
|||
|
of the resource that is suitable for presentation to a user.
|
|||
|
|
|||
|
<!ELEMENT displayname (#PCDATA) >
|
|||
|
|
|||
|
13.3 getcontentlanguage Property
|
|||
|
|
|||
|
Name: getcontentlanguage
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: Contains the Content-Language header returned by a GET
|
|||
|
without accept headers
|
|||
|
Description: The getcontentlanguage property MUST be defined on any
|
|||
|
DAV compliant resource that returns the Content-Language header on a
|
|||
|
GET.
|
|||
|
Value: language-tag ;language-tag is defined in section 14.13
|
|||
|
of [RFC2068]
|
|||
|
|
|||
|
<!ELEMENT getcontentlanguage (#PCDATA) >
|
|||
|
|
|||
|
13.4 getcontentlength Property
|
|||
|
|
|||
|
Name: getcontentlength
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: Contains the Content-Length header returned by a GET
|
|||
|
without accept headers.
|
|||
|
Description: The getcontentlength property MUST be defined on any
|
|||
|
DAV compliant resource that returns the Content-Length header in
|
|||
|
response to a GET.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 69]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
Value: content-length ; see section 14.14 of [RFC2068]
|
|||
|
|
|||
|
<!ELEMENT getcontentlength (#PCDATA) >
|
|||
|
|
|||
|
13.5 getcontenttype Property
|
|||
|
|
|||
|
Name: getcontenttype
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: Contains the Content-Type header returned by a GET
|
|||
|
without accept headers.
|
|||
|
Description: This getcontenttype property MUST be defined on any DAV
|
|||
|
compliant resource that returns the Content-Type header in response
|
|||
|
to a GET.
|
|||
|
Value: media-type ; defined in section 3.7 of [RFC2068]
|
|||
|
|
|||
|
<!ELEMENT getcontenttype (#PCDATA) >
|
|||
|
|
|||
|
13.6 getetag Property
|
|||
|
|
|||
|
Name: getetag
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: Contains the ETag header returned by a GET without
|
|||
|
accept headers.
|
|||
|
Description: The getetag property MUST be defined on any DAV
|
|||
|
compliant resource that returns the Etag header.
|
|||
|
Value: entity-tag ; defined in section 3.11 of [RFC2068]
|
|||
|
|
|||
|
<!ELEMENT getetag (#PCDATA) >
|
|||
|
|
|||
|
13.7 getlastmodified Property
|
|||
|
|
|||
|
Name: getlastmodified
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: Contains the Last-Modified header returned by a GET
|
|||
|
method without accept headers.
|
|||
|
Description: Note that the last-modified date on a resource may
|
|||
|
reflect changes in any part of the state of the resource, not
|
|||
|
necessarily just a change to the response to the GET method. For
|
|||
|
example, a change in a property may cause the last-modified date to
|
|||
|
change. The getlastmodified property MUST be defined on any DAV
|
|||
|
compliant resource that returns the Last-Modified header in response
|
|||
|
to a GET.
|
|||
|
Value: HTTP-date ; defined in section 3.3.1 of [RFC2068]
|
|||
|
|
|||
|
<!ELEMENT getlastmodified (#PCDATA) >
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 70]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
13.8 lockdiscovery Property
|
|||
|
|
|||
|
Name: lockdiscovery
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: Describes the active locks on a resource
|
|||
|
Description: The lockdiscovery property returns a listing of who has
|
|||
|
a lock, what type of lock he has, the timeout type and the time
|
|||
|
remaining on the timeout, and the associated lock token. The server
|
|||
|
is free to withhold any or all of this information if the requesting
|
|||
|
principal does not have sufficient access rights to see the requested
|
|||
|
data.
|
|||
|
|
|||
|
<!ELEMENT lockdiscovery (activelock)* >
|
|||
|
|
|||
|
13.8.1 Example - Retrieving the lockdiscovery Property
|
|||
|
|
|||
|
>>Request
|
|||
|
|
|||
|
PROPFIND /container/ HTTP/1.1
|
|||
|
Host: www.foo.bar
|
|||
|
Content-Length: xxxx
|
|||
|
Content-Type: text/xml; charset="utf-8"
|
|||
|
|
|||
|
<?xml version="1.0" encoding="utf-8" ?>
|
|||
|
<D:propfind xmlns:D='DAV:'>
|
|||
|
<D:prop><D:lockdiscovery/></D:prop>
|
|||
|
</D:propfind>
|
|||
|
|
|||
|
>>Response
|
|||
|
|
|||
|
HTTP/1.1 207 Multi-Status
|
|||
|
Content-Type: text/xml; charset="utf-8"
|
|||
|
Content-Length: xxxx
|
|||
|
|
|||
|
<?xml version="1.0" encoding="utf-8" ?>
|
|||
|
<D:multistatus xmlns:D='DAV:'>
|
|||
|
<D:response>
|
|||
|
<D:href>http://www.foo.bar/container/</D:href>
|
|||
|
<D:propstat>
|
|||
|
<D:prop>
|
|||
|
<D:lockdiscovery>
|
|||
|
<D:activelock>
|
|||
|
<D:locktype><D:write/></D:locktype>
|
|||
|
<D:lockscope><D:exclusive/></D:lockscope>
|
|||
|
<D:depth>0</D:depth>
|
|||
|
<D:owner>Jane Smith</D:owner>
|
|||
|
<D:timeout>Infinite</D:timeout>
|
|||
|
<D:locktoken>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 71]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
<D:href>
|
|||
|
opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76
|
|||
|
</D:href>
|
|||
|
</D:locktoken>
|
|||
|
</D:activelock>
|
|||
|
</D:lockdiscovery>
|
|||
|
</D:prop>
|
|||
|
<D:status>HTTP/1.1 200 OK</D:status>
|
|||
|
</D:propstat>
|
|||
|
</D:response>
|
|||
|
</D:multistatus>
|
|||
|
|
|||
|
This resource has a single exclusive write lock on it, with an
|
|||
|
infinite timeout.
|
|||
|
|
|||
|
13.9 resourcetype Property
|
|||
|
|
|||
|
Name: resourcetype
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: Specifies the nature of the resource.
|
|||
|
Description: The resourcetype property MUST be defined on all DAV
|
|||
|
compliant resources. The default value is empty.
|
|||
|
|
|||
|
<!ELEMENT resourcetype ANY >
|
|||
|
|
|||
|
13.10 source Property
|
|||
|
|
|||
|
Name: source
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: The destination of the source link identifies the
|
|||
|
resource that contains the unprocessed source of the link's source.
|
|||
|
Description: The source of the link (src) is typically the URI of the
|
|||
|
output resource on which the link is defined, and there is typically
|
|||
|
only one destination (dst) of the link, which is the URI where the
|
|||
|
unprocessed source of the resource may be accessed. When more than
|
|||
|
one link destination exists, this specification asserts no policy on
|
|||
|
ordering.
|
|||
|
|
|||
|
<!ELEMENT source (link)* >
|
|||
|
|
|||
|
13.10.1 Example - A source Property
|
|||
|
|
|||
|
<?xml version="1.0" encoding="utf-8" ?>
|
|||
|
<D:prop xmlns:D="DAV:" xmlns:F="http://www.foocorp.com/Project/">
|
|||
|
<D:source>
|
|||
|
<D:link>
|
|||
|
<F:projfiles>Source</F:projfiles>
|
|||
|
<D:src>http://foo.bar/program</D:src>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 72]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
<D:dst>http://foo.bar/src/main.c</D:dst>
|
|||
|
</D:link>
|
|||
|
<D:link>
|
|||
|
<F:projfiles>Library</F:projfiles>
|
|||
|
<D:src>http://foo.bar/program</D:src>
|
|||
|
<D:dst>http://foo.bar/src/main.lib</D:dst>
|
|||
|
</D:link>
|
|||
|
<D:link>
|
|||
|
<F:projfiles>Makefile</F:projfiles>
|
|||
|
<D:src>http://foo.bar/program</D:src>
|
|||
|
<D:dst>http://foo.bar/src/makefile</D:dst>
|
|||
|
</D:link>
|
|||
|
</D:source>
|
|||
|
</D:prop>
|
|||
|
|
|||
|
In this example the resource http://foo.bar/program has a source
|
|||
|
property that contains three links. Each link contains three
|
|||
|
elements, two of which, src and dst, are part of the DAV schema
|
|||
|
defined in this document, and one which is defined by the schema
|
|||
|
http://www.foocorp.com/project/ (Source, Library, and Makefile). A
|
|||
|
client which only implements the elements in the DAV spec will not
|
|||
|
understand the foocorp elements and will ignore them, thus seeing the
|
|||
|
expected source and destination links. An enhanced client may know
|
|||
|
about the foocorp elements and be able to present the user with
|
|||
|
additional information about the links. This example demonstrates
|
|||
|
the power of XML markup, allowing element values to be enhanced
|
|||
|
without breaking older clients.
|
|||
|
|
|||
|
13.11 supportedlock Property
|
|||
|
|
|||
|
Name: supportedlock
|
|||
|
Namespace: DAV:
|
|||
|
Purpose: To provide a listing of the lock capabilities supported
|
|||
|
by the resource.
|
|||
|
Description: The supportedlock property of a resource returns a
|
|||
|
listing of the combinations of scope and access types which may be
|
|||
|
specified in a lock request on the resource. Note that the actual
|
|||
|
contents are themselves controlled by access controls so a server is
|
|||
|
not required to provide information the client is not authorized to
|
|||
|
see.
|
|||
|
|
|||
|
<!ELEMENT supportedlock (lockentry)* >
|
|||
|
|
|||
|
13.11.1 Example - Retrieving the supportedlock Property
|
|||
|
|
|||
|
>>Request
|
|||
|
|
|||
|
PROPFIND /container/ HTTP/1.1
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 73]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
Host: www.foo.bar
|
|||
|
Content-Length: xxxx
|
|||
|
Content-Type: text/xml; charset="utf-8"
|
|||
|
|
|||
|
<?xml version="1.0" encoding="utf-8" ?>
|
|||
|
<D:propfind xmlns:D="DAV:">
|
|||
|
<D:prop><D:supportedlock/></D:prop>
|
|||
|
</D:propfind>
|
|||
|
|
|||
|
>>Response
|
|||
|
|
|||
|
HTTP/1.1 207 Multi-Status
|
|||
|
Content-Type: text/xml; charset="utf-8"
|
|||
|
Content-Length: xxxx
|
|||
|
|
|||
|
<?xml version="1.0" encoding="utf-8" ?>
|
|||
|
<D:multistatus xmlns:D="DAV:">
|
|||
|
<D:response>
|
|||
|
<D:href>http://www.foo.bar/container/</D:href>
|
|||
|
<D:propstat>
|
|||
|
<D:prop>
|
|||
|
<D:supportedlock>
|
|||
|
<D:lockentry>
|
|||
|
<D:lockscope><D:exclusive/></D:lockscope>
|
|||
|
<D:locktype><D:write/></D:locktype>
|
|||
|
</D:lockentry>
|
|||
|
<D:lockentry>
|
|||
|
<D:lockscope><D:shared/></D:lockscope>
|
|||
|
<D:locktype><D:write/></D:locktype>
|
|||
|
</D:lockentry>
|
|||
|
</D:supportedlock>
|
|||
|
</D:prop>
|
|||
|
<D:status>HTTP/1.1 200 OK</D:status>
|
|||
|
</D:propstat>
|
|||
|
</D:response>
|
|||
|
</D:multistatus>
|
|||
|
|
|||
|
14 Instructions for Processing XML in DAV
|
|||
|
|
|||
|
All DAV compliant resources MUST ignore any unknown XML element and
|
|||
|
all its children encountered while processing a DAV method that uses
|
|||
|
XML as its command language.
|
|||
|
|
|||
|
This restriction also applies to the processing, by clients, of DAV
|
|||
|
property values where unknown XML elements SHOULD be ignored unless
|
|||
|
the property's schema declares otherwise.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 74]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
This restriction does not apply to setting dead DAV properties on the
|
|||
|
server where the server MUST record unknown XML elements.
|
|||
|
|
|||
|
Additionally, this restriction does not apply to the use of XML where
|
|||
|
XML happens to be the content type of the entity body, for 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
|
|||
|
|
|||
|
A DAV compliant resource can choose from two classes of compliance.
|
|||
|
A client can discover the compliance classes of a resource by
|
|||
|
executing OPTIONS on the resource, and examining the "DAV" header
|
|||
|
which is returned.
|
|||
|
|
|||
|
Since this document describes extensions to the HTTP/1.1 protocol,
|
|||
|
minimally all DAV compliant resources, clients, and proxies MUST be
|
|||
|
compliant with [RFC2068].
|
|||
|
|
|||
|
Compliance classes are not necessarily sequential. A resource that is
|
|||
|
class 2 compliant must also be class 1 compliant; but if additional
|
|||
|
compliance classes are defined later, a resource that is class 1, 2,
|
|||
|
and 4 compliant might not be class 3 compliant. Also note that
|
|||
|
identifiers other than numbers may be used as compliance class
|
|||
|
identifiers.
|
|||
|
|
|||
|
15.1 Class 1
|
|||
|
|
|||
|
A class 1 compliant resource MUST meet all "MUST" requirements in all
|
|||
|
sections of this document.
|
|||
|
|
|||
|
Class 1 compliant resources MUST return, at minimum, the value "1" in
|
|||
|
the DAV header on all responses to the OPTIONS method.
|
|||
|
|
|||
|
15.2 Class 2
|
|||
|
|
|||
|
A class 2 compliant resource MUST meet all class 1 requirements and
|
|||
|
support the LOCK method, the supportedlock property, the
|
|||
|
lockdiscovery property, the Time-Out response header and the Lock-
|
|||
|
Token request header. A class "2" compliant resource SHOULD also
|
|||
|
support the Time-Out request header and the owner XML element.
|
|||
|
|
|||
|
Class 2 compliant resources MUST return, at minimum, the values "1"
|
|||
|
and "2" in the DAV header on all responses to the OPTIONS method.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 75]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
16 Internationalization Considerations
|
|||
|
|
|||
|
In the realm of internationalization, this specification complies
|
|||
|
with the IETF Character Set Policy [RFC2277]. In this specification,
|
|||
|
human-readable fields can be found either in the value of a property,
|
|||
|
or in an error message returned in a response entity body. In both
|
|||
|
cases, the human-readable content is encoded using XML, which has
|
|||
|
explicit provisions for character set tagging and encoding, and
|
|||
|
requires that XML processors read XML elements encoded, at minimum,
|
|||
|
using the UTF-8 [UTF-8] encoding of the ISO 10646 multilingual plane.
|
|||
|
XML examples in this specification demonstrate use of the charset
|
|||
|
parameter of the Content-Type header, as defined in [RFC2376], as
|
|||
|
well as the XML "encoding" attribute, which together provide charset
|
|||
|
identification information for MIME and XML processors.
|
|||
|
|
|||
|
XML also provides a language tagging capability for specifying the
|
|||
|
language of the contents of a particular XML element. XML uses
|
|||
|
either IANA registered language tags (see [RFC1766]) or ISO 639
|
|||
|
language tags [ISO-639] in the "xml:lang" attribute of an XML element
|
|||
|
to identify the language of its content and attributes.
|
|||
|
|
|||
|
WebDAV applications MUST support the character set tagging, character
|
|||
|
set encoding, and the language tagging functionality of the XML
|
|||
|
specification. Implementors of WebDAV applications are strongly
|
|||
|
encouraged to read "XML Media Types" [RFC2376] for instruction on
|
|||
|
which MIME media type to use for XML transport, and on use of the
|
|||
|
charset parameter of the Content-Type header.
|
|||
|
|
|||
|
Names used within this specification fall into three categories:
|
|||
|
names of protocol elements such as methods and headers, names of XML
|
|||
|
elements, and names of properties. Naming of protocol elements
|
|||
|
follows the precedent of HTTP, using English names encoded in USASCII
|
|||
|
for methods and headers. Since these protocol elements are not
|
|||
|
visible to users, and are in fact simply long token identifiers, they
|
|||
|
do not need to support encoding in multiple character sets.
|
|||
|
Similarly, though the names of XML elements used in this
|
|||
|
specification are English names encoded in UTF-8, these names are not
|
|||
|
visible to the user, and hence do not need to support multiple
|
|||
|
character set encodings.
|
|||
|
|
|||
|
The name of a property defined on a resource is a URI. Although some
|
|||
|
applications (e.g., a generic property viewer) will display property
|
|||
|
URIs directly to their users, it is expected that the typical
|
|||
|
application will use a fixed set of properties, and will provide a
|
|||
|
mapping from the property name URI to a human-readable field when
|
|||
|
displaying the property name to a user. It is only in the case where
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 76]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
the set of properties is not known ahead of time that an application
|
|||
|
need display a property name URI to a user. We recommend that
|
|||
|
applications provide human-readable property names wherever feasible.
|
|||
|
|
|||
|
For error reporting, we follow the convention of HTTP/1.1 status
|
|||
|
codes, including with each status code a short, English description
|
|||
|
of the code (e.g., 423 (Locked)). While the possibility exists that
|
|||
|
a poorly crafted user agent would display this message to a user,
|
|||
|
internationalized applications will ignore this message, and display
|
|||
|
an appropriate message in the user's language and character set.
|
|||
|
|
|||
|
Since interoperation of clients and servers does not require locale
|
|||
|
information, this specification does not specify any mechanism for
|
|||
|
transmission of this information.
|
|||
|
|
|||
|
17 Security Considerations
|
|||
|
|
|||
|
This section is provided to detail issues concerning security
|
|||
|
implications of which WebDAV applications need to be aware.
|
|||
|
|
|||
|
All of the security considerations of HTTP/1.1 (discussed in
|
|||
|
[RFC2068]) and XML (discussed in [RFC2376]) also apply to WebDAV. In
|
|||
|
addition, the security risks inherent in remote authoring require
|
|||
|
stronger authentication technology, introduce several new privacy
|
|||
|
concerns, and may increase the hazards from poor server design.
|
|||
|
These issues are detailed below.
|
|||
|
|
|||
|
17.1 Authentication of Clients
|
|||
|
|
|||
|
Due to their emphasis on authoring, WebDAV servers need to use
|
|||
|
authentication technology to protect not just access to a network
|
|||
|
resource, but the integrity of the resource as well. Furthermore,
|
|||
|
the introduction of locking functionality requires support for
|
|||
|
authentication.
|
|||
|
|
|||
|
A password sent in the clear over an insecure channel is an
|
|||
|
inadequate means for protecting the accessibility and integrity of a
|
|||
|
resource as the password may be intercepted. Since Basic
|
|||
|
authentication for HTTP/1.1 performs essentially clear text
|
|||
|
transmission of a password, Basic authentication MUST NOT be used to
|
|||
|
authenticate a WebDAV client to a server unless the connection is
|
|||
|
secure. Furthermore, a WebDAV server MUST NOT send Basic
|
|||
|
authentication credentials in a WWW-Authenticate header unless the
|
|||
|
connection is secure. Examples of secure connections include a
|
|||
|
Transport Layer Security (TLS) connection employing a strong cipher
|
|||
|
suite with mutual authentication of client and server, or a
|
|||
|
connection over a network which is physically secure, for example, an
|
|||
|
isolated network in a building with restricted access.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 77]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
WebDAV applications MUST support the Digest authentication scheme
|
|||
|
[RFC2069]. Since Digest authentication verifies that both parties to
|
|||
|
a communication know a shared secret, a password, without having to
|
|||
|
send that secret in the clear, Digest authentication avoids the
|
|||
|
security problems inherent in Basic authentication while providing a
|
|||
|
level of authentication which is useful in a wide range of scenarios.
|
|||
|
|
|||
|
17.2 Denial of Service
|
|||
|
|
|||
|
Denial of service attacks are of special concern to WebDAV servers.
|
|||
|
WebDAV plus HTTP enables denial of service attacks on every part of a
|
|||
|
system's resources.
|
|||
|
|
|||
|
The underlying storage can be attacked by PUTting extremely large
|
|||
|
files.
|
|||
|
|
|||
|
Asking for recursive operations on large collections can attack
|
|||
|
processing time.
|
|||
|
|
|||
|
Making multiple pipelined requests on multiple connections can attack
|
|||
|
network connections.
|
|||
|
|
|||
|
WebDAV servers need to be aware of the possibility of a denial of
|
|||
|
service attack at all levels.
|
|||
|
|
|||
|
17.3 Security through Obscurity
|
|||
|
|
|||
|
WebDAV provides, through the PROPFIND method, a mechanism for listing
|
|||
|
the member resources of a collection. This greatly diminishes the
|
|||
|
effectiveness of security or privacy techniques that rely only on the
|
|||
|
difficulty of discovering the names of network resources. Users of
|
|||
|
WebDAV servers are encouraged to use access control techniques to
|
|||
|
prevent unwanted access to resources, rather than depending on the
|
|||
|
relative obscurity of their resource names.
|
|||
|
|
|||
|
17.4 Privacy Issues Connected to Locks
|
|||
|
|
|||
|
When submitting a lock request a user agent may also submit an owner
|
|||
|
XML field giving contact information for the person taking out the
|
|||
|
lock (for those cases where a person, rather than a robot, is taking
|
|||
|
out the lock). This contact information is stored in a lockdiscovery
|
|||
|
property on the resource, and can be used by other collaborators to
|
|||
|
begin negotiation over access to the resource. However, in many
|
|||
|
cases this contact information can be very private, and should not be
|
|||
|
widely disseminated. Servers SHOULD limit read access to the
|
|||
|
lockdiscovery property as appropriate. Furthermore, user agents
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 78]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
SHOULD provide control over whether contact information is sent at
|
|||
|
all, and if contact information is sent, control over exactly what
|
|||
|
information is sent.
|
|||
|
|
|||
|
17.5 Privacy Issues Connected to Properties
|
|||
|
|
|||
|
Since property values are typically used to hold information such as
|
|||
|
the author of a document, there is the possibility that privacy
|
|||
|
concerns could arise stemming from widespread access to a resource's
|
|||
|
property data. To reduce the risk of inadvertent release of private
|
|||
|
information via properties, servers are encouraged to develop access
|
|||
|
control mechanisms that separate read access to the resource body and
|
|||
|
read access to the resource's properties. This allows a user to
|
|||
|
control the dissemination of their property data without overly
|
|||
|
restricting access to the resource's contents.
|
|||
|
|
|||
|
17.6 Reduction of Security due to Source Link
|
|||
|
|
|||
|
HTTP/1.1 warns against providing read access to script code because
|
|||
|
it may contain sensitive information. Yet WebDAV, via its source
|
|||
|
link facility, can potentially provide a URI for script resources so
|
|||
|
they may be authored. For HTTP/1.1, a server could reasonably
|
|||
|
prevent access to source resources due to the predominance of read-
|
|||
|
only access. WebDAV, with its emphasis on authoring, encourages read
|
|||
|
and write access to source resources, and provides the source link
|
|||
|
facility to identify the source. This reduces the security benefits
|
|||
|
of eliminating access to source resources. Users and administrators
|
|||
|
of WebDAV servers should be very cautious when allowing remote
|
|||
|
authoring of scripts, limiting read and write access to the source
|
|||
|
resources to authorized principals.
|
|||
|
|
|||
|
17.7 Implications of XML External Entities
|
|||
|
|
|||
|
XML supports a facility known as "external entities", defined in
|
|||
|
section 4.2.2 of [REC-XML], which instruct an XML processor to
|
|||
|
retrieve and perform an inline include of XML located at a particular
|
|||
|
URI. An external XML entity can be used to append or modify the
|
|||
|
document type declaration (DTD) associated with an XML document. An
|
|||
|
external XML entity can also be used to include XML within the
|
|||
|
content of an XML document. For non-validating XML, such as the XML
|
|||
|
used in this specification, including an external XML entity is not
|
|||
|
required by [REC-XML]. However, [REC-XML] does state that an XML
|
|||
|
processor may, at its discretion, include the external XML entity.
|
|||
|
|
|||
|
External XML entities have no inherent trustworthiness and are
|
|||
|
subject to all the attacks that are endemic to any HTTP GET request.
|
|||
|
Furthermore, it is possible for an external XML entity to modify the
|
|||
|
DTD, and hence affect the final form of an XML document, in the worst
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 79]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
case significantly modifying its semantics, or exposing the XML
|
|||
|
processor to the security risks discussed in [RFC2376]. Therefore,
|
|||
|
implementers must be aware that external XML entities should be
|
|||
|
treated as untrustworthy.
|
|||
|
|
|||
|
There is also the scalability risk that would accompany a widely
|
|||
|
deployed application which made use of external XML entities. In
|
|||
|
this situation, it is possible that there would be significant
|
|||
|
numbers of requests for one external XML entity, potentially
|
|||
|
overloading any server which fields requests for the resource
|
|||
|
containing the external XML entity.
|
|||
|
|
|||
|
17.8 Risks Connected with Lock Tokens
|
|||
|
|
|||
|
This specification, in section 6.4, requires the use of Universal
|
|||
|
Unique Identifiers (UUIDs) for lock tokens, in order to guarantee
|
|||
|
their uniqueness across space and time. UUIDs, as defined in [ISO-
|
|||
|
11578], contain a "node" field which "consists of the IEEE address,
|
|||
|
usually the host address. For systems with multiple IEEE 802 nodes,
|
|||
|
any available node address can be used." Since a WebDAV server will
|
|||
|
issue many locks over its lifetime, the implication is that it will
|
|||
|
also be publicly exposing its IEEE 802 address.
|
|||
|
|
|||
|
There are several risks associated with exposure of IEEE 802
|
|||
|
addresses. Using the IEEE 802 address:
|
|||
|
|
|||
|
* It is possible to track the movement of hardware from subnet to
|
|||
|
subnet.
|
|||
|
|
|||
|
* It may be possible to identify the manufacturer of the hardware
|
|||
|
running a WebDAV server.
|
|||
|
|
|||
|
* It may be possible to determine the number of each type of computer
|
|||
|
running WebDAV.
|
|||
|
|
|||
|
Section 6.4.1 of this specification details an alternate mechanism
|
|||
|
for generating the "node" field of a UUID without using an IEEE 802
|
|||
|
address, which alleviates the risks associated with exposure of IEEE
|
|||
|
802 addresses by using an alternate source of uniqueness.
|
|||
|
|
|||
|
18 IANA Considerations
|
|||
|
|
|||
|
This document defines two namespaces, the namespace of property
|
|||
|
names, and the namespace of WebDAV-specific XML elements used within
|
|||
|
property values.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 80]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
URIs are used for both names, for several reasons. Assignment of a
|
|||
|
URI does not require a request to a central naming authority, and
|
|||
|
hence allow WebDAV property names and XML elements to be quickly
|
|||
|
defined by any WebDAV user or application. URIs also provide a
|
|||
|
unique address space, ensuring that the distributed users of WebDAV
|
|||
|
will not have collisions among the property names and XML elements
|
|||
|
they create.
|
|||
|
|
|||
|
This specification defines a distinguished set of property names and
|
|||
|
XML elements that are understood by all WebDAV applications. The
|
|||
|
property names and XML elements in this specification are all derived
|
|||
|
from the base URI DAV: by adding a suffix to this URI, for example,
|
|||
|
DAV:creationdate for the "creationdate" property.
|
|||
|
|
|||
|
This specification also defines a URI scheme for the encoding of lock
|
|||
|
tokens, the opaquelocktoken URI scheme described in section 6.4.
|
|||
|
|
|||
|
To ensure correct interoperation based on this specification, IANA
|
|||
|
must reserve the URI namespaces starting with "DAV:" and with
|
|||
|
"opaquelocktoken:" for use by this specification, its revisions, and
|
|||
|
related WebDAV specifications.
|
|||
|
|
|||
|
19 Intellectual Property
|
|||
|
|
|||
|
The following notice is copied from RFC 2026 [RFC2026], section 10.4,
|
|||
|
and describes the position of the IETF concerning intellectual
|
|||
|
property claims made against this document.
|
|||
|
|
|||
|
The IETF takes no position regarding the validity or scope of any
|
|||
|
intellectual property or other rights that might be claimed to
|
|||
|
pertain to the implementation or use other technology described in
|
|||
|
this document or the extent to which any license under such rights
|
|||
|
might or might not be available; neither does it represent that it
|
|||
|
has made any effort to identify any such rights. Information on the
|
|||
|
IETF's procedures with respect to rights in standards-track and
|
|||
|
standards-related documentation can be found in BCP-11. Copies of
|
|||
|
claims of rights made available for publication and any assurances of
|
|||
|
licenses to be made available, or the result of an attempt made to
|
|||
|
obtain a general license or permission for the use of such
|
|||
|
proprietary rights by implementors or users of this specification can
|
|||
|
be obtained from the IETF Secretariat.
|
|||
|
|
|||
|
The IETF invites any interested party to bring to its attention any
|
|||
|
copyrights, patents or patent applications, or other proprietary
|
|||
|
rights which may cover technology that may be required to practice
|
|||
|
this standard. Please address the information to the IETF Executive
|
|||
|
Director.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 81]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
20 Acknowledgements
|
|||
|
|
|||
|
A specification such as this thrives on piercing critical review and
|
|||
|
withers from apathetic neglect. The authors gratefully acknowledge
|
|||
|
the contributions of the following people, whose insights were so
|
|||
|
valuable at every stage of our work.
|
|||
|
|
|||
|
Terry Allen, Harald Alvestrand, Jim Amsden, Becky Anderson, Alan
|
|||
|
Babich, Sanford Barr, Dylan Barrell, Bernard Chester, Tim Berners-
|
|||
|
Lee, Dan Connolly, Jim Cunningham, Ron Daniel, Jr., Jim Davis, Keith
|
|||
|
Dawson, Mark Day, Brian Deen, Martin Duerst, David Durand, Lee
|
|||
|
Farrell, Chuck Fay, Wesley Felter, Roy Fielding, Mark Fisher, Alan
|
|||
|
Freier, George Florentine, Jim Gettys, Phill Hallam-Baker, Dennis
|
|||
|
Hamilton, Steve Henning, Mead Himelstein, Alex Hopmann, Andre van der
|
|||
|
Hoek, Ben Laurie, Paul Leach, Ora Lassila, Karen MacArthur, Steven
|
|||
|
Martin, Larry Masinter, Michael Mealling, Keith Moore, Thomas Narten,
|
|||
|
Henrik Nielsen, Kenji Ota, Bob Parker, Glenn Peterson, Jon Radoff,
|
|||
|
Saveen Reddy, Henry Sanders, Christopher Seiwald, Judith Slein, Mike
|
|||
|
Spreitzer, Einar Stefferud, Greg Stein, Ralph Swick, Kenji Takahashi,
|
|||
|
Richard N. Taylor, Robert Thau, John Turner, Sankar Virdhagriswaran,
|
|||
|
Fabio Vitali, Gregory Woodhouse, and Lauren Wood.
|
|||
|
|
|||
|
Two from this list deserve special mention. The contributions by
|
|||
|
Larry Masinter have been invaluable, both in helping the formation 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
|
|||
|
meet. The contributions of Judith Slein in clarifying the
|
|||
|
requirements, and in patiently reviewing draft after draft, both
|
|||
|
improved this specification and expanded our minds on document
|
|||
|
management.
|
|||
|
|
|||
|
We would also like to thank John Turner for developing the XML DTD.
|
|||
|
|
|||
|
21 References
|
|||
|
|
|||
|
21.1 Normative References
|
|||
|
|
|||
|
[RFC1766] Alvestrand, H., "Tags for the Identification of
|
|||
|
Languages", RFC 1766, March 1995.
|
|||
|
|
|||
|
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
|
|||
|
Languages", BCP 18, RFC 2277, January 1998.
|
|||
|
|
|||
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|||
|
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 82]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter,
|
|||
|
"Uniform Resource Identifiers (URI): Generic Syntax",
|
|||
|
RFC 2396, August 1998.
|
|||
|
|
|||
|
[REC-XML] T. Bray, J. Paoli, C. M. Sperberg-McQueen,
|
|||
|
"Extensible Markup Language (XML)." World Wide Web
|
|||
|
Consortium Recommendation REC-xml-19980210.
|
|||
|
http://www.w3.org/TR/1998/REC-xml-19980210.
|
|||
|
|
|||
|
[REC-XML-NAMES] T. Bray, D. Hollander, A. Layman, "Namespaces in
|
|||
|
XML". World Wide Web Consortium Recommendation REC-
|
|||
|
xml-names-19990114. http://www.w3.org/TR/1999/REC-
|
|||
|
xml-names-19990114/
|
|||
|
|
|||
|
[RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach,
|
|||
|
P, Luotonen, A., Sink, E. and L. Stewart, "An
|
|||
|
Extension to HTTP : Digest Access Authentication",
|
|||
|
RFC 2069, January 1997.
|
|||
|
|
|||
|
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and
|
|||
|
T. Berners-Lee, "Hypertext Transfer Protocol --
|
|||
|
HTTP/1.1", RFC 2068, January 1997.
|
|||
|
|
|||
|
[ISO-639] ISO (International Organization for Standardization).
|
|||
|
ISO 639:1988. "Code for the representation of names
|
|||
|
of languages."
|
|||
|
|
|||
|
[ISO-8601] ISO (International Organization for Standardization).
|
|||
|
ISO 8601:1988. "Data elements and interchange formats
|
|||
|
- Information interchange - Representation of dates
|
|||
|
and times."
|
|||
|
|
|||
|
[ISO-11578] ISO (International Organization for Standardization).
|
|||
|
ISO/IEC 11578:1996. "Information technology - Open
|
|||
|
Systems Interconnection - Remote Procedure Call
|
|||
|
(RPC)"
|
|||
|
|
|||
|
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
|
|||
|
|
|||
|
[UTF-8] Yergeau, F., "UTF-8, a transformation format of
|
|||
|
Unicode and ISO 10646", RFC 2279, January 1998.
|
|||
|
|
|||
|
21.2 Informational References
|
|||
|
|
|||
|
[RFC2026] Bradner, S., "The Internet Standards Process - Revision
|
|||
|
3", BCP 9, RFC 2026, October 1996.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 83]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
[RFC1807] Lasher, R. and D. Cohen, "A Format for Bibliographic
|
|||
|
Records", RFC 1807, 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 Format for Bibliographic Data", 1994. Washington,
|
|||
|
DC: Cataloging Distribution Service, Library of Congress.
|
|||
|
|
|||
|
[REC-PICS] J. Miller, T. Krauskopf, P. Resnick, W. Treese, "PICS
|
|||
|
Label Distribution Label Syntax and Communication
|
|||
|
Protocols" Version 1.1, World Wide Web Consortium
|
|||
|
Recommendation REC-PICS-labels-961031.
|
|||
|
http://www.w3.org/pub/WWW/TR/REC-PICS-labels-961031.html.
|
|||
|
|
|||
|
[RFC2291] Slein, J., Vitali, F., Whitehead, E. and D. Durand,
|
|||
|
"Requirements for Distributed Authoring and Versioning
|
|||
|
Protocol for the World Wide Web", RFC 2291, February 1998.
|
|||
|
|
|||
|
[RFC2413] Weibel, S., Kunze, J., Lagoze, C. and M. Wolf, "Dublin
|
|||
|
Core Metadata for Resource Discovery", RFC 2413, September
|
|||
|
1998.
|
|||
|
|
|||
|
[RFC2376] Whitehead, E. and M. Murata, "XML Media Types", RFC 2376,
|
|||
|
July 1998.
|
|||
|
|
|||
|
22 Authors' Addresses
|
|||
|
|
|||
|
Y. Y. Goland
|
|||
|
Microsoft Corporation
|
|||
|
One Microsoft Way
|
|||
|
Redmond, WA 98052-6399
|
|||
|
|
|||
|
EMail: yarong@microsoft.com
|
|||
|
|
|||
|
|
|||
|
E. J. Whitehead, Jr.
|
|||
|
Dept. Of Information and Computer Science
|
|||
|
University of California, Irvine
|
|||
|
Irvine, CA 92697-3425
|
|||
|
|
|||
|
EMail: ejw@ics.uci.edu
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 84]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
A. Faizi
|
|||
|
Netscape
|
|||
|
685 East Middlefield Road
|
|||
|
Mountain View, CA 94043
|
|||
|
|
|||
|
EMail: asad@netscape.com
|
|||
|
|
|||
|
|
|||
|
S. R. Carter
|
|||
|
Novell
|
|||
|
1555 N. Technology Way
|
|||
|
M/S ORM F111
|
|||
|
Orem, UT 84097-2399
|
|||
|
|
|||
|
EMail: srcarter@novell.com
|
|||
|
|
|||
|
|
|||
|
D. Jensen
|
|||
|
Novell
|
|||
|
1555 N. Technology Way
|
|||
|
M/S ORM F111
|
|||
|
Orem, UT 84097-2399
|
|||
|
|
|||
|
EMail: dcjensen@novell.com
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 85]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
23 Appendices
|
|||
|
|
|||
|
23.1 Appendix 1 - WebDAV Document Type Definition
|
|||
|
|
|||
|
This section provides a document type definition, following the rules
|
|||
|
in [REC-XML], for the XML elements used in the protocol stream and in
|
|||
|
the values of properties. It collects the element definitions given
|
|||
|
in sections 12 and 13.
|
|||
|
|
|||
|
<!DOCTYPE webdav-1.0 [
|
|||
|
|
|||
|
<!--============ XML Elements from Section 12 ==================-->
|
|||
|
|
|||
|
<!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?,
|
|||
|
locktoken?) >
|
|||
|
|
|||
|
<!ELEMENT lockentry (lockscope, locktype) >
|
|||
|
<!ELEMENT lockinfo (lockscope, locktype, owner?) >
|
|||
|
|
|||
|
<!ELEMENT locktype (write) >
|
|||
|
<!ELEMENT write EMPTY >
|
|||
|
|
|||
|
<!ELEMENT lockscope (exclusive | shared) >
|
|||
|
<!ELEMENT exclusive EMPTY >
|
|||
|
<!ELEMENT shared EMPTY >
|
|||
|
|
|||
|
<!ELEMENT depth (#PCDATA) >
|
|||
|
|
|||
|
<!ELEMENT owner ANY >
|
|||
|
|
|||
|
<!ELEMENT timeout (#PCDATA) >
|
|||
|
|
|||
|
<!ELEMENT locktoken (href+) >
|
|||
|
|
|||
|
<!ELEMENT href (#PCDATA) >
|
|||
|
|
|||
|
<!ELEMENT link (src+, dst+) >
|
|||
|
<!ELEMENT dst (#PCDATA) >
|
|||
|
<!ELEMENT src (#PCDATA) >
|
|||
|
|
|||
|
<!ELEMENT multistatus (response+, responsedescription?) >
|
|||
|
|
|||
|
<!ELEMENT response (href, ((href*, status)|(propstat+)),
|
|||
|
responsedescription?) >
|
|||
|
<!ELEMENT status (#PCDATA) >
|
|||
|
<!ELEMENT propstat (prop, status, responsedescription?) >
|
|||
|
<!ELEMENT responsedescription (#PCDATA) >
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 86]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
<!ELEMENT prop ANY >
|
|||
|
|
|||
|
<!ELEMENT propertybehavior (omit | keepalive) >
|
|||
|
<!ELEMENT omit EMPTY >
|
|||
|
|
|||
|
<!ELEMENT keepalive (#PCDATA | href+) >
|
|||
|
|
|||
|
<!ELEMENT propertyupdate (remove | set)+ >
|
|||
|
<!ELEMENT remove (prop) >
|
|||
|
<!ELEMENT set (prop) >
|
|||
|
|
|||
|
<!ELEMENT propfind (allprop | propname | prop) >
|
|||
|
<!ELEMENT allprop EMPTY >
|
|||
|
<!ELEMENT propname EMPTY >
|
|||
|
|
|||
|
<!ELEMENT collection EMPTY >
|
|||
|
|
|||
|
<!--=========== Property Elements from Section 13 ===============-->
|
|||
|
<!ELEMENT creationdate (#PCDATA) >
|
|||
|
<!ELEMENT displayname (#PCDATA) >
|
|||
|
<!ELEMENT getcontentlanguage (#PCDATA) >
|
|||
|
<!ELEMENT getcontentlength (#PCDATA) >
|
|||
|
<!ELEMENT getcontenttype (#PCDATA) >
|
|||
|
<!ELEMENT getetag (#PCDATA) >
|
|||
|
<!ELEMENT getlastmodified (#PCDATA) >
|
|||
|
<!ELEMENT lockdiscovery (activelock)* >
|
|||
|
<!ELEMENT resourcetype ANY >
|
|||
|
<!ELEMENT source (link)* >
|
|||
|
<!ELEMENT supportedlock (lockentry)* >
|
|||
|
]>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 87]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
23.2 Appendix 2 - ISO 8601 Date and Time Profile
|
|||
|
|
|||
|
The creationdate property specifies the use of the ISO 8601 date
|
|||
|
format [ISO-8601]. This section defines a profile of the ISO 8601
|
|||
|
date format for use with this specification. This profile is quoted
|
|||
|
from an Internet-Draft by Chris Newman, and is mentioned here to
|
|||
|
properly attribute his work.
|
|||
|
|
|||
|
date-time = full-date "T" full-time
|
|||
|
|
|||
|
full-date = date-fullyear "-" date-month "-" date-mday
|
|||
|
full-time = partial-time time-offset
|
|||
|
|
|||
|
date-fullyear = 4DIGIT
|
|||
|
date-month = 2DIGIT ; 01-12
|
|||
|
date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on
|
|||
|
month/year
|
|||
|
time-hour = 2DIGIT ; 00-23
|
|||
|
time-minute = 2DIGIT ; 00-59
|
|||
|
time-second = 2DIGIT ; 00-59, 00-60 based on leap second rules
|
|||
|
time-secfrac = "." 1*DIGIT
|
|||
|
time-numoffset = ("+" / "-") time-hour ":" time-minute
|
|||
|
time-offset = "Z" / time-numoffset
|
|||
|
|
|||
|
partial-time = time-hour ":" time-minute ":" time-second
|
|||
|
[time-secfrac]
|
|||
|
|
|||
|
Numeric offsets are calculated as local time minus UTC (Coordinated
|
|||
|
Universal Time). So the equivalent time in UTC can be determined by
|
|||
|
subtracting the offset from the local time. For example, 18:50:00-
|
|||
|
04:00 is the same time as 22:58:00Z.
|
|||
|
|
|||
|
If the time in UTC is known, but the offset to local time is unknown,
|
|||
|
this can be represented with an offset of "-00:00". This differs
|
|||
|
from an offset of "Z" which implies that UTC is the preferred
|
|||
|
reference point for the specified time.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 88]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
23.3 Appendix 3 - Notes on Processing XML Elements
|
|||
|
|
|||
|
23.3.1 Notes on Empty XML Elements
|
|||
|
|
|||
|
XML supports two mechanisms for indicating that an XML element does
|
|||
|
not have any content. The first is to declare an XML element of the
|
|||
|
form <A></A>. The second is to declare an XML element of the form
|
|||
|
<A/>. The two XML elements are semantically identical.
|
|||
|
|
|||
|
It is a violation of the XML specification to use the <A></A> form if
|
|||
|
the associated DTD declares the element to be EMPTY (e.g., <!ELEMENT
|
|||
|
A EMPTY>). If such a statement is included, then the empty element
|
|||
|
format, <A/> must be used. If the element is not declared to be
|
|||
|
EMPTY, then either form <A></A> or <A/> may be used for empty
|
|||
|
elements.
|
|||
|
|
|||
|
23.3.2 Notes on Illegal XML Processing
|
|||
|
|
|||
|
XML is a flexible data format that makes it easy to submit data that
|
|||
|
appears legal but in fact is not. The philosophy of "Be flexible in
|
|||
|
what you accept and strict in what you send" still applies, but it
|
|||
|
must not be applied inappropriately. XML is extremely flexible in
|
|||
|
dealing with issues of white space, element ordering, inserting new
|
|||
|
elements, etc. This flexibility does not require extension,
|
|||
|
especially not in the area of the meaning of elements.
|
|||
|
|
|||
|
There is no kindness in accepting illegal combinations of XML
|
|||
|
elements. At best it will cause an unwanted result and at worst it
|
|||
|
can cause real damage.
|
|||
|
|
|||
|
23.3.2.1 Example - XML Syntax Error
|
|||
|
|
|||
|
The following request body for a PROPFIND method is illegal.
|
|||
|
|
|||
|
<?xml version="1.0" encoding="utf-8" ?>
|
|||
|
<D:propfind xmlns:D="DAV:">
|
|||
|
<D:allprop/>
|
|||
|
<D:propname/>
|
|||
|
</D:propfind>
|
|||
|
|
|||
|
The definition of the propfind element only allows for the allprop or
|
|||
|
the propname element, not both. Thus the above is an error and must
|
|||
|
be responded to with a 400 (Bad Request).
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 89]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
Imagine, however, that a server wanted to be "kind" and decided to
|
|||
|
pick the allprop element as the true element and respond to it. A
|
|||
|
client running over a bandwidth limited line who intended to execute
|
|||
|
a propname would be in for a big surprise if the server treated the
|
|||
|
command as an allprop.
|
|||
|
|
|||
|
Additionally, if a server were lenient and decided to reply to this
|
|||
|
request, the results would vary randomly from server to server, with
|
|||
|
some servers executing the allprop directive, and others executing
|
|||
|
the propname directive. This reduces interoperability rather than
|
|||
|
increasing it.
|
|||
|
|
|||
|
23.3.2.2 Example - Unknown XML Element
|
|||
|
|
|||
|
The previous example was illegal because it contained two elements
|
|||
|
that were explicitly banned from appearing together in the propfind
|
|||
|
element. However, XML is an extensible language, so one can imagine
|
|||
|
new elements being defined for use with propfind. Below is the
|
|||
|
request body of a PROPFIND and, like the previous example, must be
|
|||
|
rejected with a 400 (Bad Request) by a server that does not
|
|||
|
understand the expired-props element.
|
|||
|
|
|||
|
<?xml version="1.0" encoding="utf-8" ?>
|
|||
|
<D:propfind xmlns:D="DAV:"
|
|||
|
xmlns:E="http://www.foo.bar/standards/props/">
|
|||
|
<E:expired-props/>
|
|||
|
</D:propfind>
|
|||
|
|
|||
|
To understand why a 400 (Bad Request) is returned let us look at the
|
|||
|
request body as the server unfamiliar with expired-props sees it.
|
|||
|
|
|||
|
<?xml version="1.0" encoding="utf-8" ?>
|
|||
|
<D:propfind xmlns:D="DAV:"
|
|||
|
xmlns:E="http://www.foo.bar/standards/props/">
|
|||
|
</D:propfind>
|
|||
|
|
|||
|
As the server does not understand the expired-props element,
|
|||
|
according to the WebDAV-specific XML processing rules specified in
|
|||
|
section 14, it must ignore it. Thus the server sees an empty
|
|||
|
propfind, which by the definition of the propfind element is illegal.
|
|||
|
|
|||
|
Please note that had the extension been additive it would not
|
|||
|
necessarily have resulted in a 400 (Bad Request). For example,
|
|||
|
imagine the following request body for a PROPFIND:
|
|||
|
|
|||
|
<?xml version="1.0" encoding="utf-8" ?>
|
|||
|
<D:propfind xmlns:D="DAV:"
|
|||
|
xmlns:E="http://www.foo.bar/standards/props/">
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 90]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
<D:propname/>
|
|||
|
<E:leave-out>*boss*</E:leave-out>
|
|||
|
</D:propfind>
|
|||
|
|
|||
|
The previous example contains the fictitious element leave-out. Its
|
|||
|
purpose is to prevent the return of any property whose name matches
|
|||
|
the submitted pattern. If the previous example were submitted to a
|
|||
|
server unfamiliar with leave-out, the only result would be that the
|
|||
|
leave-out element would be ignored and a propname would be executed.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 91]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
23.4 Appendix 4 -- XML Namespaces for WebDAV
|
|||
|
|
|||
|
23.4.1 Introduction
|
|||
|
|
|||
|
All DAV compliant systems MUST support the XML namespace extensions
|
|||
|
as specified in [REC-XML-NAMES].
|
|||
|
|
|||
|
23.4.2 Meaning of Qualified Names
|
|||
|
|
|||
|
[Note to the reader: This section does not appear in [REC-XML-NAMES],
|
|||
|
but is necessary to avoid ambiguity for WebDAV XML processors.]
|
|||
|
|
|||
|
WebDAV compliant XML processors MUST interpret a qualified name as a
|
|||
|
URI constructed by appending the LocalPart to the namespace name URI.
|
|||
|
|
|||
|
Example
|
|||
|
|
|||
|
<del:glider xmlns:del="http://www.del.jensen.org/">
|
|||
|
<del:glidername>
|
|||
|
Johnny Updraft
|
|||
|
</del:glidername>
|
|||
|
<del:glideraccidents/>
|
|||
|
</del:glider>
|
|||
|
|
|||
|
In this example, the qualified element name "del:glider" is
|
|||
|
interpreted as the URL "http://www.del.jensen.org/glider".
|
|||
|
|
|||
|
<bar:glider xmlns:del="http://www.del.jensen.org/">
|
|||
|
<bar:glidername>
|
|||
|
Johnny Updraft
|
|||
|
</bar:glidername>
|
|||
|
<bar:glideraccidents/>
|
|||
|
</bar:glider>
|
|||
|
|
|||
|
Even though this example is syntactically different from the previous
|
|||
|
example, it is semantically identical. Each instance of the
|
|||
|
namespace name "bar" is replaced with "http://www.del.jensen.org/"
|
|||
|
and then appended to the local name for each element tag. The
|
|||
|
resulting tag names in this example are exactly the same as for the
|
|||
|
previous example.
|
|||
|
|
|||
|
<foo:r xmlns:foo="http://www.del.jensen.org/glide">
|
|||
|
<foo:rname>
|
|||
|
Johnny Updraft
|
|||
|
</foo:rname>
|
|||
|
<foo:raccidents/>
|
|||
|
</foo:r>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 92]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
This example is semantically identical to the two previous ones.
|
|||
|
Each instance of the namespace name "foo" is replaced with
|
|||
|
"http://www.del.jensen.org/glide" which is then appended to the local
|
|||
|
name for each element tag, the resulting tag names are identical to
|
|||
|
those in the previous examples.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 93]
|
|||
|
|
|||
|
RFC 2518 WEBDAV February 1999
|
|||
|
|
|||
|
|
|||
|
24. Full Copyright Statement
|
|||
|
|
|||
|
Copyright (C) The Internet Society (1999). All Rights Reserved.
|
|||
|
|
|||
|
This document and translations of it may be copied and furnished to
|
|||
|
others, and derivative works that comment on or otherwise explain it
|
|||
|
or assist in its implementation may be prepared, copied, published
|
|||
|
and distributed, in whole or in part, without restriction of any
|
|||
|
kind, provided that the above copyright notice and this paragraph are
|
|||
|
included on all such copies and derivative works. However, this
|
|||
|
document itself may not be modified in any way, such as by removing
|
|||
|
the copyright notice or references to the Internet Society or other
|
|||
|
Internet organizations, except as needed for the purpose of
|
|||
|
developing Internet standards in which case the procedures for
|
|||
|
copyrights defined in the Internet Standards process must be
|
|||
|
followed, or as required to translate it into languages other than
|
|||
|
English.
|
|||
|
|
|||
|
The limited permissions granted above are perpetual and will not be
|
|||
|
revoked by the Internet Society or its successors or assigns.
|
|||
|
|
|||
|
This document and the information contained herein is provided on an
|
|||
|
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
|||
|
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
|||
|
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
|||
|
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
|||
|
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Goland, et al. Standards Track [Page 94]
|
|||
|
|