WEBDAV Working Group Y. Y. Y.Y. Goland, Microsoft
INTERNET-DRAFT E. J.
INTERNET DRAFT E.J. Whitehead, Jr., U.C. UC Irvine
<draft-ietf-webdav-protocol-04>
<draft-ietf-webdav-protocol-05> A. Faizi, Netscape
S. R
S.R. Carter, Novell
D. Jensen, Novell
Expires April 20, April, 1998 October 12, November 19, 1997
Extensions for Distributed Authoring and Versioning on the World Wide Web -- WEBDAV
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or made obsolete by other
documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress".
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Distribution of this document is unlimited. Please send comments to
the Distributed Authoring and Versioning (WEBDAV) working group at
<w3c-dist-auth@w3.org>, which may be joined by sending a message
with subject "subscribe" to <w3c-dist-auth-
request@w3.org>. <w3c-dist-auth-request@w3.org>.
Discussions of the WEBDAV working group are archived at
<URL:http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth>.
Abstract
This Document document specifies a set of methods methods, headers, and content-types
ancillary to HTTP/1.1 for the management of resource properties,
simple name space
creation and management of resource collections, namespace
manipulation, simple resource locking (collision avoidance) avoidance), and efficient
transmission of resource version control.
Table changes.
Changes
1.1. Changes since draft-ietf-webdav-protocol-04.txt
[Editor's note: This section will not appear in the final form of Contents
Abstract
1 Terminology
2 Data Model and Methods
this document. Its purpose is to provide a concise list of changes
from the previous revision of the draft for DAV Properties
2.1 Introduction
2.1.1 The DAV Property
2.1.2 Existing Metadata Proposals
2.1.3 Properties and HTTP Headers
2.2 A Property Model use by reviewers.]
Added this change section.
Removed scoping for HTTP Resources
2.2.1 Overview
2.2.2 Property Namespace
2.3 Schemas
2.3.1 PropSchema XML Element
2.3.2 DTD XML Element
2.3.3 DefinedProps XML Element
2.3.4 PropEntries XML Element
2.3.5 Live XML Element
2.4 DAV Schema
2.4.1 namespaces so the namespace for
every element is explicitly stated.
Changed the syntax from <?XML:Namespace.../> to <?namespace...?>.
Removed propfindresult, this was left over from the old search
format.
Changed all the DAV Property
2.4.2 Level XML Element
2.4.3 Prop XML element
2.4.4 PropLoc XML Attribute
2.4.5 Example
2.5 Property Identifiers
2.5.1 Problem Definition
2.6 Link XML Element
2.6.1 Problem Description
2.6.2 Solution Requirements
2.6.3 Link XML Element
2.6.4 Src XML Element
2.6.5 Dst XML Element
2.6.6 Example
2.7 Multi-Status Response
2.7.1 Problem Definition
2.7.2 Solution Requirements
2.7.3 Multi-Status Response
2.8 Properties names to lower case.
Changed the property format to use Name and Methods
2.8.1 DELETE
2.8.2 GET
2.8.3 PROPPATCH
2.8.4 PUT
2.8.5 PROPFIND
3 A Proposal for Collections of Web Resources Namespace rather than
name and Name Space
Operations
3.1 Observations schema.
Removed proploc attribute and removed section on GETting, DELETEing,
and PUTing properties since we do not provide a mechanism for
getting a URI for properties. Also removed the requirement that
properties be URI addressable.
Removed quoted string choice from owner header, it is just XML.
Made all the HTTP Object Model
3.1.1 Collection Resources
3.1.2 Creation and Retrieval error codes use the same format.
Changed the name of Collection
Resources
3.1.3 Source Resources and Output Resources
3.2 MKCOL Method
3.2.1 Problem Description
3.2.2 Solution Requirements
3.2.3 Request
3.2.4 Response
3.2.5 Example
3.3 Standard DAV Properties
3.3.1 IsCollection Property
3.3.2 DisplayName Property
3.3.3 CreationDate Property
3.3.4 GETentity Property
3.3.5 INDEXentity Property
3.3.6 Content-Type XML Element
3.3.7 Content-Length XML Element
3.3.8 Content-Language XML Element
3.3.9 Last-Modified XML Element
3.3.10 Etag XML Element
3.4 INDEX Method
3.4.1 Problem Description
3.4.2 Solution Requirements
3.4.3 The Request
3.4.4 The Response
3.4.5 ResInfo XML Element
3.4.6 Members XML Element
3.4.7 Href XML Element
3.4.8 Example
3.5 Behavior of RFC 2068 Methods on Collections
3.5.1 GET, HEAD for Collections
3.5.2 POST for Collections
3.5.3 PUT for Collections
3.5.4 DELETE for Collections
3.5.5 DELETE Method for Non-Collection
Resources
3.6 COPY Method
3.6.1 Problem Description
3.6.2 Solution Requirements
3.6.3 The Request
3.6.4 The Response
3.6.5 Examples
3.7 MOVE Method
3.7.1 Problem Description
3.7.2 Solution Requirements
3.7.3 The Request
3.7.4 The Response
3.7.5 Examples
3.8 ADDREF Method
3.8.1 Problem Definition
3.8.2 Solution Requirements
3.8.3 The Request
3.8.4 Example
3.9 DELREF Method
3.9.1 Problem Definition
3.9.2 Solution Requirements
3.9.3 The Request
3.9.4 Example
3.10 PATCH Method
3.10.1 Problem Definition
3.10.2 Solution Requirements
3.10.3 The Request
3.10.4 text/xml elements for PATCH
3.10.5 The Response
3.10.6 Examples
3.11 Headers
3.11.1 Destination Header
3.11.2 Enforce-Live-Properties Header
3.11.3 Overwrite Header
3.11.4 Destroy Header
3.11.5 Collection-Member Header
3.12 Links
3.12.1 Source Link Property Type
4 State Tokens
4.1 Overview
4.1.1 Problem Description
4.1.2 Solution Requirements
4.2 State Token Syntax
4.3 State Token Conditional Headers
4.3.1 If-State-Match
4.3.2 If-None-State-Match
4.4 State Token Header
4.5 E-Tag
5 Locking
5.1 Locking: Introduction
5.1.1 Exclusive Vs. Shared Locks
5.1.2 Required Support
5.2 LOCK Method
5.2.1 Operation
5.2.2 The Effect of Locks on Properties and
Containers
5.2.3 Locking Replicated Resources
5.2.4 Locking Multiple Resources
5.2.5 Interaction with other Methods
5.2.6 Lock Compatibility Table
5.2.7 Status Codes
5.2.8 Lock-Info Request Header
5.2.9 Owner Request Header
5.2.10 Time-Out Header
5.2.11 Lock Response
5.2.12 Example - Simple Lock Request
5.2.13 Example - Multi-Resource Lock Request
5.3 Write Lock
5.3.1 Methods Restricted by Write Locks
5.3.2 Write Locks and Properties
5.3.3 Write Locks and Null Resources
5.3.4 Write Locks and Collections
5.3.5 Write Locks and COPY/MOVE
5.3.6 Re-issuing Write Locks
5.3.7 Write Locks and The State-Token Header
5.4 Lock Tokens
5.4.1 Problem Description
5.4.2 Lock Token Introduction
5.4.3 Generic Lock Tokens
5.4.4 OpaqueLockToken Lock Token
5.5 UNLOCK Method
5.5.1 Problem Definition
5.5.2 Example
5.6 Discovery Mechanisms
5.6.1 Lock Capability Discovery
5.6.2 Active Lock Discovery
6 Version Control
7 Internationalization Support
8 Security Considerations
9 Copyright
10 Acknowledgements
11 References
12 Authors' Addresses
1 Terminology
Collection - A resource that contains member resources.
Member Resource - a resource referred to by a collection. There
are two types of member resources: external and internal.
Internal Member Resource - the name given to a member resource of
a collection whose URI is relative to the URI of the collection.
External Member Resource - a member resource with an absolute URI
that is not relative to its parent’s URI.
Properties - A set of name/value pairs that contain descriptive
information about a resource.
Live Properties - Properties whose semantics and syntax are
enforced by the server. For example, a live "read-only" property
that is enforced by the server would disallow PUTs to the
associated resource.
Dead properties - Properties whose semantics and syntax are not
enforced by the server. A dead "read-only" property would not be
enforced by the server and thus would not be used by the server
as a reason to disallow a PUT on the associated resource.
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 [Bradner, 1997].
2 Data Model and Methods for DAV Properties
2.1 Introduction
2.1.1 The DAV Property
Properties are pieces of data that describe the state of a
resource. Properties are data about data. The term property is
used within this specification to disambiguate the concept from
the overloaded terms "metadata" and "attribute".
Properties are used within 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.
2.1.2 Existing Metadata Proposals
Properties have a long played an essential role in the
maintenance of large document repositories, and many current
proposals contain some notion of a property. These include PICS
[Miller et al., 1996], PICS-NG, the Rel/Rev draft [Maloney,
1996], Web Collections, XML [Bray, Sperberg-McQueen, 1997],
several proposals on representing relationships within HTML,
digital signature manifests (DCMF), and a position paper on Web
metadata architecture [Berners-Lee, 1997].
Some proposals come from a digital library perspective. These
include the Dublin Core [Weibel et al., 1995] metadata set and
the Warwick Framework [Lagoze, 1996], a container architecture
for different metadata schemas. The literature includes many
examples of metadata, including MARC [MARC, 1994], a
bibliographic metadata format, RFC 1807 [Lasher, Cohen, 1995], a
technical report bibliographic format employed by the Dienst
system, and the proceedings from the first IEEE Metadata
conference describe many community-specific metadata sets.
Participants of the 1996 Metadata II Workshop in Warwick, UK
[Lagoze, 1996], 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.
2.1.3 Properties and HTTP Headers
Properties already exist, in a limited sense, within HTTP through
the use of 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 then set or retrieve
just those properties.
2.2 A Property Model for HTTP Resources
2.2.1 Overview
The DAV property model is based on name/value doubles. The name
of a property identifies the property's syntax and semantics, and
provides an address with which to refer to a property. The name
and value of a property is expressed as a well-formed XML
element, where the name of the property is the name of the XML
element, and the value of the property MUST be either blank, or a
well-formed XML element value.
2.2.2 Property Namespace
2.2.2.1 Problem Definition
The requirement is to be able to associate a value with a
property name on a resource. It must be possible to associate a
URL with the property name.
2.2.2.2 Solution Requirement
Ideally a property namespace should work well with extant
property implementations as well as database systems. The DAV
property namespace has been specified with the following two
facts in mind:
· Namespaces associated with flat file systems are ubiquitous.
· The majority of databases use a fixed schema mechanism.
The last point makes efficient implementation of hierarchical
properties difficult. Specifically, each property has a random
set of children; the best a relational database can do is provide
a table with name and value, where the value is a series of
indexes into other tables and each index represents a specific
value. However most RDBS do not provide for table pointers, only
index values. Such a system would have to be jury-rigged to
handle table pointers. In addition, indexing systems are
optimized for a small set of relatively large tables;
hierarchical property systems tend toward many properties, each
with different numbers and types of children, thus potentially
requiring a table for each child.
It would seem best to implement a flat property namespace,
inducing a natural isomorphism between DAV and most native file
systems. Adopting such a model will not restrict RDBS from taking
full advantage of their search facilities.
However, it seems that future trends might be toward hierarchical
properties. Therefore, DAV requirements [Slein et al.] stipulate
that the design of the flat property system MUST be such that it
will be possible to add true hierarchical properties later
without breaking downlevel clients. Specifically, a flat client
MUST be able to speak to a hierarchical server and a hierarchical
client MUST be able to speak to a flat server. Worst case either
way MUST be that the request fails.
2.2.2.3 Property Names
A property name identifies both the syntax and semantics of the
property's value. It is critical that property names do not
collide, e.g., two principals defining the same property name
with two different meanings.
The URI framework provides a mechanism to prevent namespace
collision and for varying degrees of administrative control.
Rather than reinvent these desirable features, DAV properties
make use of them by requiring that all DAV property names MUST be
URIs. Since a property is also an XML element, the name of the
XML element is a URI.
The property namespace is flat, that is, it is not possible to
string together a series of property names in order to refer to a
hierarchy of properties. Thus it is possible to refer to a
property B but not a property A/B, where A is also a property
defined on the resource.
Finally, it is not possible to define the same property twice as
this would cause a collision in the resource's property
namespace.
2.3 Schemas
A schema is a group of property names and XML elements.
Schema discovery is used to determine if a system supports a
group of properties or XML elements. A property does not
necessarily contain sufficient information to identify any
schema(s) to which it may belong.
As with property names, schemas MUST use URIs as their names.
A resource declares its support for a schema by defining a
property whose name is the same as the schema's. The property
SHOULD contain the PropSchema XML element.
2.3.1 PropSchema XML Element
Name: http://www.ietf.org/standards/dav/PropSchema
Purpose: To provide information about properties
Schema: http://www.ietf.org/standards/dav/
Parent: Any
Values= [DTD] [DefinedProps]
Description:This property contains the definition of the schema.
This definition consists of two parts. A DTD element that
contains a DTD that declares all XML elements and DefinedProps
that defines any properties associated with the schema. As with
all XML it is possible to add extra XML elements. Therefore
schemas may define extra XML elements which are to be included
with their values.
2.3.2 DTD XML Element
Name: http://www.ietf.org/standards/dav/DTD
Purpose: To contain the DTD for XML elements associated with the
schema.
Schema: http://www.ietf.org/standards/dav/
Parent: Any
Values: XML Declaration statements
2.3.3 DefinedProps XML Element
Name: http://www.ietf.org/standards/dav/DefinedProps
Purpose: To contain a list of properties defined by the schema.
Schema: http://www.ietf.org/standards/dav/
Parent: Any
Values= 1*PropEntries
2.3.4 PropEntries XML Element
Name: http://www.ietf.org/standards/dav/PropEntries
Purpose: To contain the name of a defined property, the DTD of
its value, and its live/dead status.
Schema: http://www.ietf.org/standards/dav/
Parent: DefinedProps
Values= Prop [DTD] [Live]
Description:Prop contains the name of the property. The DTD
contains the DTD of the property's value. Live, if defined,
indicates that the property has semantics and syntax that are
enforced by the server.
2.3.5 Live XML Element
Name: http://www.ietf.org/standards/dav/Live
Purpose: If present this indicates the server MUST enforce the
syntax and semantics of the property.
Schema: http://www.ietf.org/standards/dav/
Parent: PropEntries
2.4 DAV Schema
The DAV Schema is specified as
http://www.ietf.org/standards/dav/. This schema is used to
indicate support for
· properties that may be defined on a resource and
· XML elements that may be returned in responses.
2.4.1 DAV Property
Name: http://www.ietf.org/standards/dav
Purpose: Defines support for the DAV schema and protocol.
Schema: http://www.ietf.org/standards/dav/
Values= PropSchema Level
Description:This property indicates that the resource supports the DAV schema and protocol create element in PROPPATCH to set, the level indicated. THE VALUE IN
PROPSCHEMA IS TBD, WE NEED TO PROVIDE IT IN AN APPENDIX.
2.4.2 Level XML Element
Name: http://www.ietf.org/standards/dav/level
Purpose: To indicate new
name seems to cause less confusion.
Moved all headers in the level of DAV compliance draft to a single section.
Deleted the resource
meets.
Schema: http://www.ietf.org/standards/dav/
Parent: DAV
Values= "1" | "2" | "3"
Description:A value state token section of 1 for level indicates that the resource
supports the property draft and namespace sections of the DAV
specification. Level 2 indicates that moved the resource supports level
1 and state
token headers to the lock header section of the specification, with a minimum
locking capability of draft. Removed the write lock. Level 3 indicates support
for levels 1 and 2 as well as support for state
token header.
Changed the versioning write lock section
of the DAV specification.
2.4.3 Prop XML element
Name: http://www.ietf.org/standards/dav/prop
Purpose: Contains properties related to state that a resource.
Schema: http://www.ietf.org/standards/dav/
Parent: Any
Values: XML Elements
Description:The Prop XML element is Lock-Token request
header, not a generic container for
properties defined on resources. All elements inside Prop MUST
define properties related state-token request header, is to the resource. No other elements may be used inside of submitted on
request for write locked resources.
Created a Prop element.
2.4.4 PropLoc "generic" XML element section for XML Attribute
Name: http://www.ietf.org/standards/dav/PropLoc
Purpose: To specify the location of the associated property.
Schema: http://www.ietf.org/standards/dav/
Values= URL
Description:This attribute is used with elements inside of Props
contained in responses to specify the URL of the property on the
associated resource. The PropLoc attribute MUST NOT be used in
requests.
2.4.5 Example
<?XML:Namespace href="http://www.ietf.org/standards/dav/"
AS="D"/>
<?XML:Namespace href="AIIM:Dublin:" AS="A"/>
<D:Prop>
<A:Author
D:PropLoc="http://www.foo.com/resource/props/Author">
Larry Masinter
</A:Author>
</D:Prop>
The previous specifies that get
repeatedly re-used throughout the property author exists on some
unspecified resource spec. I moved LINK XML element to
this section.
Made multistatus and that the property can be directly
referenced at http://www.foo.com/resource/props/Author. The
resource upon which Schema discovery their own level one sections.
Collected all the property is defined must be determined
from context.
2.5 Property Identifiers
2.5.1 Problem Definition
DAV properties are resources and thus may have a URI where together.
Removed all references to the
value of an instance possibility of properties have their
own URIs. This includes removing the property may be retrieved. This URI
is identifier section.
Separated the section on web collections and namespaces into two
separate from sections.
Collected all the URI new response codes together into their own
section.
Changed the XML multiresponse element name to multistatus.
Added a stand alone section on levels of the DAV compliance. I also went
method by method, property by property, which identifies to specify compliance
requirements.
Added an introduction.
Changed all the syntax "True" and semantics of the property, but which does not give
information on how "False" to access "T" and "F".
Altered the value of an instance first two paragraphs of the
property.
A server is free to assign whatever URI it chooses to identify an
instance of a property defined on a resource. In fact, a server
is free not Property Names section to reveal
make the URI of an instance of relationship between a particular
resource property's name and instead require that the client access its schema a
little clearer. I also added some text in the same section defining
a property
through PROPFIND name as a namespace and PROPPATCH. However, many servers will want element.
Added a second paragraph to allow clients property model for http resources -
overview. This paragraph clarifies why XML was chosen.
Added a 409 Conflict error to directly manipulate properties. On these
servers, move to cover attempts to move a client can discover
collection with members.
Changed the URI of an instance of collection requirement to read the collections SHOULD
end with "/". Also added a SHOULD about returning a location header
if the client submits a URL for a collection without a trailing "/".
Moved the owner header into the body due to size concerns.
Replaced the iscollection xml element with resourcetype.
Moved the DAV property by performing a PROPFIND and examining to the PropLoc
attribute, if returned, of each property.
2.6 Link XML Element
2.6.1 Problem Description
A mechanism DAV header that is needed to associate resources returned with other
resources. These associations, known
OPTIONS.
Folded the tree draft into this draft. Changed the DELETE, COPY,
and MOVE sections to include their effect on collections as links, consist of three
values, taken
from the tree draft. Created a type describing Depth header section and put in the nature of
general rules that were in the association, introduction to the
source of tree draft. I
also added the link, 102 response and response-status header.
Removed the destination of the link. In the case
of annotation, neither versioning section.
Put all the source nor methods into a single section.
Replaced the destination of PROPFIND request body with a link
need be propfind header. Now the resource upon
response can be cached just using vary.
Nuked resinfo for INDEX and combined it with multistatus which the link is recorded.
2.6.2 Solution Requirements
The association mechanism MUST make use of the DAV property
mechanism in order to make
now used for both INDEX and PROPFIND. Stripped down INDEX as
agreed.
Removed the existence of problem definition and proposed solution sections. We
can always cut and paste them together from the associations
searchable.
2.6.3 Link XML Element
Name: http://www.ietf.org/standards/dav/link
Purpose: To identify a property as older version if we
feel we need them but this draft is supposed to be a link dry run for
last call and to contain last call documents do not have problem
definition/proposed solution sections.
Killed the
source and destination of that link.
Schema: http://www.ietf.org/standards/dav/
Values= 1*Src 1*Dst
Description:Link section on schema discovery, it is controversial and we
aren't going to be able to require it. We should specify it in a
different spec.
Added a section on notational conventions used within the document.
Moved the terminology section to provide the sources and destinations
of a link. The type end of the property containing document to provide
better flow from the Link XML
element provides high-level introduction to the specific
introduction sections.
Increased the type numeric value of the link. Link is a multi-valued
element, so multiple Links may be used together 4xx status codes introduced in
this specification to indicate
multiple links avoid conflicts with the same type.
2.6.4 Src XML Element
Name: http://www.ietf.org/standards/dav/src
Purpose: To indicate the source of a link.
Schema: http://www.ietf.org/standards/dav/
Parent: http://www.ietf.org/standards/dav/link
Values= URI
2.6.5 Dst XML Element
Name: http://www.ietf.org/standards/dav/Dst
Purpose: To indicate the destination new revision of a link
Schema: http://www.ietf.org/standards/dav/
Parent: http://www.ietf.org/standards/dav/link
Values= URI
2.6.6 Example
<?XML:Namespace
href = "http://www.ietf.org/standards/dav/" AS = "D"/>
<?XML:Namespace
href = "http://www.foocorp.com/Project/" AS = "F"/>
<D:Prop>
<Source>
<Link>
<F:ProjFiles>Source</F:ProjFiles>
<src>http://foo.bar/program</src>
<dst>http://foo.bar/src/main.c</dst>
</Link>
<Link>
<F:ProjFiles>Library</F:ProjFiles>
<src>http://foo.bar/program</src>
<dst>http://foo.bar/src/main.lib</dst>
</Link>
<Link>
<F:ProjFiles>Makefile</F:ProjFiles>
<src>http://foo.bar/program</src>
<dst>http://foo.bar/src/makefile</dst>
<Link>
</Source>
</D:Prop>
In this example the resource http://foo.bar/program has a source
property defined
HTTP/1.1 specification, which contains three links. Each link contains
three elements, introduces two of which, src new 4xx status codes.
Wrote internationalization concerns section.
Added XML version number to all examples.
Contents
STATUS OF THIS MEMO...................................................1
ABSTRACT..............................................................1
CHANGES...............................................................1
1.1. Changes since draft-ietf-webdav-protocol-04.txt..................1
CONTENTS..............................................................5
2. INTRODUCTION.......................................................8
3. DATA MODEL FOR RESOURCE PROPERTIES.................................9
3.1. The Resource Property Model......................................9
3.2. Existing Metadata Proposals.....................................10
3.3. Properties and dst, are part HTTP Headers.....................................10
3.4. Property Values.................................................10
3.5. Property Names..................................................11
4. COLLECTIONS OF WEB RESOURCES......................................11
4.1. Collection Resources............................................11
4.2. Creation and Retrieval of the DAV
schema defined in this document, Collection Resources..................12
4.3. HTTP URL Namespace Model........................................13
4.4. Source Resources and one which is defined Output Resources...........................13
5. LOCKING...........................................................14
5.1. Exclusive Vs. Shared Locks......................................14
5.2. Required Support................................................15
5.3. Lock Tokens.....................................................16
5.4. opaquelocktoken Lock Token URI Scheme...........................16
5.5. Lock Capability Discovery.......................................16
5.6. Active Lock Discovery...........................................17
6. WRITE LOCK........................................................17
6.1. Methods Restricted by the
schema http://www.foocorp.com/project/ (Source, Library, Write Locks...............................17
6.2. Write Locks and
Makefile). A client which only implements the elements in the Properties......................................17
6.3. Write Locks and Null Resources..................................17
6.4. Write Locks and Collections.....................................18
6.5. Write Locks and COPY/MOVE.......................................18
6.6. Re-issuing Write Locks..........................................18
6.7. Write Locks and The Lock-Token Request Header...................18
7. NOTATIONAL CONVENTIONS............................................19
8. HTTP METHODS FOR DISTRIBUTED AUTHORING............................19
8.1. PROPFIND........................................................19
8.2. PROPPATCH.......................................................23
8.3. MKCOL Method....................................................25
8.4. INDEX Method....................................................26
8.5. DELREF Method...................................................28
8.6. ADDREF Method...................................................28
8.7. GET, HEAD for Collections.......................................29
8.8. POST for Collections............................................29
8.9. DELETE..........................................................29
8.10. PUT............................................................31
8.11. COPY Method....................................................31
8.12. MOVE Method....................................................35
8.13. LOCK Method....................................................38
8.14. UNLOCK Method..................................................42
8.15. PATCH Method...................................................43
9. DAV
spec will not understand HEADERS.......................................................47
9.1. Collection-Member Header........................................47
9.2. DAV Header......................................................47
9.3. Depth Header....................................................47
9.4. Destination Header..............................................48
9.5. Destroy Header..................................................48
9.6. Enforce-Live-Properties Header..................................49
9.7. If-None-State-Match.............................................49
9.8. If-State-Match..................................................50
9.9. Lock-Info Request Header........................................50
9.10. Lock-Token Request Header......................................51
9.11. Lock-Token Response Header.....................................51
9.12. Overwrite Header...............................................52
9.13. Propfind Request Header........................................52
9.14. Status-URI Response Header.....................................52
9.15. Timeout Header.................................................52
10. RESPONSE CODE EXTENSIONS TO RFC 2068.............................54
10.1. 102 Processing.................................................54
10.2. 207 Multi-Status...............................................54
10.3. 418 Unprocessable Entity.......................................54
10.4. 419 Insufficient Space on Resource.............................54
10.5. 420 Method Failure.............................................54
11. MULTI-STATUS RESPONSE............................................54
11.1. multistatus XML Element........................................55
11.2. response XML Element...........................................55
11.3. status XML Element.............................................55
11.4. responsedescription XML Element................................55
12. GENERIC DAV XML ELEMENTS.........................................55
12.1. href XML Element...............................................56
12.2. link XML Element...............................................56
12.3. prop XML element...............................................57
13. DAV PROPERTIES...................................................57
13.1. creationdate Property..........................................57
13.2. displayname Property...........................................57
13.3. get-content-language Property..................................58
13.4. get-content-length Property....................................58
13.5. get-content-type Property......................................58
13.6. get-etag Property..............................................58
13.7. get-last-modified Property.....................................59
13.8. index-content-language Property................................59
13.9. index-content-length Property..................................59
13.10. index-content-type Property...................................59
13.11. index-etag Property...........................................59
13.12. index-last-modified Property..................................60
13.13. lockdiscovery Property........................................60
13.14. resourcetype Property.........................................62
13.15. Source Link Property Type.....................................62
13.16. supportedlock Property........................................63
14. DAV COMPLIANCE LEVELS............................................64
14.1. Level 1........................................................64
14.2. Level 2........................................................64
15. INTERNATIONALIZATION SUPPORT.....................................65
16. SECURITY CONSIDERATIONS..........................................66
17. TERMINOLOGY......................................................66
18. COPYRIGHT........................................................66
19. ACKNOWLEDGEMENTS.................................................67
20. REFERENCES.......................................................69
21. AUTHORS' ADDRESSES...............................................71
2. Introduction
This document describes an extension to the foocorp elements 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 will ignore
them, thus seeing the expected source response entity body formats that provide
operations for:
Properties: The ability to create, remove, and destination links. An
enhanced client may know query information
about Web pages, such as its author, creation date, etc. Also, the foocorp elements
ability to link pages of any media type to related pages.
Collections: The ability to create sets of related documents, and be able to present the user with additional information about the links.
2.7 Multi-Status Response
2.7.1 Problem Definition
Some methods effect
receive a listing of pages at a particular hierarchy level (like a
directory listing in a file system).
Locking: The ability to keep more than one resource. The effect of the
method person from working on each of a
document at the scoped resources may be different, same time. This prevents the "lost update problem"
in which modifications are lost as such
a return format that can specify first one author, then another
writes their changes without merging the effect other author's changes
Namespace Operations: The ability to copy and move Web resources
Efficient Update: The ability to send changes which are proportional
to the size of the method on each
resource is needed.
2.7.2 Solution Requirements
The solution must:
- communicate change rather than retransmitting the status code entire
resource.
Requirements and reason
- give rationale for these operations are described in a
companion document, "Requirements for a Distributed Authoring and
Versioning Protocol for the URI World Wide Web" [Slein et al., 1997].
The sections below provide a detailed introduction to resource
properties (Section 3), collections of resources (Section 4), and
locking operations (Section 5). These sections introduce the resource on which
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 invoked
- be consistent with other return body formats
2.7.3 Multi-Status Response
The default multi-status response body is an text/xml exclusively encoded in
HTTP headers. Unlike HTTP/1.1, WebDAV, encodes method parameter
information either in an Extensible Markup Language (XML) [Bray,
Sperberg-McQueen, 1997] request entity
that contains a single XML element called multiresponse, which
contains a set body, or in an HTTP header.
The use of XML to encode method parameters was motivated by the
ability to add extra XML elements called response, one for each 200,
300, 400, to existing structures, providing
extensibility, and 500 series status code generated during the method
invocation. 100 series status codes MUST NOT be recorded by XML's ability to encode information in ISO
10646 character sets, providing internationalization support. As a
response
rule of thumb, parameters are encoded in XML element.
2.7.3.1 MultiResponse
Name: http://www.ietf.org/standards/dav/multiresponse
Purpose: Contains multiple response messages.
Schema: http://www.ietf.org/standards/dav/
Parent: Any
Value: 1*Response [ResponseDescription]
Description:The ResponseDescription at 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 an HTTP header. Section 9 describes
the top level new HTTP headers used with WebDAV methods.
In addition to encoding method parameters, XML is used in WebDAV to
provide a general message describing
encode the over arching nature of responses from methods, providing the response. If this value is available an application MAY use
it instead extensibility and
internationalization advantages of presenting XML for method output, as well as
input. XML elements used in this specification are defined in
Section 12.
While the individual response descriptions
contain within codes provided by HTTP/1.1 are sufficient to
describe the responses.
2.7.3.2 Response
Name: http://www.ietf.org/standards/dav/response
Purpose: Holds a single response
Schema: http://www.ietf.org/standards/dav/
Parent: Any
Value: (Prop | HREF) Status [ResponseDescription]
Description: Prop MUST contain one or more empty XML elements
representing preponderance of error conditions encountered by WebDAV
methods, there are some errors that do not fall neatly into the name of properties. Multiple properties
existing categories. New status codes developed for the WebDAV
methods are defined in Section 10. Since some WebDAV methods may be
included if
operate over many resources, the same response applies multiresponse status type has been
introduced to them all. If HREF return status information for multiple resources.
Multiresponse status is
used then the response refers described in Section 11.
The properties mechanism is employed by WebDAV to a problem with store information
about the referenced
resource, not current state of the resource. For example, when a property.
2.7.3.3 Status
Name: http://www.ietf.org/standards/dav/status
Purpose: Holds lock
is taken out on a single HTTP status-line
Schema: http://www.ietf.org/standards/dav/
Parent: Response
Value: status-line ;status-line defined in [Fielding et al.,
1997]
2.7.3.4 ResponseDescription
Name:
http://www.ietf.org/standards/dav/ResponseDescription
Purpose: Contains resource, a message that can be displayed to the user
explaining lock information property describes
the nature current state of the response.
Schema: http://www.ietf.org/standards/dav/
Parent: Multiresponse and/or Response
Value: Any
Description: This XML element provides information suitable lock. Section 13 defines the properties
used within the WebDAV specification.
Finishing off the specification are sections on what it means to be presented to a user.
2.8 Properties
compliant with this specification (Section 14), on
internationalization support (Section 15), and Methods
2.8.1 DELETE
As properties on security (Section
16).
3. Data Model for Resource Properties
3.1. The Resource Property Model
Properties are resources, the deletion of a property causes
the same result as the deletion pieces of any resource. It is worth
pointing out data that describe the deletion state of a property effects both direct
manipulation, that is by the property's URL, as well as indirect resource.
Properties are data about data.
Properties are used in distributed authoring environments to provide
for efficient discovery and manipulation, that is PROPPATCH and PROPFIND.
2.8.2 GET
A GET with a Request-URI that identifies management of resources. For example, a
'subject' property returns might allow for the
name and value indexing of that property. Accept types may be used to
specify all resources by
their subject, and an 'author' property might allow for the format
discovery of the return value, but all what authors have written which documents.
The DAV compliant
servers MUST at minimum support a return type property model consists of text/xml. If
text/xml is used as the response format then it MUST return the name/value pairs. The name and value of the a
property using the Prop XML element.
2.8.2.1 Example
The following example assumes that identifies the property's URL, originally
generated by the server, was discovered by examining the proploc
XML attribute returned on a result from a FINDPROP.
GET /bar.html;prop=z39.50_authors HTTP/1.1
Host: foo.com
HTTP/1.1 200 OK
Content-Type: text/xml
Content-Length: xxxx
E-tag: "1234"
Last-Modified: xxxx
<?XML:Namespace
href = "http://www.ietf.org/standards/dav/" AS = "D"/>
<?XML:Namespace
href = "http://www.w3.com/standards/z39.50/"AS = "Z"/>
<D:prop>
<Z:Authors>
<Z:Author>Jane Doe</Z:Author>
<Z:Author>Joe Doe</Z:Author>
<Z:Author>Lots o'Doe</Z:Author>
</Z:Authors>
</D:prop>
2.8.3 PROPPATCH
The PROPPATCH method processes instructions specified in the
request body to create and/or remove properties defined on the
resource identified syntax and semantics, and
provides an address by Request-URI.
All DAV compliant servers MUST process instructions which are
specified using the PropertyUpdate, Create, to refer to that syntax and Remove XML
elements of the DAV schema. The request message body MUST
contain at least one PropertyUpdate XML element. Instruction
processing MUST occur in the order instructions semantics.
There are received
(i.e., from top to bottom), two categories of properties: "live" and MUST be performed atomically.
2.8.3.1 PropertyUpdate XML element
Name: http://www.ietf.org/standards/dav/PropertyUpdate
Purpose: To contain a request to alter the properties on a
resource.
Schema: http://www.ietf.org/standards/dav/
Parent: Any
Values= *(Create | Remove)
Description:This XML element is a container for the information
required to modify the properties on "non-live". A
live property has its syntax and semantics enforced by the resource. server.
This XML
element is multi-valued.
2.8.3.2 Create XML element
Name: http://www.ietf.org/standards/dav/create
Purpose: To create represents the DAV properties specified inside two cases of a) the
Create XML element.
Schema: http://www.ietf.org/standards/dav/
Parent: http://www.ietf.org/standards/dav/PropertyUpdate
Values= Prop
Description:This XML element MUST contain only value of a Prop XML
element. The elements contained property is read-
only, maintained by Prop specify the name server, and b) the value of properties that are created on Request-URI. If a the property already exists then its value is replaced. The Prop XML
element MUST NOT contain a PropLoc XML attribute.
2.8.3.3 Remove XML element
Name: http://www.ietf.org/standards/dav/remove
Purpose: To remove
maintained by the DAV properties specified inside client, but server performs syntax checking on
submitted values. A non-live property has its syntax and semantics
enforced by the
Remove XML element.
Schema: http://www.ietf.org/standards/dav/
Parent: http://www.ietf.org/standards/dav/PropertyUpdate
Values= Prop
Description:Remove specifies that client; the properties specified in
Prop should be removed. Specifying server merely records the removal value of a the
property that
does not exist is not verbatim.
3.2. Existing Metadata Proposals
Properties have long played an error. All the elements essential role in Prop MUST be
empty, as only the names maintenance of
large document repositories, and many current proposals contain some
notion of properties to be removed are
required.
2.8.3.4 Response
The response MUST have a response body that contains a
multiresponse identifying property, or discuss web metadata more generally. These
include PICS [Miller et al., 1996], PICS-NG, the results for each property.
2.8.3.5 Response Codes
200 OK - The command succeeded. As there can be Rel/Rev draft
[Maloney, 1996], Web Collections, XML [Bray, Sperberg-McQueen,
1997], several proposals on representing relationships within HTML,
digital signature manifests (DCMF), and a mixture position paper on Web
metadata architecture [Berners-Lee, 1997]. Work on PICS-NG and Web
Collections has been subsumed by the Resource Definition Framework
(RDF) metadata activity of the World Wide Web Consortium, which
consists of
Create and Removes in a body, network-based data model and an XML representation of
that model.
Some proposals come from a 201 Create seems inappropriate.
403 Forbidden - The client, for reasons digital library perspective. These
include the server chooses not to
specify, can not alter one of Dublin Core [Weibel et al., 1995] metadata set and the properties.
405 Conflict - The client has provided
Warwick Framework [Lagoze, 1996], a value whose semantics
are not appropriate container architecture for the property. This
different metadata schemas. The literature includes trying to set
read only properties.
413 Request Entity Too Long - If many examples
of metadata, including MARC [MARC, 1994], a particular property is too
long to be recorded then bibliographic metadata
format, and RFC 1807 [Lasher, Cohen, 1995], a composite XML error will be returned
indicating the offending property.
417 Insufficient Space on Resource - The resource does not have
sufficient space to record technical report
bibliographic format employed by the state of Dienst system. Additionally,
the resource after proceedings from the
execution of this method.
418 Atomicity Failure - The command was not executed because first IEEE Metadata conference describe
many community-specific metadata sets.
Participants of
an atomicity failure elsewhere the caused 1996 Metadata II Workshop in Warwick, UK
[Lagoze, 1996], noted that, "new metadata sets will develop as the entire command to
be aborted.
2.8.3.6 Example
PROPPATCH /bar.html HTTP/1.1
Host: www.foo.com
Content-Type: text/xml
Content-Length: xxxx
<?XML:Namespace
href = "http://www.ietf.org/standards/dav/" AS = "D"/>
<?XML:Namespace
href = "http://www.w3.com/standards/z39.50/" AS = "Z"/>
<D:PropertyUpdate>
<Create>
<prop>
<Z:authors>
<Z:Author>Jim Whitehead</Z:Author>
<Z:Author>Roy Fielding</Z:Author>
</Z:authors>
</Prop>
</Create>
<Remove>
<prop><Z:Copyright-Owner/></prop>
</Remove>
</D:PropertyUpdate>
HTTP/1.1 405 Conflict
Content-Type: text/xml
Content-Length: xxxxx
<?XML:Namespace
href="http://www.ietf.org/standards/dav/" AS = "D"/>
<?XML:Namespace
href="http://www.w3.com/standards/z39.50/" AS = "Z"/>
<D:MultiResponse>
<ResponseDescription> Copyright Owner
networked infrastructure matures" and "different communities will
propose, design, and be responsible for different types of
metadata." These observations can not be deleted or
altered.</ResponseDescription>
<Response>
<Prop><Z:authors/></Prop>
<Status>HTTP/1.1 418 Atomicity Failure</Status>
</Response>
<Response>
<Prop><Z:Copyright-Owner/></Prop>
<Status>HTTP/1.1 405 Conflict</Status>
</Response>
</D:MultiResponse>
2.8.4 PUT
A PUT corroborated by noting that
many community-specific sets of metadata already exist, and there is specified
significant motivation for the development of new forms of metadata
as many communities increasingly make their data available in order
digital form, requiring a metadata format to control what is returned by assist data location
and cataloging.
3.3. Properties and HTTP Headers
Properties already exist, in a GET.
However limited sense, in HTTP message
headers. However, in distributed authoring environments a GET on
relatively large number of properties are needed to describe the
state of a property always returns resource, and setting/returning them all through HTTP
headers is inefficient. Thus a predefined property
containment format. Therefore PUT can not be used if the Request-
URI refers mechanism is needed which allows a
principal to identify a property.
2.8.5 PROPFIND
The PROPFIND method retrieves set of properties defined on Request-URI. in which the principal is
interested and to then set or retrieve just those properties.
3.4. Property Values
The request message body value of a property is an expressed as a well-formed XML document that MUST contain
only one PropFind document.
XML element, which specifies the type has been chosen because it is a flexible, self-describing,
structured data format that supports rich schema definitions, and
because of
property find action its support for multiple character sets. XML's self-
describing nature allows any property's value to be performed. The XML element contained extended by PropFind specifies
adding new elements. Older clients will not break because they will
still have the type of action data specified in the original schema and will ignore
elements they do not understand. XML's support for multiple
character sets allows human-readable properties to be performed:
retrieve all property names and values (AllProp), retrieve only
specified property names encoded and values (Prop), or retrieve only
read in a
list of all character set familiar to the user.
3.5. Property Names
A property names (Propname). When name is a Prop XML element universally unique identifier that is present, it specifies
associated with a list of schema that provides information about the names of properties whose
name syntax
and value are to be returned. The Prop element, when used
within semantics of the property.
Because a FINDPROP request body MUST be empty.
The response property's name is universally unique, clients can depend
upon consistent behavior for a text/xml message body particular property across multiple
resources, so long as that contains a
MultiResponse property is "live" on the resources in
question.
The XML element namespace mechanism, which describes the results of the
attempts is based on URIs, is used to retrieve the various properties. If name
properties because it provides a mechanism to prevent namespace
collisions and for varying degrees of administrative control.
The property was
successfully retrieved then its value MUST be returned in the
prop XML element. In the case namespace is flat; that is, no hierarchy of Allprop and Findprop, properties
is explicitly recognized. Thus, if a
principal does not have the right to know if property A and a particular property exists, an error MUST NOT be returned. The results A/B
exist on a resource, there is no recognition of
this method SHOULD NOT any relationship
between the two properties. It is expected that a separate
specification will eventually be cached.
2.8.5.1 Propfind XML element
Name: http://www.ietf.org/standards/dav/Propfind
Purpose: To specify 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 set resource's
property namespace.
4. Collections of matching properties
Schema: http://www.ietf.org/standards/dav/
Parent: Any
Values= (Prop | Allprop | Propname)
Description: Propfind is Web Resources
This section provides a container element for description of a new type of Web resource,
the exact
specification collection, and discusses its interactions with the HTTP URL
namespace. The purpose of a PROPFIND request.
2.8.5.2 Allprop
Name: http://www.ietf.org/standards/dav/Allprop
Purpose: To specify that all properties are collection resource is to be returned
Schema: http://www.ietf.org/standards/dav/
Parent: Propfind
Description: Its presence in model
collection-like objects (e.g., filesystem directories) within a PROPFIND request specifies
server's namespace.
All DAV compliant resources MUST support the
name HTTP URL namespace
model specified herein.
4.1. Collection Resources
A collection is a resource whose state consists of an unordered list
of internal members, an unordered list of external members, and value a
set of all properties defined on the properties. An internal member resource MUST be
returned.
2.8.5.3 Propname
Name: http://www.ietf.org/standards/dav/Propname
Purpose: To specify have a URI that
is immediately relative to the names base URI of all properties defined on the resource are to be returned.
Schema: http://www.ietf.org/standards/dav/
Parent: Propfind
Description: Its presence collection, that is,
a relative URI in which "../" is illegal, which MUST begin with "./"
and which SHOULD contain a PROPFIND request specifies "/" at the
name end of all properties defined on the resource MUST be returned.
2.8.5.4 PropFindResult XML element
Name: http://www.ietf.org/standards/dav/PropFindResult
Purpose: To contain URI if the results of a SEARCH request
Schema: http://www.ietf.org/standards/dav/
Parent: Any
Values: Prop
2.8.5.5 Example 1 - Prop
PROPFIND /container/ HTTP/1.1
Host: www.foo.bar
Content-Length: xxxx
Content-Type: text/xml
<?XML:Namespace href =
"http://www.ietf.org/standards/dav/" AS = "G"/>
<?XML:Namespace href =
"http://www.foo.bar/boxschema/" AS = "B"/>
<G:PROPFIND>
<prop>
<B:bigbox>
<B:author>
<B:DingALing>
<B:Random>
</prop>
</G:PROPFIND>
HTTP/1.1 207 Multi-Response
Content-Type: text/xml
Content-Length: xxxxx
<?XML:Namespace
href ="http://www.ietf.org/standards/dav/" AS = "S">
<?XML:Namespace href = "http://www.foo.bar/boxschema" AS = R">
<D:MultiResponse>
<ResponseDescription> There has been internal
member resource is itself a collection.
An external member resource MUST be an access violation
error. </ResponseDescription>
<Response>
<Prop>
<R:bigbox D:Proploc="http://prop.com/BoxType">
<BoxType>Box type A</BoxType>
</R:bigbox>
<R:author D:Proploc="http://prop.com/Author">
<Name>J.J. Dingleheimerschmidt</Name>
</R:author>
</Prop>
<Status>HTTP/1.1 200 Success</Status>
</Response>
<Response>
<Prop><R:DingALing/><R:Random/></>
<Status>HTTP/1.1 403 Forbidden</Status>
<ResponseDescription> The user does absolute URI that is not have access an
internal URI. Any given internal or external URI MUST only belong
to the DingALink property. </ResponseDescription>
</Response>
</D:MultiResponse>
The result will return all 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.
There is a standing convention that when a collection is referred to
by its name without a trailing slash, the container. 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 only two properties were found. The principal did not have
sufficient access rights it
SHOULD return a location header in the response pointing to see the third and fourth properties
so an error was returned.
2.8.5.6 Example 2 - Allprop
PROPFIND /container/ HTTP/1.1
Host: www.foo.bar
Content-Length: xxxx
Content-Type: text/xml
<?XML:Namespace href =
"http://www.ietf.org/standards/dav/" AS = "G"/>
<G:PROPFIND>
<Allprop/>
</G:PROPFIND>
HTTP/1.1 200 Success
Content-Type: text/xml
Content-Length: xxxxx
<?XML:Namespace href =
"http://www.ietf.org/standards/dav/" As = "S">
<?XML:Namespace href = "http://www.foo.bar/boxschema" AS = R">
<S:MultiResponse>
<Prop>
<R:bigbox D:Proploc="http://prop.com/BigBox">
<BoxType>Box type A</BoxType>
</R:bigbox>
<R:author D:Proploc="http://prop.com/Author">
<Name>Hadrian</Name>
</R:author>
</Prop>
<Status>HTTP/1.1 200 Success</Status>
</S:MultiResponse>
This particular client only had URL
ending with the right to see two properties,
BoxType and Author. No error is returned for "/". For example, if a client performs an INDEX on
http://foo.bar/blah (no trailing slash), the remaining
properties, resource
http://foo.bar/blah/ (trailing slash) MAY respond as if the client does not even have sufficient rights
operation were invoked on it, and SHOULD return a location header
with http://foo.bar/blah/ in it.
4.2. Creation and Retrieval of Collection Resources
This document specifies the MKCOL method to
know they exist. If create new collection
resources, rather than using the existing HTTP/1.1 PUT or POST
method, for the client did have following reasons
In HTTP/1.1, the right PUT method is defined to know they
existed but did not have store the right to see their value, request body at
the location specified by the Request-URI. While a 207
multi-response description
format for a collection can readily be constructed for use with PUT,
the implications of sending such a multiresponse, as used in description to the previous server are
undesirable. For example, would have been returned.
2.8.5.7 Example 3 - Propname
PROPFIND /container/ HTTP/1.1
Host: www.foo.bar
Content-Length: xxxx
Content-Type: text/xml
<?XML:Namespace
href = "http://www.ietf.org/standards/dav/" AS = "G"/>
<G:PROPFIND>
<Propname/>
</G:PROPFIND>
HTTP/1.1 200 Success
Content-Type: text/xml
Content-Length: xxxxx
<?XML:Namespace
href = "http://www.ietf.org/standards/dav/" As = "S">
<?XML:Namespace
href = "http://www.foo.bar/boxschema" AS = "R">
<S:MultiResponse>
<Prop>
<R:bigbox D:Proploc="http://prop.com/BigBox"/>
<R:author D:Proploc="http://prop.com/Author"/>
<R:DingALing/>
<R:Random/>
</Prop>
<Status>HTTP/1.1 200 Success</Status>
</S:MultiResponse>
In this case only two 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 properties have direct URLs
available, while semantics of PUT, and makes it difficult to control
DELETE functionality with an access control scheme based on methods.
While the other two properties can only POST method is sufficiently open-ended that a _create a
collection_ POST command could be referenced
via PROPFIND and PROPPATCH.
3 A Proposal constructed, this is undesirable
because it would be difficult to separate access control for Collections
collection creation from other uses of POST.
This document specifies the INDEX method for listing the contents of
a collection, rather than relying on the existing HTTP/1.1 GET
method. This is to avoid conflict with the de-facto standard
practice of redirecting a GET request on a directory to its
index.html resource.
The exact definition of Web Resources the behavior of GET and Name Space
Operations
3.1 Observations PUT on the collections
is defined later in this document.
4.3. HTTP Object URL Namespace Model
This section provides a description of
The HTTP URL Namespace is a new type of Web
resource, hierarchical namespace where the collection, and discusses its interactions
hierarchy is delimited with the "/" character. DAV compliant
resources MUST maintain the consistency of the HTTP URL namespace. This discussion is
Any attempt to create a prerequisite for resource (excepting the
specification root member of methods a
namespace) that operate on collections, given later
in this document.
3.1.1 Collection Resources
A would not be the internal member of a collection is
MUST fail. For example, if the collection http://www.foo.bar.org/a/
exists, but http://www.foo.bar.org/a/b/does not exist, an attempt to
create http://www.foo.bar.org/a/b/c must fail.
4.4. Source Resources and Output Resources
For many resources, the entity returned by a resource whose GET method exactly
matches the persistent state consists of the resource, for example, a list of
internal members, GIF
file stored on a list of external members, and disk. For this simple case, the URL at which a set
resource is accessed is identical to the URL at which the source
(the persistent state) of
properties. An internal member the resource MUST have a URI 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, server-side-
include directives within an HTML file 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
immediately relative no way to access the base URI of HTML resource containing the collection, that is,
a relative URI in which "../"
unprocessed directive.
Sometimes the entity returned by GET is illegal, which must begin with
"./" and which MAY contain only one other "/" at the end output of the
URI. An external member resource MUST be an absolute URI a data-
producing process that is
not an internal URI. Any given internal described by one or external URI MUST
only belong to more source resources
(that may not even have a location in the collection once, i.e., multiple instances URL namespace). A single
data-producing process may dynamically generate the state of
URIs in a collection are illegal. Properties defined on
collections have no special distinction, and behave exactly as do
properties on non-collection
potentially large number of output resources.
The purpose An example of a collection resource this is to model collection-like
objects (e.g., a filesystem directory) within a server's
namespace. Once these objects have been modeled with
collections, a client may perform an INDEX, add and remove
external members using ADDREF and DELREF, and perform recursive
operations, such as
a full hierarchy copy.
To support methods which operate on collections, a server SHOULD
model its collection-like objects with collection resources. For
example, CGI script that describes a server which is implemented on top "finger" gateway process that maps
part of a filesystem
SHOULD treat all filesystem directories exposed by the namespace of a server into finger requests, such as
collection resources.
3.1.2 Creation and Retrieval of Collection Resources
This document specifies
http://www.foo.bar.org/finger_gateway/user@host.
In the MKCOL method absence of distributed authoring capabilities, it is
acceptable to create new collection
resources, and the INDEX method have no mapping of source resource(s) to list their contents. the URI
namespace. In HTTP/1.1, fact, preventing access to the PUT method source resource(s) has
desirable security benefits. However, if remote editing of the
source resource(s) is defined to store desired, the request body
at source resource(s) should be
given a location in the URI namespace. This source location specified by Request-URI. While a description
format for a collection can readily be constructed that could should
not be
used with PUT, the implications one of sending such a description to the locations at which the generated output is
retrievable, since in general it is impossible for the server are undesirable. For example, if to
differentiate requests for source resources from requests for
process output resources. There is often a description of many-to-many
relationship between source resources and output resources.
On WebDAV compliant servers, for all output resources which have a
collection
single source resource (and that omitted some existing resources were PUT to source resource has a
server, this might URI), the URI
of the source resource SHOULD be interpreted as stored in a command to remove those
members. This would extend PUT to perform DELETE functionality,
which is undesirable since it changes link on the semantics of PUT, and
makes it difficult to control DELETE functionality output
resource with an access
control scheme based type http://www.ietf.org/standards/dav/source. Note
that by storing the source URIs in links on methods.
While the POST method output resources,
the burden of discovering the source is sufficiently open-ended placed on the authoring
client.
5. 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 "create reasonable guarantee that another principal will not
modify a
collection" POST command could be constructed, this is
undesirable because resource while it would be difficult to separate access
control for collection creation from other uses of POST if they
both use is being edited. In this way, a client
can prevent the same method.
While it might seem desirable "lost update" problem.
This specification allows locks to have GET return a listing vary over two client-specified
parameters, the number of principals involved (exclusive vs. shared)
and the
members type of a collection, access to be granted. Furthermore, this is foiled by document
only provides the existence definition of locking for one lock access type,
the
"index.html" de-facto standard namespace redirection, in which a
GET request on a collection write lock. However, the syntax is automatically redirected to extensible, and permits the
index.html resource.
The exact definition
eventual specification of the behavior other access types.
5.1. Exclusive Vs. Shared Locks
The most basic form of GET and PUT on
collections lock is defined later an exclusive lock. This is a lock
where the access right in this document.
3.1.2.1 Example
The structured resource http://foo/bar question is created with only granted to a PUT. Bar single
principal. The need for this arbitration results from a desire to
avoid having to constantly merge results.
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 multipart/related file
mechanism for principals to indicate that they intend to exercise
their access right. 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 members http://foo/bar/a and
http://foo/bar/b. If bar were deleted then both trust sets that affect a and b would
also be deleted since they resource.
The first trust set is created by access permissions. Principals
who are all really just one trusted, for example, may have permission to write the
resource. If
http://foo/bar/a/c was PUT then Those who are not, don't. Among those who have access
permission to write the resource, the set of principals who have
taken out a DELETE on http://foo/bar/a
would shared lock also delete http://foo/bar/a/c as c was created with a PUT
not must trust each other, creating a MKCOL.
If http://foo/bar/b/d is created
(typically) smaller trust set within the access permission write
set.
Starting with a MKCOL and
http://foo/bar/b/d/e was created then a DELETE every possible principal on d would fail
because d is a collection with an internal member. However the
existence of Internet, in most
situations the collection d is something vast majority of an illusion. If a
DELETE was executed on http://foo/bar then everything would be
deleted, even though http://foo/bar/b/d was created with these principals will not have write
access to a MKCOL.
Thus given resource. Of the effect of a MKCOL within a composite resource’s
namespace is felt on its children, 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 its ancestors. The
children overwrite their work
(the potential set of d MUST be treated as members collaborators being the set of a collection when a
method is executed on d. But a method executed on b or a is
treated as if there only existed a non-collection resource.
3.1.3 Source Resources principals who
have write permission) and Output Resources
For many resources, the entity returned by GET exactly matches use a shared lock, which informs their
collaborators that a principal is potentially working on the persistent state
resource.
The WebDAV extensions to HTTP do not need to provide all of the resource,
communications paths necessary for example, a GIF file
stored 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 a disk. For this simple case, the URL at which screen,
telephone conversation, Email, etc.) The intent of a
resource shared lock is accessed
to let collaborators know who else is identical potentially working on a
resource.
Shared locks are included because experience from web distributed
authoring systems has indicated that exclusive write locks are often
too rigid. An exclusive write lock is used to enforce a particular
editing process: take out exclusive write lock, read the URL at which resource,
perform edits, write the source
(the persistent state) of resource, release the resource is accessed. lock. This is also editing
process has the case for HTML source files problem that locks are not processed by the
server prior to transmission.
However, the server can sometimes process HTML resources before
they are transmitted as always properly released,
for example when a return entity body. For example,
server-side-include directives within an HTML file instruct program crashes, or when a
server lock owner leaves
without unlocking a resource. While both timeouts and
administrative action can be used to replace the directive with another value, such as remove an offending lock,
neither mechanism may be available when needed; the
current date. In this case, what is returned by GET (HTML plus
date) differs from timeout may be
long or the persistent state administrator may not be available.
Despite their potential problems, exclusive write locks are
extremely useful, since often a guarantee of the resource (HTML
plus directive). Typically there freedom from overwrite
conflicts is no way to access the HTML
resource containing the unprocessed directive.
Sometimes the entity returned by GET what is needed. This specification provides both
exclusive write locks and the output less strict mechanism of a data-
producing process that shared locks.
5.2. Required Support
A WebDAV compliant server is described by one or more source
resources (that may not even have a location required to support locking in any
form. If the URL
namespace). A single data-producing process may dynamically
generate the state of a potentially large number of output
resources. An example 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 a CGI script that describes a
"finger" gateway process that maps part of locking policy strikes to
the namespace very heart of a
server into finger requests, such as
http://www.foo.bar.org/finger_gateway/user@host.
In the absence resource management and versioning systems
employed by various storage repositories. These repositories
require control over what sort of distributed authoring capability, it 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
acceptable sufficiently
different to have no mapping merit exclusion of source resource(s) to certain locking features, this
specification leaves locking as the URI
namespace, and in fact has desirable security benefits. However,
if remote editing sole axis of the source resource(s) negotiation within
WebDAV.
5.3. Lock Tokens
A lock token 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 that identifies a particular lock. A lock
token is retrievable, since returned by every successful LOCK operation in
general it is impossible for the server lock-
token response header, and can also be discovered through lock
discovery on a resource.
Lock token URIs are required to differentiate requests
for source be unique across all resources from requests for process output resources.
There is often a many-to-many relationship between source
all time. This uniqueness constraint allows lock tokens to be
submitted across resources and output resources.
For DAV compliant servers all output resources which have without fear of confusion.
This specification provides a
single source resource (and lock token URI scheme called
opaquelocktoken that source resource has a URI), meets the uniqueness requirements. However
resources are free to return any URI of scheme so long as it meets the source resource SHOULD
uniqueness requirements.
5.4. opaquelocktoken Lock Token URI Scheme
The opaquelocktoken URI scheme is designed to be stored unique across all
resources for all time. Due to this uniqueness quality, a client
MAY submit an opaque lock token in a single link Lock-Token request header and
an if-state[-not]-match header on
the output a resource with type
http://www.ietf.org/standards/dav/source. Note other than the one that
returned it.
All resources MUST recognize the opaquelocktoken scheme and, at
minimum, recognize that the lock token was not generated by storing the source URI
resource. Note, however, that resources are not required to
generate opaquelocktokens in links on LOCK method responses.
In order to guarantee uniqueness across all resources for all time
the output resources, opaquelocktoken requires the burden use of
discovering the source is placed on the authoring client.
3.2 MKCOL Method
3.2.1 Problem Description
A client must be able to GUID mechanism.
Opaquelocktoken generators, however, have a choice of how they
create these tokens. They can either generate a collection.
3.2.2 Solution Requirements
The solution must ensure that new GUID for every
lock token they create, which is potentially very expensive, or they
can create a collection has been made (i.e. single GUID and then add extension characters. If the
second method is selected then the program generating the extensions
MUST guarantee that it responds to the INDEX method) as opposed to a non-
collection resource. If a collection could not same extension will never be made, it must
indicate this failure to used twice with
the user-agent.
3.2.3 Request
MKCOL creates associated GUID.
Opaque-Lock-Token = "opaquelocktoken" ":" GUID [Extension]
GUID = ; As defined in [Leach, Salz, 1997]
Extension = *urlc ;urlc is defined in [Berners-Lee et al., 1997]
(draft-fielding-url-syntax-07.txt)
5.5. Lock Capability Discovery
Since server lock support is optional, a client trying to lock a new collection
resource at on a server can either try the location specified
by lock and hope for the Request-URI. If best,
or perform some form of discovery to determine what lock
capabilities the Request-URI exists, then MKCOL must
fail. During MKCOL processing, a server MUST make the Request-URI
a member supports. This is known as lock capability
discovery. Lock capability discovery differs from discovery of its parent collection. If no such an ancestor exists,
supported access control types, since there may be access control
types without corresponding lock types. A client can determine what
lock types the method MUST fail. When server supports by retrieving the MKCOL operation creates a new
collection resource, all ancestors MUST already exist, or supportedlock
property.
Any DAV compliant resource that supports the LOCK method MUST fail with
support the supportedlock property.
5.6. Active Lock Discovery
If another principal locks a 409 Conflict status code. For example,
if resource that a request principal wishes to create collection /a/b/c/d/ is made, and neither
/a/b/ nor /a/b/c/ exist, the request MUST fail.
3.2.3.1 MKCOL Without Request Body
When MKCOL
access, it is invoked without a request body, the newly created
collection has no members.
3.2.3.2 MKCOL With Request Body
A MKCOL request message MAY contain a message body. The behavior
of a MKCOL request when useful for the body is present is limited second principal to
creating collections, members of a collection, bodies of members
and properties on be able to find out
who the collections or members. If first principal is. For this purpose 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 lockdiscovery
property is undefined in this document, provided. This property lists all outstanding locks,
describes their type, and will be specified
in separate documents.
3.2.4 Response
Responses from a MKCOL request are not cacheable, since MKCOL has
non-idempotent semantics.
201 (Created) - The collection or structured provides their lock token.
Any DAV compliant resource was created
in its entirety.
403 (Forbidden) - that supports the LOCK method MUST
support the lockdiscovery property.
6. Write Lock
This indicates at least one of two conditions:
1) The server does not allow section describes the creation semantics specific to the write access
type for locks. The write lock is a specific instance of collections at a lock
type, and is the
given location only lock type described in its namespace, and 2) The parent collection of this specification. A
DAV compliant resource MAY support the Request-URI exists but cannot accept members.
409 (Conflict) - write lock.
6.1. Methods Restricted by Write Locks
A collection cannot be made at write lock prevents a principal without the Request-URI
until one lock from successfully
executing a PUT, POST, PATCH, PROPPATCH, MOVE, DELETE, MKCOL, ADDREF
or more intermediate collections have been created.
415 (Unsupported Media Type)- The server does not support DELREF on the
request type locked resource. All other current methods, GET in
particular, function independent of the body.
417 (Insufficient Space lock.
Note, however, that as new methods are created it will be necessary
to specify how they interact with a write lock.
6.2. Write Locks and Properties
While those without a write lock may not alter a property on Resource) - The a
resource does not have
sufficient space to record it is still possible for the state values of live properties to
change, even while locked, due to the resource after the
execution requirements of this method.
3.2.5 Example
This example creates their schemas.
Only dead properties and live properties defined to respect locks
are guaranteed not to change while write locked.
6.3. Write Locks and Null Resources
It is possible to assert a container collection called
/webdisc/xfiles/ write lock on a null resource in order to
lock the server www.server.org.
MKCOL /webdisc/xfiles/ HTTP/1.1
Host: www.server.org
HTTP/1.1 201 Created
3.3 Standard DAV Properties
The following name. Please note, however, that locking a null resource
effectively makes the resource non-null, as the resource now has
lock related properties are defined on DAV compliant resources.
All enclosed properties are part it.
6.4. Write Locks and Collections
A write lock on a collection prevents the addition or removal of
members of the DAV Schema.
3.3.1 IsCollection Property
Name: http://www.ietf.org/standards/dav/iscollection
Purpose: This property contains collection. As a Boolean value that is set consequence, when a principal
issues a request to
"true" if the resource is create a new internal member of a collection
Schema: http://www.ietf.org/standards/dav/
Value: ("true" | "false")
Description: This property
using PUT or POST, or to remove an existing internal member of a
collection using DELETE, this request MUST be defined fail if the principal
does not have a write lock on all DAV compliant
resources.
3.3.2 DisplayName Property
Name: http://www.ietf.org/standards/dav/displayname
Purpose: A name for the resource that collection.
However, if a write lock request is suitable for
presentation issued to a user.
Schema: http://www.ietf.org/standards/dav/
Value: Any valid XML character data (as defined collection
containing internal member resources that are currently locked in [Bray,
Sperberg-McQueen, 1997])
Description: This property SHOULD be defined on all DAV compliant
resources. If present, a
manner which conflicts with the property contains write lock, the request MUST fail
with a description 409 Conflict status code.
6.5. Write Locks and COPY/MOVE
The owner of the a write lock MUST NOT execute a MOVE method on a
resource that he has locked. This specification intentionally does not
define what happens if a MOVE method request is suitable for presentation to made on a user.
3.3.3 CreationDate Property
Name: http://www.ietf.org/standards/dav/creationdate
Purpose: The time and date the locked
resource was created.
Schema: http://www.ietf.org/standards/dav/
Value: The time and date by the lock's owner.
A COPY method invocation MUST be given in ISO 8601 format
[ISO8601]
Description: This property SHOULD be defined NOT duplicate any write locks active
on all DAV compliant
resources. the source.
6.6. Re-issuing Write Locks
If present, it contains a timestamp of the moment when
the resource was created (i.e., the moment it had non-null
state).
3.3.4 GETentity Property
Name: http://www.ietf.org/standards/dav/GETentity
Purpose: Contains principal already owns a write lock on a resource, any future
requests for the value same type of headers that are returned by a
GET without Accept headers.
Schema: http://www.ietf.org/standards/dav/
Value: Content-Type Content-Length Content-Language Last-
Modified Etag Creation-Date
Description: This property MUST be defined write lock, on all DAV compliant
resources unless GET the same resource,
while the principal's previous write lock is not supported, in which case this
property MUST NOT be defined. This property effect, MUST contain at most
one instance of each element result
in its Value, if they are defined.
3.3.5 INDEXentity Property
Name: http://www.ietf.org/standards/dav/INDEXentity
Purpose: Contains a successful response with the value of headers that same lock token as provided for
the currently existing lock. Two lock requests are returned by an
INDEX.
Schema: http://www.ietf.org/standards/dav/
Value: Content-Type Content-Length Content-Language Last-
Modified Etag Creation-Date
Description: This property MUST be defined on all DAV compliant
resources unless INDEX is not supported, in which case this
property MUST NOT to be defined. This property MUST contain at most
one instance of each element in its Value,
identical if they their Lock-Info headers are defined.
3.3.6 Content-Type XML Element
Name: http://www.ietf.org/standards/dav/content-type
Purpose: identical.
6.7. Write Locks and The content-type of Lock-Token Request Header
If a user agent is not required to have knowledge about a lock when
requesting an operation on a locked resource, the member following scenario
might occur. Program A, run by User A, takes out a write lock on a
resource.
Schema: http://www.ietf.org/standards/dav/
Parent: GETentity or INDEXentity
Value: media-type ; defined in Section 3.7 Program B, also run by User A, has no knowledge of [Fielding et
al., 1997]
Description: If the parent of
lock taken out by Program A, yet performs a PUT to the locked
resource. In this element is GETentity, scenario, the
value MUST be identical 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 content-type returned by a GET on PUT. However, had program B known about the resource without Accept headers. If lock, it
would not have overwritten the parent is
INDEXentity, resource, preferring instead to
present a dialog box describing the value MUST be identical conflict to the content-type
returned user. Due to
this scenario, a mechanism is needed to prevent different programs
from accidentally ignoring locks taken out by an INDEX on other programs with
the resource. If no content-type same authorization.
In order to prevent these collisions the lock token request header
is
available, introduced. Please refer to the Lock Token Request Header
section for details and requirements.
6.7.1. Write Lock Token Example
COPY /~fielding/index.html HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/users/f/fielding/index.html
Lock-Token: <opaquelocktoken:123AbcEfg1284h23h2>
<opaquelocktoken:AAAASDFcalkjfdas12312>
HTTP/1.1 200 OK
In this element MUST NOT example, both the source and destination are locked so two
lock tokens must be defined.
3.3.7 Content-Length XML Element
Name: http://www.ietf.org/standards/dav/content-length
Purpose: Describes submitted. If only one of the default content-length two resources was
locked, then only one token would have to be submitted.
7. Notational Conventions
Since this document describes a set of extensions to the resource.
Schema: http://www.ietf.org/standards/dav/
Value: content-length ; see section 14.14 HTTP/1.1
protocol, the augmented BNF used herein to describe protocol
elements is exactly the same as described in Section 2.1 of RFC 2068
Description: If
2068, _Hypertext Transfer Protocol -- HTTP/1.1_ [Fielding et al.,
1997]. Since this augmented BNF uses the parent basic production rules
provided in Section 2.2 of RFC 2068, these rules apply to this element is GETentity,
document as well.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
element MUST have a value equal
document are to be interpreted as described in RFC 2119 [Bradner,
1997].
8. HTTP Methods for Distributed Authoring
8.1. PROPFIND
The PROPFIND method retrieves properties defined on the content-length header
returned by Request-URI,
if it is a GET non-collection resource, or on the resource without Accept headers. If Request-URI and
potentially its member resources, if the
parent resource is INDEXentity, a collection.
All DAV compliant resources MUST support the PROPFIND method.
A client MAY submit a Depth header with a PROPFIND on a collection
with a value of "0", "1" or "infinity". DAV compliant servers MUST be identical to
support the
content-length returned by an INDEX on "0", "1" and "infinity" behaviors. By default, the resource. If no
content-length is available, this element
PROPFIND method on a collection without a Depth header MUST NOT be defined.
3.3.8 Content-Language XML Element
Name: http://www.ietf.org/standards/dav/content-language
Purpose: Describes the default natural language of act as
if a resource.
Schema: http://www.ietf.org/standards/dav/
Value: language-tag ;language-tag Depth = infinity header was included.
A client MUST submit a Propfind request header describing what
information is defined in section
14.13 being requested. It is possible to request
particular property values, all property values, or a list of RFC 2068
Description: If the parent
names of this element the resource's properties.
The response is GETentity, this
element MUST have a value equal to the content-language header
returned by text/xml message body that contains a GET on multistatus
XML element that describes the resource without Accept headers. If results of the
parent is INDEXentity, attempts to retrieve
the various properties. If a property was successfully retrieved
then its value MUST be identical to the
content-language header returned by an INDEX on the resource. in a prop XML element. If
no content-language header the scope
of PROPFIND covers more than a single resource, as is available, this the case with
Depth values of "1" and "infinity", each response XML element MUST NOT be
defined.
3.3.9 Last-Modified
contain an href XML Element
Name: http://www.ietf.org/standards/dav/last-modified
Purpose: The date element which identifies the resource was last modified.
Schema: http://www.ietf.org/standards/dav/
Parent: GETentity or INDEXentity
Value: The date MUST be given in RFC 1123 format using on which
the
rfc-1123 production, defined properties in section 3.3.1 of [Fielding et al.,
1997].
Description: If the parent of this element is GETentity, this prop XML element MUST have a value equal to are defined. In the last-modified header
returned by case of
allprop and propname, if a GET on the resource without Accept headers. If the
parent is INDEXentity, principal does not have the value right to know
if a particular property exists, an error MUST NOT be identical returned. The
results of this method SHOULD NOT be cached.
8.1.1. Example: Retrieving Named Properties
PROPFIND /files/ HTTP/1.1
Host: www.foo.bar
Depth: 0
Propfind: <http://www.foo.bar/boxschema/bigbox> <http://www.foo.bar/
boxschema/author> <http://www.foo.bar/boxschema/DingALing> <http://w
ww.foo.bar/boxschema/Random>
HTTP/1.1 207 Multi-Status
Content-Type: text/xml
Content-Length: xxxxx
<?XML version="1.0">
<?namespace href ="http://www.ietf.org/standards/dav/" AS = "D"?>
<?namespace href = "http://www.foo.bar/boxschema" AS = R"?>
<D:multistatus>
<D:response>
<D:prop>
<R:bigbox>
<R:BoxType>Box type A</R:BoxType>
</R:bigbox>
<R:author>
<R:Name>J.J. Dingleheimerschmidt</R:Name>
</R:author>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
<D:response>
<D:prop><R:DingALing/><R:Random/></D:prop>
<D:status>HTTP/1.1 403 Forbidden</D:status>
<D:responsedescription> The user does not have access to the last-
modified header returned by
DingALing property.
</D:responsedescription>
</D:response>
<D:responsedescription> There has been an INDEX access violation error.
</D:responsedescription>
</D:multistatus>
In this example, PROPFIND is executed on the resource. If no
last-modified header is available, this element MUST NOT be defined.
3.3.10 Etag XML Element
Name: http://www.ietf.org/standards/dav/etag
Purpose: collection
http://www.foo.bar/files/. The entity tag of specified depth is zero, hence the resource.
Schema: http://www.ietf.org/standards/dav/
Parent: GETentity or INDEXentity
Value: entity-tag ; defined in Section 3.11
PROPFIND applies only to the collection itself, and not to any of [Fielding et
al., 1997]
Description: If
its members. The Propfind header specifies the parent name of four
properties whose values are being requested. In this element is GETentity, this
element MUST case only two
properties were returned, since the principal issuing the request
did not have a value equal sufficient access rights to see the entity-tag header returned
by a GET third and fourth
properties.
8.1.2. Example: Using allprop to Retrieve All Properties
PROPFIND /container/ HTTP/1.1
Host: www.foo.bar
Depth: 1
Propfind: allprop
HTTP/1.1 200 OK
Content-Type: text/xml
Content-Length: xxxxx
<?XML version="1.0">
<?namespace href = "http://www.ietf.org/standards/dav/" As = "S"?>
<?namespace href = "http://www.foo.bar/boxschema/" AS = R"?>
<S:multistatus>
<S:response>
<S:href>http://www.foo.bar/container/</S:href>
<S:prop>
<R:bigbox>
<R:BoxType>Box type A</R:BoxType>
</R:bigbox>
<R:author>
<R:Name>Hadrian</R:Name>
</R:author>
</S:prop>
<S:status>HTTP 1.1 200 OK</S:status>
</S:response>
<S:response>
<S:href>http://www.foo.bar/container/index.html</S:href>
<S:prop>
<R:bigbox>
<R:BoxType>Box type B</R:BoxType>
</R:bigbox>
</S:prop>
<S:status>HTTP 1.1 200 OK</S:status>
</S:response>
</S:multistatus>
In this example, PROPFIND was invoked on the resource without Accept headers. If the parent
is INDEXentity,
http://www.foo.bar/container/ with a Depth header of 1, meaning the value MUST be identical
request applies to the entity-tag resource and its children, and a Propfind
header returned by an INDEX on of "allprop", meaning the request should return the name and
value of all properties defined on each resource. If no entity-tag
header is available, this element MUST NOT be defined.
3.4 INDEX Method
3.4.1 Problem Description
A mechanism is needed to discover if
The resource http://www.foo.bar/container/ has two properties
defined on it, named http://www.foo.bar/boxschema/bigbox, and
http://www.foo.bar/boxschema/author, while resource
http://www.foo.bar/container/index.html has only a single resource
defined on it, named http://www.foo.bar/boxschema/bigbox, another
instance of the "bigbox" property type.
8.1.3. Example: Using propname to Retrieve all Property Names
PROPFIND /container/ HTTP/1.1
Host: www.foo.bar
Propfind: propname
HTTP/1.1 200 OK
Content-Type: text/xml
Content-Length: xxxx
<?XML version="1.0">
<?namespace href = "http://www.ietf.org/standards/dav/" As = "D"?>
<?namespace href = "http://www.foo.bar/boxschema/" AS = "R"?>
<D:multistatus>
<D:response>
<D:href>http://www.foo.bar/container/</D:href>
<D:prop>
<R:bigbox/>
<R:author/>
</D:prop>
<D:status>HTTP 1.1 200 OK</D:status>
</D:response>
<D:response>
<D:href>http://www.foo.bar/container/index.html</D:href>
<D:prop>
<R:bigbox/>
</D:prop>
<D:status>HTTP 1.1 200 OK</D:status>
</D:response>
</D:multistatus>
In this example, PROPFIND is a invoked on the collection
and if so, list its members.
3.4.2 Solution Requirements
The solution:
- must allow resource
http://www.foo.bar/container/, with a client Propfind header set to discover
"propname", meaning the members name of a collection
- must always provide a machine-readable description all properties should be returned.
Since no depth header is present, it assumes its default value of
"infinity", meaning the
membership name of a the properties on the collection
- must and
all its progeny should be leveraged as a more general mechanism to provide a
list of contents for any returned.
Consistent with the previous example, resource which can profitably return a
membership like listing.
3.4.3 The Request
http://www.foo.bar/container/ has two properties defined on it,
http://www.foo.bar/boxschema/bigbox, and
http://www.foo.bar/boxschema/author. The INDEX method returns resource
http://www.foo.bar/container/index.html, a machine-readable representation member of the
membership of "container"
collection, has only one property defined on it,
http://www.foo.bar/boxschema/bigbox.
8.2. PROPPATCH
The PROPPATCH method processes instructions specified in the resource at request
body to set and/or remove properties defined on the resource
identified by Request-URI.
For a collection, INDEX MUST return a list of its members.
All
WebDAV DAV compliant resources MUST support the text/xml response
entity described below. The INDEX result for a collection MAY
also return a list of the members of child collections, to any
depth.
Collections that respond to an INDEX PROPPATCH method with a text/xml
entity and
MUST contain only one ResInfo element. This ResInfo
element contains an Href element, which gives the identifier(s)
of the resource, a Prop element, which gives selected properties
of process instructions that are specified using the resource,
propertyupdate, set, and a Members element, which contains a ResInfo
element for each member remove XML elements of the collection. The Prop element MUST
contain at least the following properties, if they are defined
and available: DisplayName, IsCollection, CreationDate,
GETentity, and INDEXentity.
The response from INDEX is cacheable, and SHOULD be accompanied
by an ETag header (see section 13.3.4 DAV schema.
Execution of RFC 2068). If GET and
INDEX return different entities for the same resource state, they
MUST return different entity tags.
3.4.4 The Response
200 (OK) - The server directives in this method is, of course, subject to
access control constraints. DAV compliant resources MUST send a machine readable response
entity which describes support
the membership setting of arbitrary dead properties.
The request message body of the resource.
3.4.5 ResInfo XML Element
Name: http://www.ietf.org/standards/dav/resinfo
Purpose: Describes a resource.
Schema: http://www.ietf.org/standards/dav/
Parent: Any
Value: Href Prop Members
Description: There PROPPATCH method MUST be contain at least
one Href propertyupdate XML element. Each Href
element contains a URI for the resource, which Instruction processing MUST be an
absolute URI. There occur
in the order instructions are received (i.e., from top to bottom),
and MUST be a single Prop element that contains a
series of properties defined on the resource. If the resource is
a collection, it MAY have at most one Members element, which
describes the members of the collection.
3.4.6 Members performed atomically.
8.2.1. propertyupdate XML Element element
Name: http://www.ietf.org/standards/dav/members propertyupdate
Namespace: http://www.ietf.org/standards/dav/
Purpose: Describes To contain a request to alter the membership of properties on a collection
resource.
Schema: http://www.ietf.org/standards/dav/
Parent: ResInfo
Value: ResInfo None
Values= 1*(set | remove)
Description: Contains zero or more ResInfo elements, which
describe members of the collection.
3.4.7 Href This XML Element
Name: http://www.ietf.org/standards/dav/href
Purpose: To identify that the content of the element is a URI.
Schema: http://www.ietf.org/standards/dav/
Parent: Any
Value: URI ; See section 3.2.1 of [Fielding et al., 1997]
3.4.8 Example
INDEX /user/yarong/dav_drafts/ HTTP/1.1
Host: www.microsoft.com
HTTP/1.1 200 OK
Content-Type: text/xml
Content-Length: xxx
Last-Modified: Thu, 11 Sep 1997 23:45:12 GMT
ETag: "fooyyybar"
<?XML:Namespace
href = "http://www.ietf.org/standards/dav/" as = "D"/>
<D:ResInfo>
<XML:Href>
http://www.microsoft.com/user/yarong/dav_drafts/
</XML:Href>
<Prop>
<DisplayName>
WebDAV working drafts directory
</DisplayName>
<IsCollection>true</IsCollection>
<CreationDate>19970418T070304Z</CreationDate>
<GETentity>
<Content-Type>text/html</Content-Type>
<Content-Length>2754</Content-Length>
<Content-Language>en</Content-Language>
<Last-Modified>
Fri, 22 Aug 1997 10:11:26 GMT
</Last-Modified>
<Etag>"8675309"</Etag>
</GETentity>
<INDEXentity>
<Content-Type>text/xml</Content-Type>
<Content-Length>xxx</Content-Length>
<Last-Modified>
Thu, 11 Sep 1997 23:45:12 GMT
</Last-Modified>
<Etag>"fooyyybar"</Etag>
</INDEXentity>
</Prop>
<Members>
<ResInfo>
<XML:Href>
http://www.microsoft.com/user/yarong/dav_drafts/base
</XML:Href>
<Prop>
<IsCollection
D:PropLoc="http://www.microsoft.com/user/yarong/dav_drafts/b
ase;props=IsCollection">
False
</IsCollection>
<DisplayName>
WebDAV Name Space Operations Draft
</DisplayName>
<Creation-Date>19970320T230525Z</Creation-Date>
<GETentity>
<Content-Type>application/msword</Content-Type>
<Content-Length>1400</Content-Length>
<Content-Language>en</Content-Language>
<Last-Modified>
Fri, 22 Aug 1997 18:22:56 GMT
</Last-Modified>
<Etag>"8675309"</Etag>
</GETentity>
</Prop>
</ResInfo>
</Members>
</D:ResInfo>
This example shows the result of the INDEX method applied to container for the
collection resource
http://www.microsoft.com/user/yarong/dav_drafts/. It returns a
response body in XML format, which gives information about
required to modify the
container and its sole member,
http://www.microsoft.com/user/yarong/dav_drafts/base. The entry properties on the collection confirms that resource. This XML element
is multi-valued.
8.2.2. set XML element
Name: set
Namespace: http://www.ietf.org/standards/dav/
Purpose: To set the resource DAV properties specified inside the INDEX was
executed on is set XML
element.
Parent: propertyupdate
Values= prop
Description: This XML element MUST contain only a collection. prop XML element.
The result also contains the URI of
the IsCollection property on elements contained by prop specify the member resource.
3.5 Behavior name and value of RFC 2068 Methods
properties that are set on Collections
With the introduction of the collection resource type to the HTTP
object model, it Request-URI. If a property already
exists then its value is necessary to define replaced.
8.2.3. remove XML element
Name: remove
Namespace: http://www.ietf.org/standards/dav/
Purpose: To remove the behavior of DAV properties specified inside the
existing methods (defined remove
XML element.
Parent: propertyupdate
Values= prop
Description: Remove specifies that the properties specified in RFC 2068) when invoked on a
collection resource to avoid ambiguity. While some methods, such
as OPTIONS and TRACE behave identically when applied to
collections, GET, HEAD, POST, PUT, and DELETE require some
additional explanation.
3.5.1 GET, HEAD for Collections
The semantics prop
should be removed. Specifying the removal of GET are unchanged when applied to a collection,
since GET property that does
not exist is defined as, "retrieve whatever information (in the
form of not an entity) is identified by error. All the Request-URI" [Fielding et
al., 1997]. GET when applied to a collection MAY return elements in prop MUST be empty,
as only the
contents names of an "index.html" resource, properties to be removed are required.
8.2.4. Response Codes
200 OK - The command succeeded. As there can be a human-readable view of
the contents mixture of the collection, or something else altogether, sets
and
hence it is possible the result of removes in a GET on body, a collection will
bear no correlation 201 Create seems inappropriate.
403 Forbidden - The client, for reasons the server chooses not to the state
specify, cannot alter one of the collection.
Similarly, since the definition of HEAD is a GET without properties.
405 Conflict - The client has provided a
response message body, the value whose semantics of HEAD are unmodified when
applied to collection resources.
3.5.2 POST
not appropriate 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 property. This includes trying to collections cannot
be meaningfully modified because it set read-
only properties.
413 Request Entity Too Long - If a particular property is largely undefined. Thus
the semantics of POST are unmodified when applied too long
to be recorded then a
collection.
3.5.3 PUT for Collections
As defined in composite XML error will be returned
indicating the offending property.
8.2.5. Example
PROPPATCH /bar.html HTTP/1.1 specification [Fielding et al., 1997],
Host: www.foo.com
Content-Type: text/xml
Content-Length: xxxx
<?XML version="1.0">
<?namespace href = "http://www.ietf.org/standards/dav/" AS = "D"?>
<?namespace href = "http://www.w3.com/standards/z39.50/" AS = "Z"?>
<D:propertyupdate>
<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>
HTTP/1.1 207 Multi-Status
Content-Type: text/xml
Content-Length: xxxxx
<?XML version="1.0">
<?namespace href="http://www.ietf.org/standards/dav/" AS = "D"?>
<?namespace href="http://www.w3.com/standards/z39.50/" AS = "Z"?>
<D:multistatus>
<D:response>
<D:prop><Z:Authors/></D:prop>
<D:status>HTTP/1.1 420 Method Failure</D:status>
</D:response>
<D:response>
<D:prop><Z:Copyright-Owner/></D:prop>
<D:status>HTTP/1.1 409 Conflict</D:status>
</D:response>
<D:responsedescription> Copyright Owner can not be deleted or
altered.</D:responsedescription>
</D:multistatus>
In this example, the "PUT method client requests that the enclosed entity be stored under server to set the supplied Request-URI." Since submission value of an entity
representing a collection would implicitly encode creation
the http://www.w3.com/standards/z39.50/Authors property, and
deletion of resources, this specification intentionally does to
remove the property http://www.w3.com/standards/z39.50/Copyright-
Owner. Since the Copyright-Owner property could not
define a transmission format be removed, no
property modifications occur. The Method Failure response code for creating a collection using PUT.
Instead,
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 defined used to create collections. If a
PUT is invoked on new collection. All DAV
compliant resources MUST support the MKCOL method.
8.3.1. Request
MKCOL creates a new collection resource it at the location specified by
the Request-URI. If the Request-URI exists, then MKCOL must fail.
During MKCOL processing, a server MUST make the Request-URI a member
of its parent collection. If no such ancestor exists, the method
MUST fail. When the PUT MKCOL operation creates a new non-collection resource collection
resource, all ancestors MUST already exist. 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 has 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 all ancestors do 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. Response Codes
Responses from a MKCOL request are not cacheable, since MKCOL has
non-idempotent semantics.
201 Created - The collection or structured resource was created in
its entirety.
403 Forbidden - This indicates at least one of two conditions: 1)
The server does not exist, allow the
method MUST fail with creation of collections at the given
location in its namespace, and 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 status code. For example,
if resource /a/b/c/d.html is to - A collection cannot be created and /a/b/c/ made at the Request-URI until
one or more intermediate collections have been created.
415 Unsupported Media Type- The server does not
exist, then support the request MUST fail.
3.5.3.1 PUT for Non-Collection Resources
A PUT performed
type of the body.
419 Insufficient Space on an existing Resource - The resource replaces does not have
sufficient space to record the GET response
entity state of the resource, but MUST NOT change resource after the value
execution of any dead
properties defined on the resource. Live properties defined on
the resource MAY be recomputed during PUT processing.
3.5.4 DELETE for Collections
When DELETE is applied to this method.
8.3.3. Example
This example creates a collection without internal members called /webdisc/xfiles/ on the collection resource, along with its properties, and external
members, MUST be deleted. A DELETE
server www.server.org.
MKCOL /webdisc/xfiles/ HTTP/1.1
Host: www.server.org
HTTP/1.1 201 Created
8.4. INDEX Method
The INDEX method applied is used to enumerate the members of a
collection resource containing internal member resource.
All DAV compliant resources MUST
fail with a 409 Conflict status code.
3.5.5 DELETE Method for Non-Collection Resources
If support the DELETE INDEX method is issued to a non-collection resource which
is an internal member of if they
have members.
8.4.1. The Request
For a collection, then during DELETE
processing a server MUST remove the Request-URI from its parent
collection. A server MAY remove the URI of INDEX MUST return a deleted resource
from any collections list of which its members. All
WebDAV compliant resources MUST support the resource is an external member.
3.6 COPY Method
3.6.1 Problem Description
Currently, in order to create text/xml response entity
described below. The INDEX result for a copy of collection MAY also return
a resource, list of the client
must GET an entity and then PUT members of child collections, to any depth.
Collections that entity respond to the desired
destination. This requires (1) an INDEX method with a text/xml entity to be transmitted to and
from
MUST contain a single multistatus XML element which contains a
response XML element for each member.
A resource that supports INDEX MUST return the server and (2) resourcetype property
for each member.
Note that the resource be expressible prop XML element MAY contain additional properties.
8.4.2. Example
INDEX /user/yarong/dav_drafts/ HTTP/1.1
Host: www.microsoft.com
HTTP/1.1 200 OK
Content-Type: text/xml
Content-Length: xxx
Last-Modified: Thu, 11 Sep 1997 23:45:12 GMT
ETag: _fooyyybar_
<?XML version="1.0">
<?namespace href = _http://www.ietf.org/standards/dav/_ as an
entity with complete fidelity.
This is problematic because of the network traffic involved in
making a copy, and because there = _D_?>
<D:multistatus>
<D:response>
<D:href>http://www.microsoft.com/user/yarong/dav_drafts/
</D:href>
<D:prop>
<D:resourcetype>
<D:collection/>
</D:resourcetype>
</D:prop>
<D:status>HTTP 1.1 200 OK</D:status>
</D:response>
<D:response>
<D:href>
http://www.microsoft.com/user/yarong/dav_drafts/base
</D:href>
<D:prop>
<D:resourcetype/>
</D:prop>
<D:status>HTTP 1.1 200 OK</D:status>
</D:response>
</D:multistatus>
8.5. ADDREF Method
The ADDREF method is often no way used to fully express
a resource as an entity without a loss of fidelity.
3.6.2 Solution Requirements
The solution:
- MUST allow a principal add external members to create a copy of a resource
without having to transmit resource.
All DAV compliant collection resources MUST support the resource to and from ADDREF
method. All other DAV compliant resources MAY support the server.
3.6.3 ADDREF
method as appropriate.
8.5.1. The Request
The COPY ADDREF method creates a duplicate of the source resource, given
by adds the Request-URI, URI specified in the destination resource, given Collection-Member
header as an external member to the collection specified by the
Destination header.
Request-URI. The Destination value in the Collection-Member header MUST be present. The
exact behavior of the COPY method depends on an
absolute URI meeting the type requirements of the
source resource.
3.6.3.1 COPY for HTTP/1.1 resources
When the source resource is not a collection, and an external member URI.
It is not a
property, an error if the body URI specified in the Collection-Member
header already exists as an external member of the destination resource collection.
However, after processing the ADDREF there MUST be octet-for-
octet identical to the body only one instance
of the source resource. Alterations
to URI in the destination resource do not modify collection. If the source resource.
Alterations to URI specified in the source resource do not modify
Collection-Member header already exists as an internal member of the destination
resource. Thus, all copies are performed "by-value".
All properties on
collection, the source resource ADDREF method MUST be duplicated on fail with a 412 Precondition
Failed status code.
8.5.2. Example
ADDREF /~ejw/dav/ HTTP/1.1
Host: www.ics.uci.edu
Collection-Member: http://www.ietf.org/standards/dav/
HTTP/1.1 200 OK
This example adds the
destination resource, subject to modifying headers, following URI http://www.ietf.org/standards/dav/ as an
external member resource of the
definition for copying properties.
3.6.3.2 COPY for Properties collection
http://www.ics.uci.edu/~ejw/dav/.
8.6. DELREF Method
The following section defines how properties on a resource are
handled during DELREF method is used to remove external members from a COPY operation.
Live properties SHOULD be duplicated as identically behaving live
properties at the destination
resource. Since All DAV compliant collection resources MUST support the
DELREF method. All other DAV compliant resources MUST support the
DELREF method only if they are live
properties, support the server determines ADDREF method.
8.6.1. The Request
The DELREF method removes the syntax and semantics (hence
value) of these properties. Properties named by URI specified in the Enforce-
Live-
Properties Collection-Member
header MUST be live on from the destination resource, or collection specified by the method MUST fail. If Request-URI.
DELREFing a property URI which is not named by Enforce-
Live-
Properties and cannot be copied live, then its value MUST be
duplicated, octet-for-octet, in an identically named, dead
resource on the destination resource.
If a property on the source already exists on the resource and member of the overwrite header collection is set to TRUE then the property at the
destination not an
error. DELREFing an internal member MUST be overwritten fail with a 412
Precondition Failed status code.
8.6.2. Example
DELREF /~ejw/dav/ HTTP/1.1
Host: www.ics.udi.edu
Collection-Member: http://www.ietf.org/standards/dav/
HTTP/1.1 200 OK
This example removes the property URI http://www.ietf.org/standards/dav/, an
external member resource, from the
source. If collection
http://www.ics.uci.edu/~ejw/dav/.
8.7. 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 overwrite header form
of an entity) is false and identified by the previous
situation exists then Request-URI_ [Fielding et al.,
1997]. GET when applied to a collection MAY return the COPY MUST fail with contents of
an _index.html_ resource, a 409 Conflict.
3.6.3.3 COPY for Collections
A COPY on human-readable view of the contents of
the collection, or something else altogether, and hence it is
possible the result of a collection causes GET on a new, empty collection resource will bear no
correlation to
be created at the destination with state of the same properties as 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.
8.8. POST for Collections
Since by definition the actual function performed by POST is
determined by the
source resource. All properties server and often depends on the source collection MUST be
duplicated on particular
resource, the destination collection, subject behavior of POST when applied to modifying
headers, following collections cannot be
meaningfully modified because it is largely undefined. Thus the definition
semantics of POST are unmodified when applied to a collection.
8.9. DELETE
8.9.1. DELETE Method for copying properties. The
new collection MUST NOT contain any members, internal or
external.
3.6.3.4 Type Interactions Non-Collection Resources
If the destination resource identifies DELETE method is issued to a property and the source non-collection resource which is not
an internal member of a property, collection, then during DELETE processing a
server MUST remove the copy SHOULD fail.
If Request-URI from its parent collection. A
server MAY remove the destination URI of a deleted resource identifies from any collections
of which the resource is an external member.
8.9.2. DELETE for Collections
The DELETE method on a collection and the
Overwrite MUST act as if a Depth = Infinity
header is "true," prior to performing the copy, the
server was used on it. A client MUST perform NOT submit a Depth header on a
DELETE operation on the collection.
3.6.4 The Response
200 (OK) The source resource was successfully copied to a pre-
existing destination resource.
201 (Created) The source resource was successfully copied. The
copy operation resulted collection with any value but Infinity.
DELETE instructs that the collection specified in the creation of a new resource.
412 (Precondition Failed) This status code MUST be returned if request-URI,
the server was unable records of its external member resources, and all its internal
member resources, are to maintain the liveness be deleted.
If any member cannot be deleted then all of the properties
listed in the Enforce-Live-Properties header, or if member's progeny
MUST NOT be deleted, so as to maintain the Overwrite namespace.
Any headers included with DELETE MUST be applied in processing every
resource to be deleted. In this case, a header of special interest
is false, and the state of Destroy header, which specifies the destination resource is
non-null.
417 (Insufficient Space on Resource) - The destination resource
does not have sufficient space method to record be used to
delete all resources in the state scope of the
resource after DELETE.
When the execution of this method.
500 (Server Error) The resource was in such a state that DELETE method has completed processing it could
not MUST return a
consistent namespace.
The response SHOULD be copied. This may occur if the Destination header specifies a resource Multi-Status response that is outside the namespace the resource is able to
interact with.
3.6.5 Examples
3.6.5.1 Overwrite Example
This example shows resource
http://www.ics.uci.edu/~fielding/index.html being copied to describes the
location http://www.ics.uci.edu/users/f/fielding/index.html. The
contents
result of the destination resource were overwritten, if non-
null.
COPY /~fielding/index.html DELETE on each affected resource.
8.9.2.1. Example
DELETE /container/ HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/users/f/fielding/index.html www.foo.bar
Destroy: NoUndelete
HTTP/1.1 207 Multi-Status
Content-Type: text/xml
Content-Length: xxxxx
<?XML version="1.0">
<?namespace href = "http://www.ietf.org/standards/dav/" As = "d"?>
<d:multistatus>
<d:response>
<d:href>http://www.foo.bar/container/resource1</d:href>
<d:href>http://www.foo.bar/container/resource2</d:href>
<d:status>HTTP/1.1 200 OK
3.6.5.2 No Overwrite Example
The following OK</d:status>
</d:response>
<d:response>
<d:href>http://www.foo.bar/container/</d:href>
<d:status>HTTP/1.1 420 Method Failure</d:status>
</d:response>
<d:response>
<d:href>http://www.foo.bar/container/resource3</d:href>
<d:status>HTTP/1.1 412 Precondition Failed</d:status>
</d:response>
</d:multistatus>
In this example shows the same copy operation being
performed, except with attempt to delete
http://www.foo.bar/container/resource3 failed because the Overwrite header set server was
unable to "false." A
response guarantee that resource3 would not be able to be
undeleted. Consequently, the attempt to delete
http://www.foo.bar/container/ also failed, but resource1 and
resource2 were deleted. Even though a Depth header has not been
included, a depth of 412, Precondition Failed, infinity is returned assumed because the
destination resource has method is on a non-null state.
COPY /~fielding/index.html HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/users/f/fielding/index.html
Overwrite: "false"
HTTP/1.1 412 Precondition Failed
3.7 MOVE Method
3.7.1 Problem Description
The move operation
collection. As this example illustrates, DELETE processing need not
be atomic.
8.10. PUT
8.10.1. PUT for Non-Collection Resources
A PUT performed on a an existing resource is replaces the logical equivalent GET response
entity of the resource. Properties defined on the resource MAY be
recomputed during PUT processing. For example, if a
copy followed by a delete, where server
recognizes the actions are performed
atomically. Using RFC 2068 methods only, this procedure content type of the request body, it may be able to
automatically extract information that could be
performed profitably exposed
as properties.
A PUT that would result in several steps. First, the client could issue a GET
to retrieve a representation creation of a resource, issue a DELETE to
remove the resource from the server, then use PUT to place the resource on the server without an
appropriately scoped parent collection MUST fail with a new URI. 405 Method
Not Allowed.
8.10.2. PUT for Collections
As is defined in the case for COPY -
because of HTTP/1.1 specification [Fielding et al., 1997],
the network traffic involved in making a move, and
because there is often no way to fully express a resource as "PUT method requests that the enclosed entity be stored under
the supplied Request-URI." Since submission of an entity without
representing a loss collection would implicitly encode creation and
deletion of fidelity - server move functionality is
preferable.
With a WEBDAV server, a principal may accomplish resources, this task by
issuing specification intentionally does not
define a COPY and then DELETE. Network load decreases, but the
server load may still be significant because transmission format for creating a collection using PUT.
Instead, the server must MKCOL method is defined to create collections. If a duplicate resource. Were
PUT is invoked on a server to know beforehand
that collection resource it MUST fail.
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 principal intended 409 Conflict status code. For example, if
resource /a/b/c/d.html is to perform COPY be created and DELETE operations
in succession, it could avoid /a/b/c/ does not exist,
then the creation of request must fail.
8.11. COPY Method
The COPY method creates a duplicate
resource.
3.7.2 Solution Requirements
The solution:
- Must prevent the unneeded transfer of entity bodies from and
to the server.
- Must prevent specified resource. All
DAV compliant resources MUST support the unneeded creation of copies by COPY method.
Support for the server.
3.7.3 The Request
The move operation on a resource is COPY method does not guarantee the logical equivalent of a ability to copy followed by a delete, where
resource. For example, separate programs may control resources on
the actions are performed
atomically. If same server. As a resource exists at the destination, the
destination resource will result, it may not even be DELETEd as possible to copy a side effect of the MOVE
operation, subject
resource to a location that appears to be on the restrictions of the overwrite header.
3.7.4 same server.
8.11.1. The Response
200 (OK) - Request
The resource was moved. A successful response must
contain COPY method creates a duplicate of the Content-Location header, set equal to source resource, given by
the URI Request-URI, in
source. This lets caches properly flush any cached entries for the source. Unfortunately destination resource, given by the Content-Location
Destination header. The Destination header only allows
a single value so it is not possible for caches unfamiliar with
the MOVE method to properly clear their caches.
412 (Precondition Failed) This status code MUST be returned if present. The
exact behavior of the server was unable to maintain COPY method depends on the liveness type of the properties
listed in the Enforce-Live-Properties header, or if source
resource.
8.11.1.1. COPY for HTTP/1.1 resources
When the Overwrite
header source resource is false, and not a collection the state body of the
destination resource is
non-null.
501 (Not Implemented) - This may occur if MUST be octet-for-octet identical to the Destination header
specifies a resource which is outside its domain body
of control
(e.g., stored on another server) resource and the server either
refuses or is incapable of moving to an external source resource.
502 (Bad Gateway) - This may occur when moving Alterations to external
resources and the destination server refused to accept resource do
not modify the source resource.
3.7.5 Examples
3.7.5.1 Overwrite Example
This example shows resource
http://www.ics.uci.edu/~fielding/index.html being moved Alterations to the
location http://www.ics.uci.edu/users/f/fielding/index.html. The
contents of source resource
do not modify the destination resource. Thus, all copies are
performed _by-value_.
All properties on the source resource were overwritten, if non-
null.
MOVE /~fielding/index.html HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/users/f/fielding/index.html
HTTP/1.1 200 OK
Content-Location:
http://www.ics.uci.edu/users/f/fielding/index.html
3.8 ADDREF Method
3.8.1 Problem Definition
There needs to MUST be a way to add an external member duplicated on the
destination resource, subject to a
collection.
3.8.2 Solution Requirements modifying headers, following the
definition for copying properties.
8.11.1.2. COPY for Properties
The solution must:
- allow access control
- allow referencing to URIs of external members
- not require following section defines how properties on a body
3.8.3 The Request
The ADDREF method adds resource are
handled during a COPY operation.
Live properties SHOULD be duplicated as identically behaving live
properties at the URI specified in destination resource. Since they are live
properties, the Collection-Member
header as an external member to server determines the collection specified syntax and semantics of these
properties. Properties named by the
Request-URI. The value in the Collection-Member Enforce-Live-Properties header
MUST be an
absolute URI meeting live on the requirements of an external member URI.
It destination resource, or the method MUST fail.
If a property is not named by Enforce-Live-Properties and cannot be
copied live, then its value MUST be duplicated, octet-for-octet, in
an error if identically named, dead property on the URI specified in destination resource.
If a property on the Collection-Member
header source already exists as an external member of on the collection,
however, after processing ADDREF there destination
resource and the Overwrite header is set to "T" then the property at
the destination MUST be only one instance
of overwritten with the URI in property from the collection.
source. If the URI specified in the
Collection-Member Overwrite header already exists as an internal member of is "F" and the collection, previous situation
exists, then the ADDREF method COPY MUST fail with a 412
Precondition Failed status code.
3.8.4 Example
ADDREF /~whitehead/dav/ HTTP/1.1
HOST: www.ics.udi.edu
Collection-Member: http://www.ietf.org/standards/dav/
HTTP/1.1 200 OK
3.9 DELREF Method
3.9.1 Problem Definition
There needs to be 409 Conflict.
8.11.1.3. COPY for Collections
The COPY method on a way to remove an external member from collection without a
collection.
3.9.2 Solution Requirements
The solution must:
- allow access control
- allow referencing to URIs of external members
- not require Depth header MUST act as
if a body
3.9.3 The Request
The DELREF method removes the URI specified in the Collection-
Member Depth = infinity header from the collection specified by the Request-URI.
DELREFing was included. A client MAY submit a URI which is not
Depth header on a member COPY on a collection with a value of "0" or
"infinity". DAV compliant servers MUST support the "0" and
"infinity" behaviors.
A COPY of depth infinity instructs that the collection is not an
error. DELREFing an specified in
the Request-URI, the records of its external member resources, and
all its internal member MUST fail with a 412
Precondition Failed status code.
3.9.4 Example
DELREF /~whitehead/dav/ HTTP/1.1
Host: www.ics.udi.edu
Collection-Member: http://www.ietf.org/standards/dav/
HTTP/1.1 200 OK
3.10 PATCH Method
3.10.1 Problem Definition
At present, if a principal wishes resources, are to be copied to modify a resource, they must
issue a GET against location
relative to the resource, modify their local copy Destination header.
A COPY of depth "0" only instructs that the
resource, collection, the
properties, and then issue its external members, not its internal members, are
to be copied.
Any headers included with a PUT COPY are to place the modified be applied in processing
every resource on to be copied.
The exception to this rule is the server. Destination header. This procedure is inefficient because header
only specifies the entire
entity destination for a resource must be transmitted to and from the server
in order to make even small changes. Ideally, the update entity
transmitted Request-URI. When applied to
members of the server should be proportional collection specified in size to the
modifications.
3.10.2 Solution Requirements
The solution must:
- allow partial modification request-URI the value of a resource without having
Destination is to
transmit the entire modified resource
- allow byte-range patching
- allows extensions so that patches can be done beyond simple
byte-range patching
- allow ranges modified to be deleted, inserted, and replaced
3.10.3 The Request
The request entity of reflect the PATCH method contains a list of
differences between current location in the resource identified by
hierarchy. So, if the Request-URI request-URI is "a" and the desired content destination is "b"
then when a/c/d is processed it MUST use a destination of b/c/d.
When the resource after the PATCH action COPY method has been applied. The list of differences is in completed processing it MUST have created a format defined
by
consistent namespace at the media type of destination. Thus if it is not possible
to COPY a collection with internal members, the entity (e.g., "application/diff") and
must include sufficient information internal members may
still be copied but a collection will have to allow be created at the server
destination to
convert contain them.
The response is a Multi-Status response that describes the original version result of
the COPY on each affected resource. The response is given for the
resource that was to the desired
version. Processing performed by PATCH is atomic, hence all
changes MUST be successfully executed or the method fails. PATCH
MUST fail if executed on a non-existent resource; i.e. PATCH does copied, not create a the resource that was created as
a side effect.
If result of the request appears (at least initially) to be acceptable, copy. In other words, each entry indicates whether
the
server MUST transmit an interim 100 response message after
receiving copy on the empty line terminating resource specified in the request headers href succeeded or failed
and
continue processing the request. Since the semantics of PATCH
are non-idempotent, responses why.
The exception to this method are not cacheable.
While server support for PATCH rule is optional, for errors that occurred on the
destination. For example, if a server does
support PATCH, it MUST support at least the text/xml diff format
defined below. Support for destination was locked the VTML difference format [VTML] is
recommended, but not required.
3.10.4 text/xml elements for PATCH
The resourceupdate XML element contains
response would indicate the destination URL and a set of XML sub-entities
that describe modification operations. The name 421 Destination
Locked error.
8.11.1.4. Type Interactions
If the destination resource identifies a collection and meaning of
these XML elements the
Overwrite header is given below. Processing of these directives
MUST be performed in _T_, prior to performing the order encountered within copy the XML
document. A directive operates server
MUST perform a DELETE operation on the resource as modified by
all previous directives (executed in sequential order). The
length of the resource MAY be extended or reduced by a PATCH. collection.
8.11.2. Response Codes
200 OK - The changes specified by the resourceupdate XML element MUST be
executed atomically.
3.10.4.1 ResourceUpdate
Name: http://www.ietf.org/standards/dav/patch/resourceupdate
Purpose: Contains an ordered set of changes source resource was successfully copied to a non-
collection, non-property pre-
existing destination resource.
Schema: http://www.ietf.org/standards/dav/patch/
Parent: Any
Value: *(Insert | Delete | Replace)
3.10.4.2 Insert
Name: http://www.ietf.org/standards/dav/patch/insert
Purpose: Insert the XML element’s contents starting at the
specified octet.
Schema: http://www.ietf.org/standards/dav/patch/
Parent: ResourceUpdate
Value:
201 Created - The insert XML element MUST contain an Octet-Range
XML element that specifies an octet position within source resource was successfully copied. The copy
operation resulted in the body creation of a new resource. A value of "end" specifies
412 Precondition Failed - This status code MUST be returned if the end of
server was unable to maintain the resource.
The body liveness of the insert XML element contains the octets to be
inserted.
Please note that properties listed
in order to protect the white Enforce-Live-Properties header, or if the Overwrite header is
"F", and the state of the destination resource is non-null.
419 Insufficient Space on Resource - The destination resource does
not have sufficient space contained in
this XML element to record the following attribute/value MUST be included
in state of the element: XML-SPACE = "PRESERVE".
3.10.4.3 Delete
Name: http://www.ietf.org/standards/dav/patch/delete
Purpose: Removes resource after
the specified range execution of octets.
Schema: http://www.ietf.org/standards/dav/patch/
Parent: ResourceUpdate
Value: The Delete XML element MUST contain an octet-range
XML element.
Discussion: this method.
421 Destination Locked _ The octets that are deleted are removed, which means
the destination resource is collapsed was locked and
either a valid Lock-Token header was not submitted, or the length of Lock-
Token header identifies a lock held by another principal.
500 Server Error - The resource was in such a state that it could
not be copied. This may occur if the Destination header specifies a
resource that is
decremented by outside the size of namespace the octet range. It resource is not
appropriate able to
interact with.
8.11.3. Overwrite Example
This example shows resource
http://www.ics.uci.edu/~fielding/index.html being copied to replace deleted octets with zeroed-out octets,
since zero is a valid octet value.
3.10.4.4 Replace
Name: http://www.ietf.org/standards/dav/patch/replace
Purpose: Replaces the specified range of octets with the
location http://www.ics.uci.edu/users/f/fielding/index.html. The
contents of the XML element. If the number of octets in the XML
element is different from the number of octets specified, the
update MUST be rejected.
Schema: http://www.ietf.org/standards/dav/patch/
Parent: ResourceUpdate
Value: The Replace XML element MUST contain an octet-
range XML element. destination resource were overwritten, if non-null.
COPY /~fielding/index.html HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/users/f/fielding/index.html
HTTP/1.1 200 OK
8.11.4. No Overwrite Example
The contents of following example shows the entity are same copy operation being performed,
except with the replacement
octets.
Please note that in order Overwrite header set to protect the white space contained in
this XML element the following attribute/value MUST be included
in the element: XML-SPACE = "PRESERVE".
3.10.4.5 Octet-Range Attribute
Name: http://www.ietf.org/standards/dav/patch/octet-
range
Purpose: Specifies a range _F._ A response of octets that the enclosing property
effects.
Schema: http://www.ietf.org/standards/dav/patch/
Parent: Insert, Delete, Replace
Value: number ["-" (number | "end")]
Number = 1*Digit
Description: Octet numbering begins with 0. If 412
Precondition Failed is returned because the octet contains destination resource has
a single number then the operation non-null state.
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_
HTTP/1.1 412 Precondition Failed
8.11.5. Collection Example
COPY /container/ HTTP/1.1
Host: www.foo.bar
Destination: http://www.foo.bar/othercontainer/
Enforce-Live-Properties: *
Depth: Infinity
HTTP/1.1 207 Multi-Status
Content-Type: text/xml
Content-Length: xxxxx
<?XML version="1.0">
<?namespace href = "http://www.ietf.org/standards/dav/" As = "d"?>
<d:multistatus>
<d:response>
<d:href>http://www.foo.bar/othercontainer/resource1</d:href>
<d:href>http://www.foo.bar/othercontainer/resource2</d:href>
<d:href>http://www.foo.bar/othercontainer/</d:href>
<d:href>http://www.foo.bar/othercontainer/R2/D2</d:href>
<d:status>HTTP/1.1 201 Created</d:status>
</d:response>
<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 to begin at that octet and
to continue for a length specified by the operation. In unnecessary as the case default behavior of COPY on a delete, this would mean
collection is to delete act as if a single octet. "Depth: Infinity" header had been
submitted. In the
case of an insert this would mean to begin the insertion at the
specified octet and to continue for the length example most of the included
value, extending the resource if necessary. In the case of
replace, resources, along with the replace begins at
collection, were copied successfully. However the specified octet and overwrites
all that follow collection R2
failed, most likely due to the length of the included value.
3.10.5 The Response
200 (OK) - The request entity body a problem with enforcing live properties.
R2's member D2 was processed without error,
resulting in an update successfully copied. As a result a collection
was created at www.foo.bar/othercontainer/R2 to contain D2.
8.12. MOVE Method
The move operation on a resource is the state logical equivalent of a copy
followed by a delete, where the resource.
409 (Conflict) - If actions are performed atomically.
All DAV compliant resources MUST support the update information in MOVE method.
However, support for the request message
body MOVE method does not make sense given guarantee the current state 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 even be possible to move
a resource
(e.g., an instruction within a namespace that appears to delete belong to the same
server.
8.12.1. The Request
If a non-existent line), this status
code MAY resource exists at the destination, the destination resource
will be returned.
415 (Unsupported Media Type) - The server does not support DELETEd as a side effect of the
content type MOVE operation, subject to
the restrictions of the update instructions Overwrite header.
8.12.2. MOVE for Collections
MOVE instructs that the collection specified in the request message
body.
416 (Unprocessable Entity) - A new status code. The server
understands Request-URI, the content type
records of the request entity, but was
unable its external member resources, and all its internal
member resources, are to be moved to a location relative to process the contained instructions.
417 (Insufficient Space on Resource) -
Destination header.
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 are to be applied in processing every
resource does not have
sufficient space to record be moved.
The exception to this rule is the state Destination header. The behavior
of this header is the resource after same as given for COPY on collections.
When the
execution of this method.
3.10.6 Examples
3.10.6.1 HTML file modification
The following example shows MOVE method has completed processing it MUST have created a modification of
consistent namespace on both the title source and
contents of destination, creating
collections at the HTML resource http://www.example.org/hello.html.
Before:
<HTML>
<HEAD>
<TITLE>Hello world HTML page</TITLE>
</HEAD>
<BODY>
<P>Hello, world!</P>
</BODY>
</HTML>
PATCH Request: Response:
PATCH hello.html HTTP/1.1
Host: www.example.org
Content-Type: text/xml
Content-Length: xxx
HTTP/1.1 100 Continue
<?XML:Namespace href =
Shttp://www.ietf.org/standards/dav/patch/" AS = "D"/>
<D:ResourceUpdate>
<Replace XML-SPACE = "PRESERVE"><octet-range>14</octet-
range>&003CTITLE&003ENew Title&003C/TITLE&003E</Replace>
<Delete><octet-range>38-50</Delete>
<Insert XML-SPACE = "PRESERVE"><octet-range>86</>&
003CP&003ENew paragraph&003C/P&003E</Insert>
</D:ResourceUpdate>
HTTP/1.1 200 OK
After:
<HTML>
<HEAD>
<TITLE>New Title</TITLE>
</HEAD>
<BODY>
<P>Hello, world!</P>
<P>New paragraph</P>
</BODY>
</HTML>
3.11 Headers
3.11.1 Destination Header
The Destination header specifies a source or destination resource for
methods such as COPY and necessary.
As specified in the definition of MOVE, which take two URIs as parameters.
Destination= "Destination" ":" URI
3.11.2 Enforce-Live-Properties Header a MOVE of a collection over
another collection causes the destination collection and all its
members to be deleted.
The Enforce-Live-Properties header specifies properties response is a Multi-Status response that MUST
be "live" after they are copied (moved) to describes the destination
resource result of a copy (or move). If
the value "*" MOVE on each effected resource. The response is given for the
header, then it designates all live properties on
resource that was to be moved, not the source
resource. If resource that was created as
a result of the value is "Omit" then move. In other words, each entry indicates whether
the server MUST NOT
duplicate move on the destination resource any properties specified in the href succeeded or failed
and why.
The exception to this rule is for errors that are
defined occurred on the source resource. If
destination. For example, if the destination was locked the
response would indicate the destination URL and a 421 Destination
Locked error.
8.12.3. Response Codes
200 OK - The move operation was successful.
409 Conflict _ The MOVE was attempted on a collection with members.
While the COPY part of this header is not included
then operation could succeed the DELETE could
not. Therefore the MOVE MUST fail.
412 Precondition Failed - This status code MUST be returned if the
server is expected was unable to act as defined by maintain the default
property handling behavior liveness of the associated method.
EnforceLiveProperties = "Enforce-Live-Properties" ":" ("*" |
"Omit" | 1#(Property-Name))
Property-Name = "<" URI ">"
3.11.3 properties listed
in the Enforce-Live-Properties header, or if the Overwrite Header header is
"F", and the state of the destination resource is non-null.
421 Destination Locked - The Overwrite destination resource was locked and
either a valid Lock-Token header specifies whether was not submitted, or the Lock-
Token header identifies a lock held by another principal.
502 Bad Gateway - This may occur when the destination is
o
n another
server should
overwrite and the state of a non-null destination resource during a
COPY or MOVE. A value of "false" states that the server MUST NOT
perform refuses to accept the COPY or MOVE operation if resource
8.12.4. Overwrite Example
This example shows resource
http://www.ics.uci.edu/~fielding/index.html being moved to the state
location http://www.ics.uci.edu/users/f/fielding/index.html. The
contents of the destination resource is were overwritten, if non-null. By default,
MOVE /~fielding/index.html HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/users/f/fielding/index.html
HTTP/1.1 200 OK
8.12.5. Collection Example
MOVE /container/ HTTP/1.1
Host: www.foo.bar
Destination: http://www.foo.bar/othercontainer/
Enforce-Live-Properties: *
Overwrite: False
Lock-Token: <OpaqueLockToken:xxxx> <OpaqueLockToken:xxxx>
HTTP/1.1 207 Multi-Status
Content-Type: text/xml
Content-Length: xxxxx
<?XML version="1.0">
<?namespace href = "http://www.ietf.org/standards/dav/" As = "D"?>
<d:multistatus>
<d:response>
<d:href>http://www.foo.bar/container/resource1</d:href>
<d:href>http://www.foo.bar/container/resource2</d:href>
<d:href>http://www.foo.bar/container/</d:href>
<d:href>http://www.foo.bar/container/C2/R2</d:href>
<d:status>HTTP/1.1 201 Created</d:status>
</d:response>
<d:response>
<d:href>http://www.foo.bar/container/C2</d:href>
<d:status>HTTP/1.1 420 Method Failure</d:status>
<d:response>
<d:href>http://www.foo.bar/othercontainer/C2</d:href>
<d:status>HTTP/1.1 409 Conflict</d:status>
</d:response>
</d:multistatus>
In this example the value of
Overwrite is "true," and a client MAY omit this header from has submitted a
request when its value is "true." While number of lock tokens
with the Overwrite header
appears request. A lock token will need to duplicate be submitted for every
resource, both source and destination, anywhere in the functionality scope of the If-Match: * header
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 continer/c2 could not be moved,
although its child container/C2/R2 could be moved.
8.13. LOCK Method
The following sections describe the LOCK method, which is used to
take out a lock of HTTP/1.1, If-Match applies any access type. These sections on the LOCK
method describe only those semantics that are specific to the Request-URI, LOCK
method and not to are independent of the Destination access type of a COPY or MOVE.
Overwrite = "Overwrite" ":" ("true" | "false")
If there is a conflict the lock being
requested. Once the general LOCK method has been described,
subsequent sections describe the semantics of the "write" access
type, and the Overwrite write lock.
8.13.1. Operation
A LOCK method invocation creates the lock specified by the Lock-Info
header equals "true", or
is absent and thus defaults to "true", then on the Request-URI. Lock method MUST fail
with requests SHOULD have a 409 Conflict.
3.11.4 Destroy Header
When deleting XML
request body which contains an Owner XML element for this lock
request. The LOCK request MAY have a resource the client often wishes Timeout header.
A successful response to specify
exactly what sort a lock invocation MUST include Lock-Token
and Timeout headers. Clients MUST assume that locks may arbitrarily
disappear at any time, regardless of delete is being enacted. The Destroy header,
used with the Mandatory header, allows the client to specify value given in the
end result they desire. Timeout
header. The Destroy Timeout header is specified as
follows:
The Undelete token requests that, only indicates the behavior of the
server if possible, "extraordinary" circumstances do not occur. For example,
an administrator may remove a lock at any time or the resource
should be left system may
crash in a state such a way that it can be undeleted. The
server is not required to honor this request.
The NoUndelete token requests that loses the resource record of the lock's
existence. The response MUST NOT be left also contain the value of the
lockdiscovery property in a state such that it can be undeleted. prop XML element.
8.13.2. The VersionDestroy token includes Effect of Locks on Properties and Collections
By default the functionality scope of a lock is the
NoUndelete token entire state of the resource,
including its body and extends it to include having associated properties. As a result, a lock
on a resource also locks the resource's properties, and a lock on a
property may lock a property's resource or may restrict the server
remove all versioning references ability
to lock the resource that it has
control over.
DestroyHeader = "Destroy" ":" #Choices
Choices = "VersionDestroy" | "NoUndelete" | "Undelete" | token
|"<" URI ">" ; property's resource. Only a single lock token extension MUST NOT be
used unless it is
specified in a RFC16, otherwise when a URI MUST be used for
extensions.
3.11.5 Collection-Member Header
The Collection-Member header specifies the URI of an external
resource lock extends to be added/deleted to/from cover both a collection.
CollectionMember = "Collection-Member" ":" URI
3.12 Links
3.12.1 Source Link Property Type
Name: http://www.ietf.org/standards/dav/link/source
Purpose: The destination of the source link identifies the resource and its
properties. Note that contains the unprocessed source of certain lock types MAY override this
behavior.
For collections, a lock also affects the link’s
source.
Schema: http://www.ietf.org/standards/dav/link/
Parent: Any
Value: An XML document with zero ability to add or more link XML
elements.
Discussion: remove
members. The source nature of the link (src) is typically effect depends upon the URI type of access
control involved.
8.13.3. Locking Replicated Resources
Some servers automatically replicate resources across multiple URLs.
In such a circumstance the output resource on which the link is defined, and there is
typically server MAY only accept a lock on one destination (dst) of
the link, which is the
URI where URLs if the unprocessed source of server can guarantee that the resource may be accessed.
When more than one link destination exists, this specification
asserts no policy on ordering.
4 State Tokens
4.1 Overview
4.1.1 Problem Description
There are times when a principal lock will want to predicate
successful execution of a method on be honored
across all the current state of a
resource. While HTTP/1.1 provides a mechanism URLs.
8.13.4. Locking Multiple Resources
The LOCK method supports locking multiple resources simultaneously
by allowing for conditional
execution the listing of methods using entity tags via several URIs in the "If-Match" and
"If-None-Match" headers, LOCK request.
These URIs, in addition to the mechanism is not sufficiently
extensibleto express conditional statements involving more
generic state indicators, such Request-URI, are then to be locked as lock tokens.
a result of the LOCK method's invocation. When multiple resources
are specified the LOCK method only succeeds if all specified
resources are successfully locked.
The fundamental issue with entity tags is Lock-Tree option of the lock request specifies that they can only the resource
and all its internal children (including internal collections, and
their internal members) are to be
generated locked. This is another mechanism
by which a resource. However there are times when request for a client
will want to lock on multiple resources can be able
specified.
Currently existing locks can not be extended to share state tokens between cover more or less
resources,
potentially on different servers, as well as be able and any request to generate
certain types expand or contract the number of
resources in a lock tokens without first having to communicate MUST fail with a server.
For example, a principal may wish to require that resource B have
a certain state in order 409 Conflict status code. So,
for a method to successfully execute on example, if resource A. If A is exclusively write locked and then the client submits an e-tag from resource B
same principal asks to
resource exclusively write lock resources A, then B, and C,
the request will fail as A has no way of knowing is already locked and the lock can not be
extended.
A successful result will return a single lock token which represents
all the resources that have been locked. If an UNLOCK is executed
on this token, all associated resources are unlocked.
If the e-tag is meant lock cannot be granted to describe resource B.
Another example occurs when all resources, a principal wishes to predicate the
successful completion of 409 Conflict
status code MUST be returned with a method on response entity body containing
a multistatus XML element describing which resource(s) prevented the absence
lock from being granted.
8.13.5. Interaction with other Methods
The interaction of any locks on a resource. It LOCK with various methods is not sufficient to submit an "If-None-Match: *"
as this refers to dependent upon the existence of an entity, not
lock type. However, independent of lock type, a lock.
This draft defines the term "state token" as an identifier for a
state successful DELETE
of a resource. resource MUST cause all of its locks to be removed.
8.13.6. Lock Compatibility Table
The sections table below define requirements for
state tokens and provide a state token syntax, along with two
new headers which can accept describes the new state token syntax.
4.1.2 Solution Requirements
4.1.2.1 Syntax
Self-Describing. A state token must be self describing such behavior that
upon inspecting occurs when a state token it lock
request is possible to determine what
sort of state token it is, what resource(s) it applies to, and
what state it represents.
This self-describing nature allows servers to accept tokens from
other servers and potentially 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 able to coordinate state
information cross resource and cross site through standardized
protocols. For example, granted. False = lock MUST NOT be
granted. *=if the execution principal requesting the lock is the owner of a request on resource A
can the
lock, the lock MAY be predicated on the regranted.
The current lock state of a resource B, where A is given in the leftmost
column, and B lock requests are
potentially on different servers.
Client Generable. The state token syntax must allow, when
appropriate, for clients to generate a state token without having listed in the first communicated with a server.
One drawback row. The
intersection of entity tags is that they are set by the server,
and there is no interoperable algorithm for calculating an entity
tag. Consequently, a client cannot generate an entity tag from a
particular state row and column gives the result of a resource. However, a state token which
encodes an MD5 state hash could be calculated by lock request.
For example, if a client based shared lock is held on a client-held state of a resource, and then submitted to a
server in a conditional method invocation.
Another potential use for client generable state tokens an
exclusive lock is for a
client to generate requested, the table entry is _false_, indicating
the lock tokens with wild card fields, and hence
be able to express conditionals such as: "only execute this GET
if there are no write locks on this resource."
4.1.2.2 Conditonals
Universal. A solution must not be applicable to all requests.
Positive and Negative. Conditional expressions must allow for granted.
If an exclusive or shared lock is re-requested by the
expression of both positive and negative state requirements.
4.2 State Token Syntax
State tokens are URLs employing principal who
owns the lock, the lock MUST be regranted. If the lock is
regranted, the same lock token that was previously issued MUST be
returned.
8.13.7. Owner XML Element
Name: owner
Namespace: http://www.ietf.org/standards/dav/
Purpose: Provide information about the principal taking out a
lock.
Parent: Any
Values: XML Elements
Descripton: 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 following syntax:
State-Token = "StateToken:" Type ":" Resources ":" State-Info
Type = "Type" "=" Caret-encoded-URL
Resources = "Res" "=" Caret-encoded-URL
Caret-encoded-URL = "^" Resource "^"
Resource = <A URI where all "^" characters are escaped>
State-Info = *(uchar | reserved) ; uchar, reserved defined
section 3.2.1 principal (such as the
URL of RFC 2068
This proposal has created a new URL scheme for state tokens
because homepage) who owns a state token names lock.
8.13.8. Lock Response
A successful lock response MUST contain a network resource using its normal
name, which is typically state-invariant, along with additional
information that specifies Lock-Token response
header, a particular state of the resource.
Encoding Timeout header and a prop XML element in the state information into response body
which contains the native URL scheme value of the
network lockdiscovery property.
8.13.9. Response Codes
409 Conflict - The resource is locked, so the method has been
rejected.
412 Precondition Failed - The included Lock-Token was not felt to be safe, since freedom from name
space collisions
enforceable on this resource or the server could not be guaranteed. If this proposal is
accepted, satisfy the StateToken URL scheme will need to be defined and
registered with IANA.
State Token URLs begin with
request in the URL scheme name "StateToken"
rather than Lock-Info header.
8.13.10. Example - Simple Lock Request
LOCK /workspace/webdav/proposal.doc HTTP/1.1
Host: webdav.sb.aol.com
Lock-Info: LockType=Write LockScope=Exclusive
Timeout: Infinite; Second-4100000000
Content-Type: text/xml
Content-Length: xyz
<?XML version="1.0">
<?namespace href="http://www.ietf.org/standards/dav/" AS = "D"?>
<D:owner>
<D:href>http://www.ics.uci.edu/~ejw/contact.html</D:href>
</D:owner>
HTTP/1.1 200 OK
Lock-Token: opaquelocktoken:xyz122393481230912asdfa09s8df09s7df
Timeout: Second-604800
Content-Type: text/xml
Content-Length: xxxxx
<?XML version="1.0">
<?namespace href ="http://www.ietf.org/standards/dav/" AS = "D"?>
<D:prop>
<D:lockdiscovery>
<D:activelock>
<D:locktype>write</D:locktype>
<D:lockscope>exclusive</D:lockscope>
<D:addlocks/>
<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:xyz122393481230912asdfa09s8df09s7df
</D:href>
</D:locktoken>
</D:activelock>
</D:lockdiscovery>
</D:prop>
This example shows the name 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 particular state 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). The
response has a Lock-Token header that gives the lock token type they
represent in order to make the URL self describing. Thus it is
possible to examine that
uniquely identifies the URL and know, at lock created by this lock request.
8.13.11. Example - Multi-Resource Lock Request
LOCK /workspace/webdav/proposal.doc HTTP/1.1
Host: webdav.sb.aol.com
Lock-Info: LockType=Write LockScope=Exclusive
Addlocks=<http://webdav.sb.aol.com/workspace/><http://foo.bar/blah>
Timeout: Infinite, Second-4100000000
<?XML version="1.0">
<?namespace href="http://www.ietf.org/standards/dav/" AS = "D"?>
<D:href>http://www.ics.uci.edu/~ejw/contact.html<D:href>
HTTP/1.1 409 Conflict
Content-Type: text/xml
Content-Length: xxxxx
<?XML version="1.0">
<?namespace href = "http://www.ietf.org/standards/dav/" As = "D"?>
<D:multistatus>
<D:response>
<D:href>
http://webdav.sb.aol.com/workspace/webdav/proposal.doc
</D:href>
<D:href>
http://webdav.sb.aol.com/workspace/webdav/
</D:href>
<D:status>HTTP/1.1 202 Accepted</D:status>
</D:response>
<D:response>
<D:href>http://foo.bar/blah</D:href>
<D:status>HTTP/1.1 403 Forbidden</D:status>
</D:response>
</D:multistatus>
This example shows a minimum, request for an exclusive write lock on three
resources, http://webdav.sb.aol.com/workspace/webdav/proposal.doc,
http://webdav.sb.aol.com/workspace/, and http://foo.bar/blah. In
this request, the client has specified that it is desires an infinite
length lock, if available, otherwise a
state token.
Labeled name/value pairs are used within the token to allow new
fields to be added. Processors timeout of state tokens MUST be prepared
to accept the fields in whatever order they are present and MUST
ignore any fields they do not understand. 4.1 billion
seconds, if available. The "Type" Owner header field specifies the type of the state web
address for contact information
encoded in the state token. A URL is used in order to avoid
namespace collisions.
The "Res" field identifies the resource for which the state token
specifies a particular state. Since commas and spaces are
acceptable URL characters, a caret is used to delimit a URL.
Since a caret is an acceptable URL character, any instances of it
must be escaped using principal taking out the % escape convention.
The State-Info production is expanded upon in descriptions of
specific state token types, and is intended to contain
lock.
This lock request has failed, because the state
description information server rejected the lock
request for a particular state token.
4.3 State Token Conditional Headers
4.3.1 If-State-Match
If-State-Match = "If-State-Match" ":" ("AND" | "OR") 1#("<"
State-Token ">")
The If-State-Match header is intended to have similar
functionality http://foo.bar/blah. The 409 Conflict status code
indicates that the server was unable to satisfy the If-Match header defined in section 14.25 request because
there is a conflict between the state of
RFC 2068.
If the AND keyword is used resources and all of the state tokens identify
operation named in the state of request. Within the resource, then multistatus, the server MAY perform 202
Accepted status code indicates that the
requested method. If lock method was accepted by
the OR keyword is used resources, and any of the state
tokens identifies would have been completed if all resources named
in the current state of request were able to be locked. The 403 Forbidden status
code indicates that the resource, then server
MAY perform does not allow lock requests on this
resource.
8.14. UNLOCK Method
The UNLOCK method removes the requested method. If neither of lock identified by the keyword
requirements is met, lock token in
the server MUST NOT perform Lock-Token header from the requested
method, Request-URI, and all other resources
included in the lock.
Any DAV compliant resource which supports the LOCK method MUST return a 412 (Precondition Failed) response.
4.3.2 If-None-State-Match
If-None-State-Match = "If-None-State-Match" ":" 1#("<" State-
Token ">")
support the UNLOCK method.
8.14.1. Example
UNLOCK /workspace/webdav/info.doc HTTP/1.1
Host: webdav.sb.aol.com
Lock-Token:opaquelocktoken:123AbcEfg1284h23h2
HTTP/1.1 200 OK
In this example, the lock identified by the lock token
"opaquelocktoken:123AbcEfg1284h23h2" 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 was removed
from those resources as well.
8.15. PATCH Method
The If-None-State-Match header PATCH method is intended to have similar
functionality used to modify parts of the If-None-Match header defined entity returned in section
14.26
the response to a GET method. DAV compliant resources MAY support
the PATCH method.
8.15.1. The Request
The request entity of RFC 2068.
If any the PATCH method contains a list of
differences between the state tokens identifies resource identified by the current state Request-URI and
the desired content of the
resource, resource after the server MUST NOT perform PATCH action has been
applied. The list of differences is in a format defined by the requested method.
Instead, if
media type of the request method was GET, HEAD, INDEX, or GETMETA, entity (e.g., "application/diff") and must include
sufficient information to allow the server SHOULD respond with a 304 (Not Modified) response,
including to convert the cache-related entity-header fields (particularly
ETag) original
version of the current state of resource to the resource. For desired version. Processing
performed by PATCH is atomic. Hence all other
request methods, changes MUST be
successfully executed or the server method fails. PATCH MUST respond with fail if
executed on a status of 412
(Precondition Failed). non-existent resource; i.e., PATCH does not create a
resource as a side effect.
If none of the state tokens identifies the current state of the
resource, request appears (at least initially) to be acceptable, the
server MAY perform MUST transmit an interim 100 response message after receiving
the requested method.
Note that empty line terminating the "AND" request headers and "OR" keywords specified with continue
processing the If-
State-Match header request. Since the semantics of PATCH are non-
idempotent, responses to this method are intentionally not cacheable.
While server support for PATCH is optional, if a server does support
PATCH, it MUST support at least the text/xml diff format defined
below. Support for If-None-
State-Match, because this functionality the VTML difference format [VTML] is
recommended, but not required.
4.4 State Token Header
State-Token-Header = "State-Token" ":" 1#("<" State-Token ">")
The State Token header is intended to have similar functionality
to the etag header defined in section 14.20
8.15.2. text/xml elements for PATCH
The resourceupdate XML element contains a set of RFC 2068. XML sub-entities
that describe modification operations. The
purpose name and meaning of
these XML elements are given below. Processing of these directives
MUST be performed in the tag is to return state tokens defined order encountered within the XML document.
A directive operates on a the resource as modified by all previous
directives (executed in a response. sequential order). The contents length of the state-token are not
guaranteed to
resource MAY be exhaustive and are generally used to return extended or reduced by a
new state token that has been defined as PATCH.
The changes specified by the result of a method.
For example, if a LOCK method were successfully resourceupdate XML element MUST be
executed on a
resource the response would include atomically.
8.15.2.1. resourceupdate XML Element
Name: resourceupdate
Namespace: http://www.ietf.org/standards/dav/patch/
Purpose: Contains an ordered set of changes to a state token header with non-collection,
non-property resource.
Parent: None
Value= *(insert | delete | replace)
8.15.2.2. insert XML Element
Name: insert
Namespace: http://www.ietf.org/standards/dav/patch/
Purpose: Insert the
lock state token included.
4.5 E-Tags
E-tags have already been deployed using XML element's contents starting at the If-Match and If-None-
Match headers. Introducing two mechanisms to express e-tags
would only confuse matters, therefore e-tags should continue to
be expressed using quoted strings and
specified octet.
Parent: resourceupdate
Value: The insert XML element MUST contain an octet-range XML
attribute that specifies an octet position within the If-Match and If-None-
Match headers.
5 Locking
5.1 Locking: Introduction
Locking is used to arbitrate access to body of a resource amongst
principals that have equal access rights to that
resource.
This specification allows locks to vary over two parameters, A value of _end_ specifies the
number end of principals involved and the type resource. The
body of access the insert XML element contains the octets to be
granted. Furthermore, inserted.
Please note that in order to protect the white space contained in
this document only provides XML element the definition
of locking for one access type, write. However, following attribute/value MUST be included in
the syntax element: XML-SPACE = "PRESERVE". This attribute is
extensible, and allows defined in
the XML specification [Bray, Sperberg-McQueen, 1997].
8.15.2.3. delete XML Element
Name: delete
Namespace: http://www.ietf.org/standards/dav/patch/
Purpose: Removes the specified range of other access types.
5.1.1 Exclusive Vs. Shared Locks octets.
Parent: resourceupdate
Value: The most basic form of lock is delete XML element MUST contain an exclusive lock. This is a lock
where the access right in question is only granted to a single
principal. octet-range XML
attribute.
Discussion: The need for this arbitration results from a desire to
avoid having to constantly merge results. In fact, many users so
dislike having to merge that they would rather serialize their
access to a resource rather than have to constantly perform
merges.
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 right. 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 octets that affect a
resource. The first trust set is created by access permissions.
Principals who are trusted, for example, may have permission to
write the resource, those who deleted are not, don't. Among those who
have access permission to write removed, which means the resource,
resource is collapsed and the set length 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 resource is decremented
by the vast majority size of these principals will the octet range. It is not have
write access appropriate to replace
deleted octets with zeroed-out octets, since zero is a given resource. Of valid octet
value.
8.15.2.4. replace XML Element
Name: replace
Namespace: http://www.ietf.org/standards/dav/patch/
Purpose: Replaces the specified range of octets with the contents
of the XML element. If the small number who do
have write access, some principals may decide to guarantee their
edits are free of octets in the XML element is
different from overwrite conflicts by using exclusive write
locks. Others may decide they trust their collaborators (the
potential set the number of collaborators being octets specified, the set update MUST be
rejected.
Parent: resourceupdate
Value: The replace XML element MUST contain an octet-range XML
attribute. The contents of principals who
have write permission) and use the entity are the replacement octets.
Please note that in order to protect the white space contained in
this XML element the following attribute/value MUST be included in
the element: XML-SPACE = "PRESERVE"
.
This attribute is defined in the
XML specification [Bray, Sperberg-McQueen, 1997].
8.15.2.5. octet-range Attribute
Name: octet-range
Namespace: http://www.ietf.org/standards/dav/patch/
Purpose: Specifies a shared lock, which informs their
collaborators range of octets that the enclosing property
affects.
Parent: insert | delete | replace
Value: number [_-_ (number | _end_)]
Number = 1*Digit
Description: Octet numbering begins with 0. If the octet contains a principal is potentially working on
single number then the
resource.
The WebDAV extensions operation is to HTTP do not need begin at that octet and to provide all of the
communications paths necessary
continue 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 a length specified by the
screen, telephone conversation, email, etc.) The intent operation. In the case of a
shared lock is
delete, this would mean to let collaborators know who else is potentially
working on delete a resource.
Shared locks are included because experience from web distributed
authoring systems has indicated that exclusive write locks are
often too rigid. An exclusive write lock is used single octet. In the case of an
insert this would mean to enforce a
particular editing process: take out exclusive write lock, read begin the resource, perform edits, write insertion at the resource, release specified octet
and to continue for the
lock. What happens if length of the lock isn't released? While included value, extending the time-
out mechanism provides one solution,
resource if you need to force necessary. In the
release case of a lock immediately, it doesn't help much. Granted, an
administrator can release replace, the lock for you, but this could become
a significant burden for large sites. In addition there is replace begins
at the
problem specified octet and overwrites all that an administrator may not be immediately available.
Despite their potential problems, exclusive write locks are
extremely useful, since often a guarantee follow to the length
of freedom from
overwrite conflicts is what is needed. the included value.
8.15.3. Response Codes
200 OK - The tradeoff described request entity body was processed without error,
resulting in
this specification is to provide exclusive write locks, but also an update to provide a less strict mechanism in the form state of shared locks
which can be used by a set the resource.
409 Conflict - If the update information in the request message body
does not make sense given the current state of people who trust each other and who
have access the resource (e.g.,
an instruction to delete a communications channel external to HTTP which
can non-existent line), this status code MAY
be used to negotiate writing to the resource.
5.1.2 Required Support
A WebDAV compliant returned.
415 Unsupported Media Type - The server is does not required to support locking the content
type of the update instructions in
any form. If the server request message body.
418 Unprocessable Entity - The entity body submitted with the PATCH
was not understood by the resource.
419 Insufficient Space on Resource - The resource does support locking it may choose not have
sufficient space to
support any combination record the state of exclusive and shared locks for any
access types. the resource after the
execution of this method.
8.15.4. HTML file modification Example
The reason following example shows a modification of the title and contents
of the HTML resource http://www.example.org/hello.html.
Before:
<HTML>
<HEAD>
<TITLE>Hello world HTML page</TITLE>
</HEAD>
<BODY>
<P>Hello, world!</P>
</BODY>
</HTML>
PATCH Request: Response:
PATCH hello.html HTTP/1.1
Host: www.example.org
Content-Type: text/xml
Content-Length: xxx
HTTP/1.1 100 Continue
<?XML version="1.0">
<?namespace href = _http://www.ietf.org/standards/dav/patch/_ AS =
_D_?>
<D:resourceupdate>
<D:replace XML-SPACE = "PRESERVE">
<D:octet-range>14</D:octet-range>&003CTITLE&003ENew
Title&003C/TITLE&003E</D:replace>
<D:delete><D:octet-range>38-50</D:octet-range></D:delete>
<D:insert XML-SPACE = "PRESERVE"><D:octet-range>86</D:octet-
range>&003CP&003ENew paragraph&003C/P&003E</D:insert>
</D:resourceupdate>
HTTP/1.1 200 OK
After:
<HTML>
<HEAD>
<TITLE>New Title</TITLE>
</HEAD>
<BODY>
<P>Hello, world!</P>
<P>New paragraph</P>
</BODY>
</HTML>
9. HTTP Headers for this flexibility Distributed Authoring
9.1. Collection-Member Header
CollectionMember = "Collection-Member" ":" URI ; URI is that server implementers have
said that they are willing to accept minimum requirements on all
services but locking. Locking policy strikes to defined in
section 3.2.1 of [Fielding et al., 1997]
The Collection-Member header specifies the very heart URI of
their an external
resource management and versioning systems and they require
control over what sort of locking will to be made available. For
example, some systems 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 added/deleted to/from a collection.
9.2. DAV Header
DAV = "DAV" ":" ("1" | "2" | extend)
This header indicates that the resource supports the DAV schema and
protocol to merit exclusion of certain locking features, the
authors are proposing that locking be allowed as level indicated. All DAV compliant resources MUST
return the sole axis of
negotiation within WebDAV.
5.2 LOCK Method DAV header on all OPTIONS responses.
9.3. Depth Header
Depth = "Depth" ":" ("0" | "1" | "infinity")
The following sections describe the LOCK method, which Depth header is used to
take out a lock of any access type. These sections with methods executed on collections to
indicate whether the LOCK method describe is to be applied only those semantics that are specific to the
LOCK method and are independent of the access type of the lock
being requested. Once collection
(Depth = 0), to the general LOCK method has been
described, subsequent sections describe collection and its immediate children, (Depth =
1), or the semantics of collection and all its progeny (Depth = infinity). Note
that Depth = 1 and Depth = infinity behavior only applies to
internal member resources, and not to external member resources.
The Depth header is only supported if a method's definition
explicitly provides for such support.
The following rules are the
"write" access type, and default behavior for any method that
supports the write lock.
5.2.1 Operation depth header. A LOCK method invocation creates the lock specified MAY override these defaults by
defining different behavior in its definition.
Methods which support the Lock-
Info 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 Request-URI. Lock method requests SHOULD NOT
have on a request body. A user-agent SHOULD submit an Owner collection if a depth header
field with is not
present. For example, the MOVE method only supports Depth = infinity
and if a lock request.
A successful response to depth header is not present will act as if a lock invocation Depth =
infinity header had been applied.
Clients MUST include Lock-
Token and Time-Out headers.
5.2.2 The Effect NOT rely upon methods executing on members of Locks their
hierarchies in any particular order or the execution being atomic.
Note that methods MAY provide guarantees on Properties ordering and Containers
By default the scope of atomicity.
Upon execution, a lock is the entire state method with a depth header will perform as much of the
resource, including
its body assigned task as possible and associated properties. As then return a
result, response specifying
what it was able to accomplish and what it failed to do.
So, for example, an attempt to COPY a lock hierarchy may result in some
of the members being copied and some not.
Any headers on a method with a depth header MUST be applied to all
resources in the scope of the method. For example, an if-match
header will have its value applied against every resource also locks in the resource's
properties,
method's scope and will cause the method to fail if the header fails
to match.
If a lock on a property may lock a property's
resource resource, source or may restrict destination, within the ability to lock scope of the property's
resource. Only method
is locked in such a single way as to prevent the successful execution of
the method, then the lock token for that resource MUST be used when a lock
extends to cover both submitted
with the request in the Lock-Token request header.
9.4. Destination Header
Destination = "Destination" ":" URI
The Destination header specifies a destination resource for methods
such as COPY and its properties. Note MOVE, which take two URIs as parameters.
9.5. Destroy Header
DestroyHeader = "Destroy" ":" #Choices
Choices = "VersionDestroy" | "NoUndelete" | "Undelete" | extend
Extend = RFC-Reg | Coded-URL
RFC-Req = Token ; This is a token value (defined in section 2.2 of
[Fielding et al., 1997]) that
certain lock types MAY override this behavior.
For containers, has been published as an RFC.
Coded-URL = "<" URI ">"
When deleting a lock also affects resource the ability client often wishes to add or remove
members. The nature specify exactly
what sort of delete should be performed. The Destroy header, used
with the effect depends upon the type of access
control involved.
5.2.3 Locking Replicated Resources
Some servers automatically replicate resources across multiple
URLs. In such a circumstance Mandatory header, allows the server MAY only accept a lock on
one of client to specify the URLs end
result it desires. The Destroy header is specified as follows:
The Undelete token requests that, if possible, the server resource should
be left in a state such that it can guarantee be undeleted. The server is not
required to honor this request.
The NoUndelete token requests that the resource MUST NOT be left in
a state such that the lock will it can be
honored across all the URLs.
5.2.4 Locking Multiple Resources undeleted.
The LOCK method supports locking multiple resources
simultaneously by allowing for VersionDestroy token includes the listing functionality of several URIs in the
LOCK request. These URIs, in addition
NoUndelete token and extends it to include having the Request-URI, are
then server remove
all versioning references to the resource that it has control over.
9.6. Enforce-Live-Properties Header
EnforceLiveProperties = "Enforce-Live-Properties_ _:" (_*_ | "Omit"
| 1*(Property-Name))
Property-Name = Coded-URL
The Enforce-Live-Properties header specifies properties that MUST be locked as a result
_live_ after they are copied (moved) to the destination resource of
a copy (or move). If the LOCK method's invocation.
When multiple resources are specified value _*_ is given for the LOCK method only
succeeds if header, then it
designates all specified resources are successfully locked.
The Lock-Tree option of live properties on the lock request specifies that source resource. If the value
is "Omit" then the server MUST NOT duplicate on the destination
resource and all its internal children (including internal
collections, and their internal members) any properties that are to be locked. This
is another mechanism by which a request for a lock defined on multiple
resources can be specified.
Currently existing locks can the source resource. If
this header is not be extended to cover more or
less resources, and any request included then the server is expected to expand or contract act as
defined by the number default property handling behavior of resources the associated
method.
9.7. If-None-State-Match
If-None-State-Match = "If-None-State-Match" ":" 1#Coded-URL
The If-None-State-Match header is intended to have similar
functionality to the If-None-Match header defined in a lock MUST fail section 14.26
of RFC 2068. However the if-none-state-match header is intended for
use with any URI which represents state information about a 409 Conflict status code.
So, for example, if resource A is exclusively write locked and
then the same principal asked
resource, referred to exclusively write lock resources
A, B, and C, the request would fail as a state token. A typical example is already locked and
the lock can not be extended.
A successful result will return a single lock token which
represents all the resources that have been locked. If an UNLOCK
is executed on this token, all associated resources are unlocked.
token.
If any of the lock can not be granted to all resources, a 406 Conflict
status code state tokens identifies the current state of the
resource, the server MUST be returned with a response entity body
containing a multiresponse XML element describing which
resource(s) prevented NOT perform the lock from being granted.
5.2.5 Interaction requested method.
Instead, if the request method was GET, HEAD, INDEX, or PROPFIND,
the server SHOULD respond with other Methods
The interaction of a LOCK with various methods is dependent upon 304 Not Modified response,
including the lock type. However, independent of lock type, a successful
DELETE cache-related entity-header fields (particularly ETag)
of a resource MUST cause all the current state of its locks to be removed.
5.2.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
Lock For all other request
None True True
Shared Lock True False
Exclusive Lock False False*
Legend: True = lock MAY be granted. False = lock MUST NOT be
granted. *=if
methods, the principal requesting server MUST respond with a status of 412 Precondition
Failed.
If none of the lock is state tokens identifies the owner current state of the lock,
resource, the lock server MAY be regranted.
The current lock state perform the requested method.
If any of a resource the tokens is given in not recognized then the leftmost
column, method MUST fail
with a 412 Precondition Failed.
Note that the "AND" and lock requests are listed in "OR" keywords specified with the first row. If-State-
Match header are intentionally not defined for If-None-State-Match,
because this functionality is not required.
9.8. If-State-Match
If-State-Match = "If-State-Match" ":" ("AND" | "OR") 1#Coded-URL
The
intersection of a row and column gives If-State-Match header is intended to have similar functionality
to the result If-Match header defined in section 14.25 of RFC 2068.
However the If-State-Match header is intended for use with any URI
which represents state information about a lock
request. For example, if a shared lock resource. A typical
example is held on a resource,
and an exclusive lock is requested, token.
If the table entry AND keyword is "false",
indicating used and all of the lock must not be granted.
If an exclusive or shared lock is re-requested by state tokens identify the principal
who owns
state of the lock, resource, then the lock MUST be regranted. server MAY perform the requested
method. If the lock OR keyword is
regranted, used and any of the same lock token that was previously issued MUST be
returned.
5.2.7 Status Codes
409 "Conflict" - The resource is locked, so state tokens
identifies the method has been
rejected.
412 "Precondition Failed" - The included state-token was not
enforceable on this resource or current state of the resource, then the server MAY
perform the requested method. If the request in keyword requirement for the lock-info
header could
the keyword used is not be satisfied by met, the server.
5.2.8 Lock-Info Request Header
The Lock-Info request header specifies server MUST NOT perform the scope
requested method, and type of a
lock for MUST return a LOCK method request. The syntax specification below 412 Precondition Failed
response.
If any of the tokens is
extensible, allowing new type and scope identifiers to be added. not recognized then the method MUST fail
with a 412 Precondition Failed.
9.9. Lock-Info Request Header
LockInfo = "Lock-Info" ":" DAVLockType SP DAVLockScope [SP
AdditionalLocks] [SP Lock-Tree]
DAVLockType = "LockType" "=" DAVLockTypeValue
DAVLockTypeValue = ("Write" | *(uchar | reserved)) Extend)
DAVLockScope = "LockScope" "=" DAVLockScopeValue
DAVLockScopeValue = ("Exclusive" |"Shared" | *(uchar | reserved)) Extend)
AdditionalLocks = "AddLocks" "=" 1*("<" URI ">")
Lock-Tree = "Lock-Tree" "=" ("True" ("T" | "False") "F")
The Lock-Info request header specifies the scope and type of a lock
for a LOCK method request. The syntax specification below is
extensible, allowing new type and scope identifiers to be added.
The LockType field specifies the access type of the lock. At
present, this specification only defines one lock type, the "Write"
lock. The LockScope field specifies whether the lock is an
exclusive lock, or a shared lock. The AddLocks field specifies
additional URIs, beyond the Request-URI, to which the lock request
applies. The LockTree field is used to specify recursive locks. If
the LockTree field is "true", the lock "T", the lock request applies to the hierarchy
traversal of the internal member resources of the Request-URI, and
the AddLocks URIs, inclusive of the Request-URI and the AddLocks
URIs. It is not an error if LockTree is "T", and the Request-URI or
the AddLocks URIs have no internal member resources. By default,
the value of LockTree is "F", and this field MAY be omitted when its
value is "F".
9.10. Lock-Token Request Header
Lock-Token = "Lock-Token" ":" 1#Coded-URL
The Lock-Token request header, containing a lock token owned by the
requesting principal, is used by the principal to indicate that the
principal is aware of the existence of the lock specified by the
lock token.
If the following conditions are met:
1) The method is restricted by a lock type that requires the
submission of a lock token, such as a write lock,
2) The user-agent has authenticated itself as a principal,
3) The user-agent is submitting a method request applies to a resource on
which the hierarchy traversal of principal owns a write lock,
Then:
1) The method request MUST include a Lock-Token header with the internal
members lock
token, or,
2) The method MUST fail with a 409 Conflict status code.
If multiple resources of the Request-URI, and the AddLocks URIs,
inclusive of the Request-URI and the AddLocks URIs. It is not an
error if LockTree is true, and the Request-URI are involved with a method, such as a COPY or
MOVE method, then the AddLocks
URIs have no internal member resources. By default, the value of
LockTree is "false", and this field MAY lock tokens, if any, for all involved
resources, MUST be omitted when its value
is false.
5.2.9 Owner Request Header
5.2.9.1 Problem Description
When discovering included in the list of owners of locks Lock-Token request header.
For example, Program A, used by user A, takes out a write lock on a resource,
resource. Program A then makes a
principal may want to be able to contact number of PUT requests on the owner directly. For
this to be possible
locked resource. All the lock discovery mechanism must provide
enough information for requests contain a Lock-Token request
header that includes the write lock owner to be contacted.
Additionally, programs may wish state token. Program B, also
run by User A, then proceeds to be able perform a PUT to record structured
information in the owner header locked
resource. However, program B was not aware of the existence of the
lock and so that other programs may be
able does not include the appropriate Lock-Token request
header. The method is rejected even though principal A is
authorized to parse perform the PUT. Program B can, if it later. Note, however, that these programs may
not necessarily be coordinating so there need be no guarantee
that chooses, now
perform lock discovery and obtain the information can be parsed.
5.2.9.2 Solution Requirements
Not all systems have authentication procedures lock token. Note that provide
sufficient information
programs A and B can perform GETs without using the Lock-Token
header because the ability to identify a particular user in perform a way
that GET is meaningful to not affected by a person. In addition, many systems that do
have sufficient information, such as
write lock.
Having a name and e-mail address,
do lock token provides no special access rights. Anyone can
find out anyone else's lock token by performing lock discovery.
Locks are to be enforced based upon whatever authentication
mechanism is used by the server, not have based on the ability to associate this information with secrecy of the
lock discovery mechanism. Therefore
token values.
9.11. Lock-Token Response Header
Lock-Token = "Lock-Token" ":" Coded-URL
If a means resource is needed to allow
principals to provide authentication in successfully locked then a manner which Lock-Token header will
be
meaningful to a person. returned containing the lock token that represents the lock.
9.12. Overwrite Header
Overwrite = "Overwrite" ":" ("T" | "F")
The From Overwrite header (defined in RFC 2068), which contains only an
email mailbox, is not sufficient for specifies whether the server should overwrite
the purposes state of quick
identification. When desperately looking for someone to remove a
lock, e-mail is often not sufficient. non-null destination resource during a COPY or MOVE.
A telephone number (cell
number, pager number, etc.) would be better. Furthermore, value of _F_ states that the
email address in server MUST NOT perform the From header only optionally includes COPY or
MOVE operation if the
owners name and that name state of the destination resource is non-null.
By default, the value of Overwrite is often set to an alias anyway.
Therefore _T,_ and a client MAY omit
this header more flexible than From is required.
The from a request when its value also needs is _T._ While the
Overwrite header appears to be such that both man and machine can
place values in it duplicate the functionality of the If-
Match: * header of HTTP/1.1, If-Match applies only to the Request-
URI, and later retrieve those values.
5.2.9.3 Syntax
Owner = "Owner" ":" (Coded-XML | quoted-string)
Coded-XML = field-content ; XML where any character which is not legal in field-content (see section 4.2 of [Fielding et al.,
1997]) is XML encoded
The XML SHOULD provide information sufficient for either directly
contacting to the principal (such as Destination of a telephone number COPY or e-mail
URI), MOVE.
If a COPY or for discovering the principal (such as MOVE is not performed due to the URL value of a
homepage) who owns the lock. The quoted string SHOULD provide a
means for directly contacting the principal who owns Overwrite
header, the lock,
such as method MUST fail with a name and telephone number.
5.2.10 Time-Out 409 Conflict status code.
9.13. Propfind Request Header
5.2.10.1 Problem Description
In a perfect world principals take out locks, work on the
resource, and then remove the lock when it is no longer needed.
However, this process
Propfind = "Propfind" ":" ("allprop" | "propname" | RFC-Reg |
1*(Property-Name))
The Propfind header is frequently not completed, leaving active
but unused locks. Reasons for this include client programs
crashing and losing information about locks, users leaving used to specify which properties are to be
returned in a PROPFIND method. The properties are identified by
their
systems URIs. Two special tokens are defined for use with the day
Propfind header, allprop and forgetting to remove their locks, etc. As
a result of this behavior, servers need propname. The allprop token specifies
that all property names and values on the resource are to establish a policy by
which they can remove be
returned. The propname token specifies that only a lock without input from list of property
names on the lock owner.
Once such a policy is instituted, resource are to be returned.
9.14. Status-URI Response Header
The Status-URI response header MAY be used with the server also needs a
mechanism 102 Processing
response code to inform the principal of the policy.
5.2.10.2 Solution Requirements
There are two basic lock removal policies: administrator and time
based removal. In client as to the case status of administrator based removal, a
principal other than method.
Status-URI = "Status-URI" ":" *(Status-Code "<" URI ">") ; Status-
Code is defined in 6.1.1 of [Fielding et al., 1997]
The URIs listed in the lock owner has sufficient access rights
to order header are source resources which have been
affected by the lock removed, even though they did not take it out. outstanding method. The second policy type is time based removal. In this case, a
timer is set as soon as status code indicates the
resolution of the lock is created. Every time a method
is executed on any resource covered by the lock, the timer identified resource. So, for
example, if a MOVE method on a collection is
reset. If the timer runs out, the lock outstanding and a 102
"Processing" response with a Status-URI response header is removed.
User-agents MUST assume that locks may arbitrarily disappear at
any time. If their actions require confirmation of returned,
the existence
of a lock then included URIs will indicate resources that have had move
attempted on them and what the If-State headers are available.
5.2.10.3 Syntax result was.
9.15. Timeout Header
TimeOut = "Time-Out" "Timeout" ":" 1#TimeType
TimeType = ("Second-" DAVTimeOutVal | "Infinite" | Extend) Other)
DAVTimeOutVal = 1*digit
Extend
Other = RFC-Reg | URL "-" Token ; The URL format is used for
unregistered TimeTypes
RFC-Req = Token Extend field-value ; This is a TimeType that has been published as
an See section 4.2 of RFC 2068
Clients MAY include TimeOut Timeout headers in their LOCK requests.
However
However, the server is not required to honor or even consider the
request. these
requests. Clients MUST NOT submit a Time-Out Timeout request header with any
method other than a LOCK method.
A Time-Out 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.
The Time-Out Timeout response header 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 Time-Out Timeout
header.
The "Second" _Second_ TimeType specifies the number of seconds that MUST
elapse between granting of the lock at the server, and the automatic
removal of the lock. A server MUST not generate a time
out timeout value for "Second"
_Second_ greater than 2^32-1.
The time out timeout counter is restarted any time an owner of the client lock sends
a method to any member of the lock, including unsupported methods,
or methods which are unsuccessful. It is recommended that the HEAD
method be used when the goal is simply to restart the time
out timeout
counter.
If the timeout expires then the lock is lost. Specifically 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 its override authority. Thus logs,
notifications, and other mechanisms that act as side effects to
the granting and removal of a lock will logs should be properly informed as
to updated
with the disposition of the lock. 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 time-
out 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 time-out because its user may be planning
on going off-line.
5.2.11 Lock Response
A successful lock response MUST contain a Lock-Token response
header, a Time-Out header and a PROP element in the response body
which contains the value of the LockDiscovery property.
5.2.11.1 Lock-Token Response Header
If a resource is successfully locked then a lock-token header
will be returned containing the lock token that represents the
lock.
Lock-Token = "Lock-Token" ":" URI
5.2.12 Example - Simple Lock Request
LOCK /workspace/webdav/proposal.doc HTTP/1.1
Host: webdav.sb.aol.com
Lock-Info: LockType=Write LockScope=Exclusive
Time-Out: Infinite; Second-4100000000
Owner: <?XML:Namespace href="http://www.ietf.org/standards/dav/"
AS =
"D"/><D:HREF>http://www.ics.uci.edu/~ejw/contact.html</D:HREF>
HTTP/1.1 200 OK
Lock-Token: OpaqueLockToken:xyz122393481230912asdfa09s8df09s7df08
sd0f98a098sda
Time-Out: Second-604800
Content-Type: text/xml
Content-Length: xxxxx
<?XML:Namespace
href ="http://www.ietf.org/standards/dav/" AS = "D"/>
<D:Prop>
<lockdiscovery>
<activelock>
<locktype>write</locktype>
<lockscope>exclusive</lockscope>
<addlocks/>
<owner>
<HREF>http://www.ics.uci.edu/~ejw/contact.html</HREF>
</owner>
<timeout>Second-604800</timeout>
<locktoken>
<HREF>
OpaqueLockToken:xyz122393481230912asdfa09s8df09s7d
f08sd0f98a098sda
</HREF>
</locktoken>
</activelock>
</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 type of activity the lock. The server has
client intends to perform. For example, an
activity-based timeout policy applet running in place on this a
browser may need to lock a resource, but because of the instability
of the environment within which
causes the lock to automatically applet is running, the applet
may be removed after 1 week (604800
seconds). The response has turned off without warning. As a Lock-Token header that gives result, the
state token URL applet is
likely to ask for a relatively small timeout value so that if the
applet dies, the lock token generated by this lock
request.
5.2.13 Example - Multi-Resource Lock Request
LOCK /workspace/webdav/proposal.doc HTTP/1.1
Host: webdav.sb.aol.com
Lock-Info: LockType=Write LockScope=Exclusive
Addlocks=<http://webdav.sb.aol.com/workspace/><http://foo.bar/bla
h>
Time-Out: Infinite, Second-4100000000
Owner: <http://www.ics.uci.edu/~ejw/contact.html>
HTTP/1.1 409 Conflict
Content-Type: text/xml
Content-Length: xxxxx
<?XML:Namespace href =
"http://www.ietf.org/standards/dav/" As = "D"/>
<D:MultiResponse>
<Response>
<HREF>
http://webdav.sb.aol.com/workspace/webdav/proposal.doc
</HREF>
<HREF>
http://webdav.sb.aol.com/workspace/webdav/
</HREF>
<Status>HTTP/1.1 202 Accepted</Status>
</Response>
<Response>
<HREF>http://foo.bar/blah</HREF>
<Status>HTTP/1.1 403 Forbidden</Status>
</Response>
</D:MultiResponse>
This example shows can be quickly harvested. However, a request document
management system is likely to ask for an exclusive write lock extremely long timeout
because its user may be planning on three
resources,
http://webdav.sb.aol.com/workspace/webdav/proposal.doc,
http://webdav.sb.aol.com/workspace/, and http://foo.bar/blah. In
this request, the client has specified that it desires an
infinite length lock, if available, otherwise going off-line.
10. Response Code Extensions to HTTP/1.1
The following response codes are added to those defined in HTTP/1.1
[Fielding et al., 1997].
10.1. 102 Processing
Methods can potentially take a timeout long period of 4.1
billion seconds, if available. The Owner header field specifies time to process,
especially methods that support the web address for contact information for Depth header. In such cases the principal taking
out
client may time-out the lock.
This lock request has failed, because connection while waiting for a response. To
prevent this the server rejected the
lock request for http://foo.bar/blah. The 409 Conflict status MAY return a 102 response code indicates to indicate
to the client that the server was unable to satisfy is still processing the request
because there method.
If a method is taking longer than 20 seconds (a reasonable, but
arbitrary value) to process the server SHOULD return a conflict between 102
"Processing" response.
10.2. 207 Multi-Status
The response requires providing status for multiple independent
operations.
10.3. 418 Unprocessable Entity
The server understands the state content type of the resources
and the operation named in request entity, but
was unable to process the request. Within contained instructions.
10.4. 419 Insufficient Space on Resource
The resource does not have sufficient space to record the
multiresponse, state of
the 202 Accepted status code indicates that resource after the
lock execution of this method.
10.5. 420 Method Failure
The method was accepted by not executed on a particular resource within its
scope because some part of the resources, and would have been
completed if all resources named in method's execution failed causing the request were able
entire method to be
locked. aborted. For example, if a resource could not
be moved as part of a MOVE method, all the other resources would
fail with a 420 Method Failure.
10.6. 421 Destination Locked
The 403 Forbidden status code indicates that destination resource of a method is locked, and either the server
does
request did not allow lock requests on this resource.
5.3 Write Lock
This section describes the semantics specific to contain a valid Lock-Info header, or the write access
type for locks. The write Lock-Info
header identifies a lock held by another principal.
11. Multi-Status Response
The default 207 Multi-Status response body is a specific instance of text/xml HTTP entity
that contains a lock
type, single XML element called multistatus, which
contains a set of XML elements called response, one for each 200,
300, 400, and is 500 series status code generated during the only lock type described method
invocation. 100 series status codes MUST NOT be recorded in this specification.
5.3.1 Methods Restricted by Write Locks
A write lock prevents a principal without
response XML element.
11.1. multistatus XML Element
Name: multistatus
Namespace: http://www.ietf.org/standards/dav/
Purpose: Contains multiple response messages.
Parent: Any
Value: 1*response [responsedescription]
Description: The responsedescription at the lock from
successfully executing top level is used to
provide a PUT, POST, PATCH, PROPPATCH, MOVE,
DELETE, MKCOL, ADDREF or DELREF on general message describing the locked resource. All other
current methods, GET in particular, function independent overarching nature of the
lock.
Note, however, that as new methods are created
response. If this value is available an application MAY use it will be
necessary to specify how they interact with a write lock.
5.3.2 Write Locks and Properties
While those without a write lock may not alter a property on
instead of presenting the individual response descriptions contained
within the responses.
11.2. response XML Element
Name: response
Namespace: http://www.ietf.org/standards/dav/
Purpose: Holds a
resource it is still possible for single response
Parent: multistatus
Value: href [prop] status [responsedescription]
Description: Prop MUST contain one or more empty XML elements
representing the values names of live properties. Multiple properties
to change, even while locked, due to may be
included if the requirements of their
schemas. Only dead properties and live properties defined to
respect locks are guaranteed same response applies to not change while write locked. them all. If a property href is write locked used
then a LOCK request on the
associated resource MUST fail response refers to a problem with the referenced resource,
not a property.
11.3. status XML Element
Name: status
Namespace: http://www.ietf.org/standards/dav/
Purpose: Holds a single HTTP status-line
Parent: response
Value: status-line ;status-line defined in [Fielding et al.,
1997]
11.4. responsedescription XML Element
Name: responsedescription
Namespace: http://www.ietf.org/standards/dav/
Purpose: Contains a 409 "Conflict". Note message that a
write lock on a property MAY can be extended displayed to include the
associated resource without user
explaining the principal having explicitly
requested nature of the extension.
5.3.3 Write Locks and Null Resources
It is possible response.
Parent: multistatus | response
Value: Any
Description: This XML element provides information suitable to be
presented to assert a write lock on user.
12. Generic DAV XML Elements
12.1. href XML Element
Name: href
Namespace: http://www.ietf.org/standards/dav/
Purpose: To identify that the content of the element is a null resource in order URI.
Parent: Any
Value: URI ; See section 3.2.1 of [Fielding et al., 1997]
12.2. link XML Element
Name: link
Namespace: http://www.ietf.org/standards/dav/
Purpose: To identify a property as a link and to lock contain the name. Please note, however,
source and destination of that locking a null
resource effectively makes the resource non-null as link.
Values= 1*src 1*dst
Description: Link is used to provide the resource
now has lock related properties defined on it.
5.3.4 Write Locks sources and Collections
A write lock on destinations of
a collection prevents the addition or removal link. The type of
members the property containing the link XML element
provides the type of the collection. As a consequence, when a principal
issues link. Link is a request multi-valued element, so
multiple Links may be used together to create a new internal member indicate multiple links with
the same type.
12.2.1. src XML Element
Name: src
Namespace: http://www.ietf.org/standards/dav/
Purpose: To indicate the source of a collection
using PUT or POST, or to remove an existing internal member link.
Parent: link
Values= URI
12.2.2. dst XML Element
Name: dst
Namespace: http://www.ietf.org/standards/dav/
Purpose: To indicate the destination of a
collection using DELETE, link
Parent: link
Values= URI
12.2.3. Example
<?XML version="1.0">
<?namespace href = "http://www.ietf.org/standards/dav/" AS = "D"?>
<?namespace href = "http://www.foocorp.com/Project/" AS = "F"?>
<D:prop>
<D:Source>
<D:link>
<F:projfiles>Source</F:projfiles>
<D:src>http://foo.bar/program</D:src>
<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 request MUST fail if the principal
does not have a write lock on example the collection.
However, if a write lock request is issued to resource http://foo.bar/program has a collection
containing internal member resources source
property that contains three links. Each link contains three
elements, two of which, src and dst, are currently locked, part of the request MUST fail with a 409 Conflict status code.
5.3.5 Write Locks DAV schema
defined in this document, and COPY/MOVE
The owner of a write lock MUST NOT execute a MOVE method on a
resource they have locked. This specification intentionally does
not define what happens if a MOVE method request one which is made on a
locked resource defined by the lock's owner. schema
http://www.foocorp.com/project/ (Source, Library, and Makefile). A COPY method invocation MUST NOT duplicate any write locks
active on
client which only implements the source.
5.3.6 Re-issuing Write Locks
If a principal already owns a write lock on a resource, any
future requests for elements in the same type of write lock, on DAV spec will not
understand the same
resource, while foocorp elements and will ignore them, thus seeing
the principal's previous write lock is in effect,
MUST result in a successful response 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 same lock token as
provided for links. This example demonstrates
the currently existing lock. Two lock requests are
defined power of XML markup that allows for element values to be identical if their Lock-Info headers are identical.
5.3.7 Write Locks and The State-Token Header
5.3.7.1 Problem Definition
If
enhanced without breaking older clients.
12.3. prop XML element
Name: prop
Namespace: http://www.ietf.org/standards/dav/
Purpose: Contains properties related to a user agent resource.
Parent: Any
Values: XML Elements
Description: The prop XML element is not required to have knowledge about a lock
when requesting an operation generic container for
properties defined on a locked resource, resources. All elements inside prop MUST
define properties related to the following
scenario might occur. Program A, run by User A, takes out resource. No other elements may be
used inside of a write
lock prop element.
13. DAV Properties
13.1. creationdate Property
Name: creationdate
Namespace: http://www.ietf.org/standards/dav/
Purpose: The time and date the resource was created.
Value: The time and date MUST be given in ISO 8601 format
[ISO8601]
Description: This property SHOULD be defined on all DAV compliant
resources. If present, it contains a resource. Program B, also run by User A, has no
knowledge timestamp of the lock taken out by Program A, yet performs a PUT
to moment when
the locked resource. In this scenario, resource was created (i.e., the PUT succeeds
because locks are associated with a principal, not a program, and
thus program B, because moment it is acting with principal A’s
credential, is allowed to perform the PUT. However, had program B
known about non-null state).
13.2. displayname Property
Name: displayname
Namespace: http://www.ietf.org/standards/dav/
Purpose: A name for the lock, it would not have overwritten resource that is suitable for
presentation to a user.
Value: Any valid XML character data (as defined in [Bray,
Sperberg-McQueen, 1997])
Description:This property SHOULD be defined on all DAV compliant
resources. If present, the resource,
preferring instead to present property contains a dialog box describing description of the
conflict
resource that is suitable for presentation to the a user. Due to this scenario,
13.3. get-content-language Property
Name: get-content-language
Namespace: http://www.ietf.org/standards/dav/
Purpose: Contains the Content-Language header returned by a mechanism GET
without accept headers. If no Content-Language header is needed
to prevent different programs from accidentally ignoring locks
taken out by other programs with the same authorization.
5.3.7.2 Solution Requirement
The solution must not require principals to perform discovery in
order to prevent accidental overwrites as available,
this could cause race
conditions.
The solution must not require that clients guess what sorts property MUST NOT exist.
Value: language-tag ;language-tag is defined in section 14.13
of
locks might be used and use if-state-match headers with wildcards
to prevent collisions. The problem with trying to "guess" which
locks are being used RFC 2068
13.4. get-content-length Property
Name: get-content-length
Namespace: http://www.ietf.org/standards/dav/
Purpose: Contains the Content-Length header returned by a GET
without accept headers. If no Content-Length header is that new lock types might be introduced,
and available,
this property MUST NOT exist.
Value: content-length ; see section 14.14 of RFC 2068
13.5. get-content-type Property
Name: get-content-type
Namespace: http://www.ietf.org/standards/dav/
Purpose: Contains the program would not know to "guess them". So, for example, Content-Type header returned by a client might put GET
without accept headers. If no Content-Type header is available,
this property MUST NOT exist.
Value: media-type ; defined in an if-state-match Section 3.7 of [Fielding et
al., 1997]
13.6. get-etag Property
Name: get-etag
Namespace: http://www.ietf.org/standards/dav/
Purpose: Contains the ETag header with returned by a wildcard
specifying GET without
accept headers. If no ETag header is available, this property MUST
NOT exist.
Value: entity-tag ; defined in Section 3.11 of [Fielding et
al., 1997]
Description:Note that if the ETag on some resource may reflect changes
in any write lock is outstanding then part of the
operation should fail. However a new read/write lock could be
introduced which state of the client would resource, not know necessarily just a
change to put in the header.
5.3.7.3 State-Token Header
The State-Token header, containing response to the GET method. For example, a lock token owned by change in
the
requesting principal, is used by ACL may cause the principal ETag to indicate that change.
13.7. get-last-modified Property
Name: get-last-modified
Namespace: http://www.ietf.org/standards/dav/
Purpose: Contains the principal Last-Modified header returned by a GET
method without accept headers. If no Last-Modified header is aware
available, this property MUST NOT exist.
Value: HTTP-date ; defined in Section 3.3.1 of [Fielding et
al., 1997]
Description:Note that the existence last-modified date on some resource may
reflect changes in any part of the lock specified by state of the lock token. It is used in resource, not
necessarily just a change to the following way.
If response to the following conditions are met:
1. GET method. For
example, a user-agent has authenticated itself as change in a principal,
2. property may cause the user-agent is submitting a method request last-modified date to a
resource
on which the principal owns a write lock,
3.
change.
13.8. index-content-language Property
Name: index-content-language
Namespace: http://www.ietf.org/standards/dav/
Purpose: Contains the method is restricted Content-Language header returned by a write lock, as an
INDEX without accept headers. If no Content-Language header is
available, this property MUST NOT exist.
Value: language-tag ;language-tag is defined in
the section "Methods Restricted by a Write Lock",
then 14.13
of RFC 2068
13.9. index-content-length Property
Name: index-content-length
Namespace: http://www.ietf.org/standards/dav/
Purpose: Contains the method request MUST include a State-Token Content-Length header with
the lock token returned by an INDEX
without accept headers. If no Content-Length header is available,
this property MUST NOT exist.
Value: content-length ; see section 14.14 of RFC 2068
13.10. index-content-type Property
Name: index-content-type
Namespace: http://www.ietf.org/standards/dav/
Purpose: Contains the write lock, or the method fails with a 409
Conflict status code. Content-Type header returned by an INDEX
without accept headers. If multiple resources are involved with a
method, such as a COPY or MOVE method, then the lock tokens, if
any, for all involved resources, no Content-Type header is available,
this property MUST be included NOT exist.
Value: media-type ; defined in the State-
Token request header.
For example, Program A, used by user A, takes out a write lock on
a resource. Program A then makes a number Section 3.7 of PUT requests on the
locked resource, all [Fielding et
al., 1997]
13.11. index-etag Property
Name: index-etag
Namespace: http://www.ietf.org/standards/dav/
Purpose: Contains the requests contain a State-Token ETag header
which includes the write lock state token. Program B, also run returned by
User A, then proceeds to perform a PUT to an INDEX without
accept headers. If no ETag header is available, this property MUST
NOT exist.
Value: entity-tag ; defined in Section 3.11 of [Fielding et
al., 1997]
Description:Note that the locked resource.
However program B was not aware ETag on some resource may reflect changes
in any part of the existence state of the lock and
so does resource, not include necessarily just a
change to the appropriate state-token header. The
method is rejected even though principal A is authorized response to
perform the PUT. Program B can, if it so chooses, now perform
lock discovery and obtain INDEX method. For example, a change
in the lock token. Note that program A and
B can perform GETs without using ACL may cause the ETag to change.
13.12. index-last-modified Property
Name: index-last-modified
Namespace: http://www.ietf.org/standards/dav/
Purpose: Contains the state-token Last-Modified header because
the ability to perform a GET is not affected returned by a write lock.
Having a lock state token provides an INDEX
method without accept headers. If no special access rights.
Anyone can find out anyone else’s lock state token by performing
lock discovery. Locks are to be enforced based upon whatever
authentication mechanism Last-Modified header is used by
available, this property MUST NOT exist.
Value: HTTP-date ; defined in Section 3.3.1 of [Fielding et
al., 1997]
Description:Note that the server, not based last-modified date on some resource may
reflect changes in any part of the
secrecy state of the token values.
5.3.7.3.1 Example
COPY /~fielding/index.html HTTP/1.1
Host: www.ics.uci.edu
Destination: http://www.ics.uci.edu/users/f/fielding/index.html
State-Token: <OpaqueLockToken:123AbcEfg1284h23h2>
<OpaqueLockToken:AAAASDFcalkjfdas12312>
HTTP/1.1 200 OK
In this resource, not
necessarily just a change to the response to the INDEX method. For
example, both a change in a property may cause the source and destination last-modified date to
change.
13.13. lockdiscovery Property
Name: lockdiscovery
Namespace: http://www.ietf.org/standards/dav/
Purpose: To discover what locks are locked so
two lock tokens must be submitted. If only one active on a resource
Values= *activelock
Description:The lockdiscovery property returns a listing of the two
resources was locked, then only one token would have to be
submitted.
5.4 Lock Tokens
5.4.1 Problem Description
It is possible that once who has
a lock, what type of lock has been granted it may be
removed without he have, the lock owner’s knowledge. This can cause
serialization problems if timeout type and the time
remaining on the timeout, and the associated lock owner executes methods
thinking their lock token. The server
is still active. Due free to this, a mechanism is
needed for a withhold any or all of this information if the requesting
principal does not have sufficient access rights to predicate see the successful execution of a
message upon
requested data. A server which supports locks MUST provide the continuing existence of a lock.
5.4.2 Lock Token Introduction
lockdiscovery property on any resource with locks on it.
13.13.1. activelock XML Element
Name: activelock
Namespace: http://www.ietf.org/standards/dav/
Purpose: A lock token is a type of state token multivalued XML element that describes a particular
lock. A lock token is returned by every successful LOCK
operation, and can also be discovered through
active lock discovery on a
resource.
There are two types of lock tokens, a generic lock token, which
is unique only for a particular resource, and an opaque resource
Parent: lockdiscovery
Values= locktype lockscope [addlocks] owner timeout locktoken
13.13.2. owner XML Element
Name: owner
Namespace: http://www.ietf.org/standards/dav/
Purpose: Returns owner information
Parent: activelock
Values= XML:REF | *PCDATA
13.13.3. timeout XML Element
Name: timeout
Namespace: http://www.ietf.org/standards/dav/
Purpose: Returns information about the timeout associated with
the lock
token, which is unique across all
Parent: activelock
Values= TimeType
13.13.4. addlocks XML Element
Name: addlocks
Namespace: http://www.ietf.org/standards/dav/
Purpose: Lists additional resources for all time.
Uniqueness for associated with this lock, if
any.
Parent: activelock
Values= 1*href
13.13.5. locktoken XML Element
Name: locktoken
Namespace: http://www.ietf.org/standards/dav/
Purpose: Returns the lock token
Parent: activelock
Values= href
Description:The href contains a particular Lock-Token-URL.
13.13.6. Example
PROPFIND /container/ HTTP/1.1
Host: www.foo.bar
Content-Length: xxxx
Content-Type: text/xml
<?XML version="1.0">
<?namespace href = "http://www.ietf.org/standards/dav/" AS = "D"?>
<D:propfind>
<D:prop><lockdiscovery/></D:prop>
</D:propfind>
HTTP/1.1 207 Multi-Status
Content-Type: text/xml
Content-Length: xxxxx
<?XML version="1.0">
<?namespace href ="http://www.ietf.org/standards/dav/" AS = "D"?>
<D:multistatus>
<D:response>
<D:prop>
<D:lockdiscovery>
<D:activelock>
<D:locktype>write</D:locktype>
<D:lockscope>exclusive</D:lockscope>
<D:addlocks>
<D:href>http://foo.com/doc/</D:href>
</D:addlocks>
<D:owner>Jane Smith</D:owner>
<D:timeout>Infinite</D:timeout>
<D:locktoken>
<D:href>iamuri:unique!!!!!</D:href>
</D:locktoken>
</D:activelock>
</D:lockdiscovery>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
</D:multistatus>
This resource prevents problems with long
held outstanding has a single exclusive write lock tokens being confused on it, with newer tokens. an
infinite timeout. This uniqueness requirement is the same as for e-tags. Uniqueness
across all resources for all time allows for tokens to be
submitted across resources and servers without fear of confusion.
Generic lock tokens, because of their relaxed uniqueness
requirements, are faster to generate than opaque lock tokens.
5.4.3 Generic Lock Tokens
Any valid URI can be used by also covers the resource as
http://foo.com/doc/.
13.14. resourcetype Property
Name: resourcetype
Namespace: http://www.ietf.org/standards/dav/
Purpose: This property contains a generic lock
token. The only requirement is series of XML elements that
specify information regarding the nature of the lock token MUST never
have been issued previously on that resource. Because a lock
token is This
specification only guaranteed to defines a single value, collection.
Value: XML elements
Description:This property MUST be unique defined on all DAV compliant
resources. The default value is empty.
13.14.1. collection XML Element
Name: collection
Namespace: http://www.ietf.org/standards/dav/
Purpose: Identifies the associated resource that
generated it, the lock token MUST NOT be submitted in as a state-
token request header or an if-state[-not]-match header on any
resource but collection.
Collection resources MUST define this value with the resourcetype
property.
Parent: resourcetype
Values: None
13.15. Source Link Property Type
Name: source
Namespace: http://www.ietf.org/standards/dav/link/
Purpose: The destination of the source link identifies the
resource that generated it.
5.4.4 OpaqueLockToken Lock Token contains the unprocessed source of the link's source.
Parent: None
Value: An XML document with zero or more link XML elements.
Discussion: The opaquelocktoken scheme source of the link (src) is designed to 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 unique across all
resources for all time. Due to accessed. When more than
one link destination exists, this uniqueness quality, specification asserts no policy on
ordering.
13.16. supportedlock Property
Name: supportedlock
Namespace: http://www.ietf.org/standards/dav/
Purpose: To provide a client
MAY submit an opaque listing of the lock token in a state-token request header
and an if-state[-not]-match header on capabilities supported
by the resource.
Values: An XML document containing zero or more LockEntry XML
elements.
Description:The supportedlock property of a resource other than the
one that returned it.
All resources MUST recognize returns a
listing of the opaquelocktoken scheme combinations of scope and access types which may be
able to, at minimum, recognize that the
specified in a lock token was not
generated by request on the resource. Note, however, Note that resources the actual
contents are themselves controlled by access controls so a server is
not required to generate opaquelocktokens.
In order to guarantee uniqueness across all resources for all
time provide information the opaquelocktoken requires client is not authorized to
see. If supportedlock is available on _*_ then it MUST define the use
set of locks allowed on all resources on that server.
13.16.1. lockentry XML Element
Name: lockentry
Namespace: http://www.ietf.org/standards/dav/
Purpose: Defines a DAVLockType/LockScope pair that may be legally
used with a LOCK on the GUID mechanism.
Opaquelocktoken generators however have specified resource.
Parent: supportedlock
Values= locktype lockscope
13.16.2. locktype XML Element
Name: locktype
Namespace: http://www.ietf.org/standards/dav/
Purpose: Lists a choice DAVLockType
Parent: lockentry
Values= DAVLockTypeValue
13.16.3. lockscope XML Element
Name: lockscope
Namespace: http://www.ietf.org/standards/dav/
Purpose: Lists a DAVLockScope
Parent: lockentry
Values: DAVLockScopeValue
13.16.4. Example
PROPFIND /container/ HTTP/1.1
Host: www.foo.bar
Content-Length: xxxx
Content-Type: text/xml
<?XML version="1.0">
<?namespace href = "http://www.ietf.org/standards/dav/" AS = "D"?>
<D:propfind>
<D:prop><supportedlock/></D:prop>
</D:propfind>
HTTP/1.1 207 Multi-Status
Content-Type: text/xml
Content-Length: xxxxx
<?XML version="1.0">
<?namespace href ="http://www.ietf.org/standards/dav/" AS = "D"?>
<D:multistatus>
<D:response>
<D:prop>
<D:supportedlock>
<D:LockEntry>
<D:locktype>Write</D:locktype>
<D:lockscope>Exclusive</D:lockscope>
</D:LockEntry>
<D:LockEntry>
<D:locktype>Write</D:locktype>
<D:lockscope>Shared</D:lockscope>
</D:LockEntry>
</D:supportedlock>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
</D:multistatus>
14. DAV Compliance Levels
A DAV compliant resource can choose from two levels of how they
create these tokens. They compliance.
A client can either generate a new GUID for
every lock token they create, discover which is potentially very
expensive, or they can create level a single GUID resource supports by executing
OPTIONS on the resource, and then add
extension characters. If examining the second method "DAV" header which is selected then the
program generating the
returned.
Since this document describes extensions MUST guarantee that to the same
extension will never HTTP/1.1 protocol,
minimally all DAV compliant resources, clients, and proxies MUST be used twice
compliant with the associated GUID.
Opaque-Lock-Token = "OpaqueLockToken" ":" GUID [Extension]
GUID = ; As defined in [LEACH]
Extension = *urlc ;urlc is defined in [Berners-Lee RFC 2068 [Fielding et al.,
1997] (draft-fielding-url-syntax-07.txt)
5.5 UNLOCK Method
5.5.1 Problem Definition
The UNLOCK method removes the lock identified by the lock token 1997].
14.1. Level 1
A level 1 compliant resource MUST meet all "MUST" requirements in
all sections of this document.
14.2. Level 2
A level 2 compliant resource MUST meet all level 1 requirements and
support the State-Token header from supportedlock property as well as the Request-URI, and all other
resources included LOCK method.
15. Internationalization Considerations
In the realm of internationalization issues, this specification is
substantively in compliance with the lock.
5.5.2 Example
UNLOCK /workspace/webdav/info.doc HTTP/1.1
Host: webdav.sb.aol.com
State-Token: OpaqueLockToken:123AbcEfg1284h23h2
HTTP/1.1 200 OK IETF Character Set Policy
[Alvestrand, 1997]. In this example, specification, human-readable fields can
be found in either the lock identified by value of a property, or in an error message
returned in a response entity body. In both cases, the lock token
"OpaqueLockToken:123AbcEfg1284h23h2" human-
readable content is successfully removed from encoded using XML, which has explicit provisions
for character set tagging and encoding, and requires by default that
XML processors read XML elements encoded using the resource http://webdav.sb.aol.com/workspace/webdav/info.doc.
If this lock included more than just one resource, UTF-8 and UCS-2
encodings of the lock is
removed ISO 10646 basic multilingual plane. Furthermore,
XML contains provisions for encoding XML elements using other
encoding schemes, notable among them UCS-4, which permits encoding
of characters from those resources as well.
5.6 Discovery Mechanisms
5.6.1 Lock Capability Discovery
5.6.1.1 Problem Definition
Since server lock support any ISO 10646 character plane.
The default character set encoding for XML data in this
specification, and in general, is optional, a client trying to lock a
resource on a server can either try UTF-8. WebDAV compliant
applications MUST support the lock UTF-8 and UCS-2 character set
encodings for XML elements, and hope SHOULD support the UCS-4 encoding.
The XML character set encoding declaration for each supported
character set MUST also be supported, since it is by using this
encoding declaration that an XML processor determines the
best, or perform some form encoding
of discovery an element.
XML also provides language tagging capability which provides the
ability to determine what lock
capabilities specify 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.
5.6.1.2 SupportedLock Property
Name: http://www.ietf.org/standards/dav/lock/supportedlock
Purpose: To provide a listing language of the lock capabilities supported
by contents of a particular XML
element. Although XML, and hence WebDAV, does not use RFC 1766
language tags for its language names, the resource.
Schema: http://www.ietf.org/standards/dav/
Values: An benefit of using standard
XML document containing zero or more LockEntry in this context outweighs the advantage of using RFC 1766
language tags.
Names used within this specification fall into two categories: names
specific to protocol elements such as methods and headers, names of
XML
elements.
Description: The SupportedLock property elements, and names of a resource returns a
listing properties. Naming of protocol elements
follows the combinations precedent of scope and access types which may
be specified HTTP, using English names encoded in a lock request on the resource. Note that the
actual contents
USASCII for methods and headers. Since these protocol elements are themselves controlled by access controls so a
server is
not required visible to provide information users, and are in fact simply long token identifiers,
they do not need to support encoding in multiple character sets.
Similarly, though the client is names of XML elements used in this
specification are English names encoded in UTF-8, these names are
not
authorized visible to see. If SupportedLock is available on "*" then it
MUST define the user, and hence do not need to support multiple
character set encodings.
The name of locks allowed on all resources on that
server.
5.6.1.3 LOCKENTRY XML Element
Name: http://www.ietf.org/standards/dav/lockentry
Purpose: Defines a DAVLockType/LockScope pair which may be
legally used with a LOCK property defined on the specified resource.
Schema: http://www.ietf.org/standards/dav/
Parent: A SupportedLock entry
Values: LockType LockScope
5.6.1.4 LOCKTYPE XML Element
Name: http://www.ietf.org/standards/dav/locktype
Purpose: Lists a DAVLockType
Schema: http://www.ietf.org/standards/dav/
Parent: LOCKENTRY
Values: DAVLockTypeValue
5.6.1.5 LOCKSCOPE XML Element
Name: http://www.ietf.org/standards/dav/lockscope
Purpose: Lists a DAVLockScope
Schema: http://www.ietf.org/standards/dav/
Parent: LOCKENTRY
Values: DAVLockScopeValue
5.6.1.6 Example
PROPFIND /container/ HTTP/1.1
Host: www.foo.bar
Content-Length: xxxx
Content-Type: text/xml
<?XML:Namespace href =
"http://www.ietf.org/standards/dav/" AS = "D"/>
<D:PROPFIND>
<prop><SupportedLock/></prop>
</D:PROPFIND>
HTTP/1.1 207 Multi-Response
Content-Type: text/xml
Content-Length: xxxxx
<?XML:Namespace
href ="http://www.ietf.org/standards/dav/" AS = "D"/>
<D:MultiResponse>
<Response>
<Prop>
<SupportedLock>
<LockEntry>
<LockType>Write</LockType>
<LockScope>Exclusive</LockScope>
</LockEntry>
<LockEntry>
<LockType>Write</LockType>
<LockScope>Shared</LockScope>
</LockEntry>
</SupportedLock>
</Prop>
<Status>HTTP/1.1 200 Success</Status>
</Response>
</D:MultiResponse>
5.6.2 Active Lock Discovery
5.6.2.1 Problem Definition
If another principal locks a resource that is a principal wishes URI. Although
some applications (e.g., a generic property viewer) will display
property URIs directly to
access, their users, it is useful for the second principal to be able to find
out who expected that the first principal is.
5.6.2.2 Solution Requirements
The lock discovery mechanism should provide
typical application will use a list fixed set of who has the
resource locked, what locks they have, properties, and what their lock tokens
are. The lock tokens are useful 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 shared lock situations
the case where
two principals may want to guarantee that they do the set of properties is not overwrite
each other. The lock tokens are also useful for administrative
purposes so known ahead of time that
an administrator can remove a lock by referring
to its token.
5.6.2.3 LOCKDISCOVERY Property
Name: http://www.ietf.org/standards/dav/lockdiscovery
Purpose: To discover what locks are active on a resource
Schema: http://www.ietf.org/standards/dav/
Values= An XML document containing zero or more ActiveLock XML
elements.
Description: The LOCKDISCOVERY application need display a property returns name URI to a listing user. We
recommend that applications provide human-readable property names
wherever feasible.
For error reporting, we follow the convention of who
has HTTP/1.1 status
codes, including with each status code a lock, what type short, English description
of lock they have, the time out type and the time remaining on code (e.g., 421 Destination Locked). While the time out, 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 associated lock
token. The server is free to withhold any or all user's language and
character set.
Since interoperation of clients and servers does not require locale
information, this
information if the requesting principal specification does not have sufficient
access rights to see the requested data. A server which supports
locks MUST provide the LOCKDISCOVERY property on specify any resource
with locks on it.
5.6.2.4 ACTIVELOCK XML Element
Name: http://www.ietf.org/standards/dav/activelock
Purpose: mechanism for
transmission of this information.
16. Security Considerations
[TBD]
17. Terminology
Collection - A multivalued XML element resource that describes contains member resources.
Member Resource - A resource contained by a particular
active lock on collection. There are
two types of member resources: external and internal.
Internal Member Resource _ A member resource of a collection whose
URI is relative to the URI of the collection.
External Member Resource - A member resource
Schema: http://www.ietf.org/standards/dav/
Parent: of a collection with an
absolute URI that is not relative to its parent's URI.
Property - A LOCKDISCOVERY entry
Values= LOCKTYPE LOCKSCOPE [ADDLOCKS] OWNER TIMEOUT LOCKTOKEN
5.6.2.5 OWNER XML Element
Name: http://www.ietf.org/standards/dav/lock/owner
Purpose: Returns owner information
Schema: http://www.ietf.org/standards/dav/
Parent: ACTIVELOCK
Values= XML:REF | {any valid XML string}
5.6.2.6 TIMEOUT XML Element
Name: http://www.ietf.org/standards/dav/timeout
Purpose: Returns name/value pair that contains descriptive information
about a resource.
Live Property _ A property whose semantics and syntax are enforced
by the server. For example, a live "content-length" property would
have its value, the timeout associated with length of the lock
Schema: http://www.ietf.org/standards/dav/
Parent: ACTIVELOCK
Values= TimeType
5.6.2.7 ADDLOCKS XML Element
Name: http://www.ietf.org/standards/dav/addlocks
Purpose: Lists additional resources associated with this lock, if
any.
Schema: http://www.ietf.org/standards/dav/
Parent: ACTIVELOCK
Values= 1*HREF
5.6.2.8 LOCKTOKEN XML Element
Name: http://www.ietf.org/standards/dav/statetoken
Purpose: Returns entity returned by a GET request,
automatically calculated by the lock token
Schema: http://www.ietf.org/standards/dav/
Parent: ACTIVELOCK
Values= HREF
Description: server.
Dead Property _ A property whose semantics and syntax are not
enforced by the server. The HREF contains a Lock-Token-URL.
5.6.2.9 Example
PROPFIND /container/ HTTP/1.1
Host: www.foo.bar
Content-Length: xxxx
Content-Type: text/xml
<?XML:Namespace href =
"http://www.ietf.org/standards/dav/" AS = "D"/>
<D:PROPFIND>
<prop><lockdiscovery/></prop>
</D:PROPFIND>
HTTP/1.1 207 Multi-Response
Content-Type: text/xml
Content-Length: xxxxx
<?XML:Namespace
href ="http://www.ietf.org/standards/dav/" AS = "D"/>
<D:MultiResponse>
<Response>
<Prop>
<lockdiscovery>
<activelock>
<locktype>write</locktype>
<lockscope>exclusive</lockscope>
<addlocks>
<HREF>http://foo.com/doc/</HREF>
</addlocks>
<owner>Jane Smith</owner>
<timeout>Infinite</timeout>
<locktoken>
<HREF>iamuri:unique!!!!!</HREF>
</locktoken>
</activelock>
</lockdiscovery>
</Prop>
<Status>HTTP/1.1 200 Success</Status>
</Response>
</D:MultiResponse>
This resource has server only records the value of a single exclusive write lock on it, with an
infinite time out. This same lock also covers dead
property; the resource
http://foo.com/doc/.
6 Version Control
[TBD]
7 Internationalization Support
[TBD]
8 Security Considerations
[TBD]
9 client is responsible for maintaining the consistency
of the syntax and semantics of a dead property.
18. Copyright
The following copyright notice is copied from RFC 2026 chapter 10.4,
and describes the applicable copyright for this document
Copyright (C) The Internet Society October 13, November 19, 1997. 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 assignees.
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.
10
19. 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, Alan Babich, Dylan Barrell, Bernard
Chester, Tim Berners-Lee, Dan Connolly, Jim Cunningham, Ron Daniel,
Jr., Jim Davis, Keith Dawson, Mark Day, Martin Duerst, David Durand,
Lee Farrell, Chuck Fay, Roy Fielding, Mark Fisher, Alan Freier,
George Florentine, Jim Gettys, Phill Hallam-Baker, Dennis Hamilton,
Steve Henning, Alex Hopmann, Andre van der Hoek, Ben Laurie, Paul
Leach, Ora Lassila, Karen MacArthur, Steven Martin, Larry Masinter,
Michael Mealling, Keith Moore, Henrik Nielsen, Kenji Ota, Bob
Parker, Glenn Peterson, Jon Radoff, Saveen Reddy, Henry Sanders,
Christopher Seiwald, Judith Slein, Mike Spreitzer, Einar Stefferud,
Ralph Swick, Kenji Takahashi, Richard N. Taylor, Robert Thau, John
Turner, Sankar Virdhagriswaran, Fabio Vitali, Gregory Woodhouse, and
Lauren Wood
11 Wood.
One from this list deserves 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.
20. References
[Alvestrand, 1997] H. T. Alvestrand, "IETF Policy on Character Sets
and Languages." Internet-draft, work-in-progress.
ftp://ds.internic.net/internet-drafts/draft-alvestrand-charset-
policy-02.txt
[Berners-Lee, 1997] T. Berners-Lee, "Metadata Architecture."
Unpublished white paper, January 1997.
http://www.w3.org/pub/WWW/DesignIssues/Metadata.html.
[Bradner, 1997] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels." RFC 2119, BCP 14. Harvard University. March,
1997.
[Bray, Sperberg-McQueen, 1997] T. Bray, C. M. Sperberg-McQueen,
"Extensible Markup Language (XML): Part I. Syntax", WD-xml-
lang.html, http://www.w3.org/pub/WWW/TR/WD-xml-lang.html.
[Connolly et al, 1997] D. Connolly, R. Khare, H.F. Nielsen, "PEP
- an Extension Mechanism for HTTP", Internet draft, work-in-
progress. draft-ietf-http-pep-04.txt,
ftp://ds.internic.net/internet-drafts/draft-ietf-http-pep-04.txt.
[Fielding et al., 1997] R. Fielding, J. Gettys, J. Mogul, H.
Frystyk, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1."
RFC 2068. U.C. Irvine, DEC, MIT/LCS. January, 1997.
ftp://ds.internic.net/rfc/rfc2068.txt
[Lasher, Cohen, 1995] R. Lasher, D. Cohen, "A Format for
Bibliographic Records," RFC 1807. Stanford, Myricom. June, 1995.
ftp://ds.internic.net/rfc/rfc1807.txt
[Leach, Salz, 1997] P. J. Leach, R. Salz, "UUIDs and GUIDs."
Internet-draft (expired), work-in-progress, February, 1997.
http://www.internic.net/internet-drafts/draft-leach-uuids-guids-
00.txt
[Maloney, 1996] M. Maloney, "Hypertext Links in HTML." Internet
draft (expired), work-in-progress, January, 1996.
[MARC, 1994] Network Development and MARC Standards, Office, ed.
1994. "USMARC Format for Bibliographic Data", 1994. Washington, DC:
Cataloging Distribution Service, Library of Congress.
[Miller et al., 1996] J. Miller, T. Krauskopf, P. Resnick, W.
Treese, "PICS Label Distribution Label Syntax and Communication
Protocols" Version 1.1, W3C Recommendation REC-PICS-labels-
961031. REC-PICS-labels-961031.
http://www.w3.org/pub/WWW/TR/REC-PICS-labels-961031.html.
[Slein et al., 1997] J. A. Slein, F. Vitali, E. J. Whitehead, Jr.,
D. Durand, "Requirements for Distributed Authoring and Versioning on
Protocol for the World Wide Web." Internet-draft, work-in-
progress, draft-ietf-webdav-requirements-04.txt,
ftp://ds.internic.net/internet-drafts/draft-ietf-webdav-
requirements-04.txt. RFC XXXX. Xerox, Univ. of Bologna,
U.C. Irvine, Boston Univ. YYY, 1997.
ftp://ds.internic.net/rfc/rfcXXXX.txt
[WebDAV, 1997] WEBDAV Design Team. "A Proposal for Web Metadata
Operations." Unpublished manuscript.
http://www.ics.uci.edu/~ejw/authoring/proposals/metadata.html
[Weibel et al., 1995] S. Weibel, J. Godby, E. Miller, R. Daniel,
"OCLC/NCSA Metadata Workshop Report."
http://purl.oclc.org/metadata/dublin_core_report.
[Yergeau, 1997] F. Yergeau, "UTF-8, a transformation format of
Unicode and ISO 10646", Internet Draft, work-in-progress, draft-
yergeau-utf8-rev-00.txt, http://www.internic.net/internet-
drafts/draft-yergeau-utf8-rev-00.txt.
12
21. Authors' Addresses
Y. Y. Goland
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
Email
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
A. Faizi
Netscape
685 East Middlefield Road
Mountain View, CA 94043
Email: asad@netscape.com
S. R R. Carter
Novell
1555 N. Technology Way
M/S ORM F111
Orem, UT 84097-2399
Email
Email: srcarter@novell.com
D. Jensen
Novell
1555 N. Technology Way
M/S ORM F111
Orem, UT 84097-2399
Email
Email: dcjensen@novell.com