MKCOL was created as a separate method rather than using PUT or POST because: PUT with a collection description could be misinterpreted as deleting omitted members (conflating PUT with DELETE semantics), and POST is too open-ended to support fine-grained access control on collection creation.

http

Shared locks were included alongside exclusive locks because experience with web distributed authoring systems showed exclusive locks are often too rigid. Exclusive locks can become orphaned (program crash, owner leaves), blocking all access, whereas shared locks let collaborators signal intent without fully blocking each other.

http

WebDAV intentionally cannot prevent the 'lost update' problem entirely because it cannot force HTTP 1.0/1.1 clients (which do not understand locking) to use locking, cannot require all servers to support locking (some use reservations/merging), and being stateless cannot enforce the LOCK/GET/PUT/UNLOCK sequence.

http

XML was chosen for encoding WebDAV method parameters because it supports rich schema definitions, multiple character sets, and is self-describing — allowing older clients to ignore unknown extensions without breaking. Parameters with unbounded length or human-readable content go in XML bodies; short machine-readable parameters go in HTTP headers.

http

DAV compliance is divided into two classes: Class 1 requires all HTTP/1.1 methods plus PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK (optional), and UNLOCK (optional), plus the DAV header, new status codes, and the multistatus response. Class 2 requires Class 1 plus mandatory LOCK/UNLOCK support and the supportedlock property.

http

Non-DAV-compliant HTTP proxies may strip or mishandle the If header, silently discarding lock tokens submitted by clients. Clients SHOULD be aware that If header semantics are DAV-specific and may not survive traversal through non-DAV-aware intermediaries.

http

A COPY method invocation MUST NOT duplicate any write locks active on the source. A successful MOVE request on a write locked resource MUST NOT move the write lock with the resource.

http

A lock-null resource MUST respond with a 404 (Not Found) or 405 (Method Not Allowed) to any HTTP/1.1 or DAV methods except PUT, MKCOL, OPTIONS, PROPFIND, LOCK, and UNLOCK. A lock-null resource MUST appear as a member of its parent collection and MUST have lockdiscovery and supportedlock properties defined.

http

A lock token MUST be submitted by an authorized principal in the If header for all locked resources that a method may interact with, or the method MUST fail. For example, a MOVE where both source and destination are locked requires two lock tokens.

http

A write lock MUST prevent a principal without the lock from successfully executing a PUT, POST, PROPPATCH, LOCK, UNLOCK, MOVE, DELETE, or MKCOL on the locked resource. All other current methods, GET in particular, function independently of the lock.

http, security

All DAV compliant clients and resources MUST use XML parsers compliant with REC-XML. If a server receives ill-formed XML in a request it MUST reject the entire request with a 400 (Bad Request). If a client receives ill-formed XML in a response it MUST NOT assume anything about the outcome.

http

All DAV compliant resources MUST support the PROPFIND method. PROPFIND without a Depth header MUST act as if 'Depth: infinity' was included. DAV compliant servers MUST support 'Depth: 0', '1', and 'infinity' behaviors.

http

All resources MUST recognize the opaquelocktoken scheme and, at minimum, recognize that the lock token does not refer to an outstanding lock on the resource. Any DAV compliant resource that supports LOCK MUST support both the supportedlock and lockdiscovery properties.

http

Lock token URIs MUST be unique across all resources for all time. Locks MUST be enforced based upon whatever authentication mechanism is used by the server, not based on the secrecy of the token values.

http, security

MKCOL MUST fail if the resource identified by the Request-URI is non-null. All ancestors MUST already exist, or the method MUST fail with a 409 (Conflict) status code. During MKCOL processing, a server MUST make the Request-URI a member of its parent collection.

http

PROPPATCH instructions MUST either all be executed or none executed (atomic). If any error occurs during processing, all executed instructions MUST be undone and a proper error result returned. Instructions MUST be processed in the order received.

http

The DELETE method on a collection MUST act as if a 'Depth: infinity' header was used. A client MUST NOT submit a Depth header with a DELETE on a collection with any value but infinity. If any resource identified by a member URI cannot be deleted, all of that member's ancestors MUST NOT be deleted.

http

Properties on resources may expose sensitive metadata about authorship, creation dates, and modification history. The DAV:source link property can reveal URIs of server-side source files (e.g., CGI scripts or server-side includes) that administrators intended to keep hidden.

http, privacy

COPY and MOVE are new HTTP methods for duplicating and relocating resources. Both require a Destination header and support an Overwrite header (T/F). They return 207 Multi-Status if partial errors occur within collections.

http

LOCK and UNLOCK are new HTTP methods for acquiring and releasing write locks. A successful LOCK returns the lock token in the lockdiscovery property in the response body. Locks may be exclusive or shared and may apply with Depth 0 or infinity on collections.

http

MKCOL is a new HTTP method for creating collection resources (analogous to directory creation). It returns 201 on success, 405 if the resource already exists, 409 if intermediate collections are missing, and 507 if storage is insufficient.

http

New HTTP status codes defined: 102 Processing (interim response for long-running operations), 207 Multi-Status (status for multiple resources), 422 Unprocessable Entity (semantically erroneous XML), 423 Locked (resource is locked), 424 Failed Dependency (action failed due to a dependency), 507 Insufficient Storage.

http

PROPFIND is a new HTTP method that retrieves properties on resources, optionally traversing collections to a specified depth (0, 1, or infinity). It accepts an XML propfind body specifying which properties to retrieve (named, allprop, or propname) and returns a 207 Multi-Status XML response.

http

PROPPATCH is a new HTTP method that sets and/or removes properties defined on the resource identified by the Request-URI using a propertyupdate XML element in the request body. It returns a 207 Multi-Status response and executes instructions atomically.

http

The DAV response header advertises server compliance level. A value of '1' indicates Class 1 compliance (all DAV methods except LOCK/UNLOCK); a value of '2' indicates Class 2 compliance (adds locking support). Resources that are collections but not DAV compliant MUST NOT return DAV: 1.

http

The Depth header takes values '0', '1', or 'infinity' and controls the depth of recursive operations on collection hierarchies. It is used with PROPFIND, COPY, LOCK, and DELETE methods.

http

The If request header carries lock tokens and optionally ETags as preconditions. It uses no-tag-list and tagged-list productions, where tagged-lists associate conditions with specific resource URIs. If conditions are not met, the server MUST return 412 (Precondition Failed).

http

The lockdiscovery DAV property lists all outstanding locks on a resource, including lock type (exclusive/shared), scope, depth, owner, timeout, and lock token. The supportedlock property advertises which lock types and scopes the resource supports.

http

Lock tokens provide no special access rights — anyone can discover another's lock token via lock discovery. Locks MUST be enforced based on the server's authentication mechanism, not on token secrecy. Servers should require authentication before allowing any write operation.

http, security

The opaquelocktoken UUID node field traditionally uses the IEEE 802 address, which exposes the server machine's MAC address. An alternative algorithm using a 47-bit cryptographic random number with the multicast bit set is provided to avoid this exposure.

http, security

XML external entity references in DAV request bodies can be used for denial of service attacks or to read local files on the server (e.g., /etc/passwd via file:// URIs). Servers MUST carefully handle or disallow XML external entity processing.

http, security

A null resource transitions to 'lock-null' state when a write lock is successfully asserted on it. From lock-null, it transitions to a real resource when PUT or MKCOL succeeds on it. If unlocked without a successful PUT or MKCOL, it MUST return to null state and cease to be a member of its parent collection.

http

The 207 Multi-Status response uses a multistatus XML element (DAV: namespace) containing one or more response elements, each with an href element and one or more propstat or status elements. Property values MUST be expressed as well-formed XML.

http

The opaquelocktoken URI scheme uses the format 'opaquelocktoken:UUID[Extension]' where UUID is the ISO 11578 string representation of a UUID. No whitespace (LWS) is allowed between production elements. Extension is an optional path segment as defined in RFC 2068 section 3.2.1.

http