Shared locks were included because exclusive locks proved too rigid in practice: they are frequently not released when programs crash or users disconnect, and neither timeouts nor administrators may be available to remove them in time.

http

Write locks cannot fully prevent lost updates because WebDAV must remain compatible with HTTP/1.1 clients that do not understand locking, and because not all repository implementations support locking; ETags with If-Match are the recommended complement for HTTP-only clients.

http

XML was chosen for property values and method marshalling because it is self-describing, extensible (clients MUST ignore unknown elements), and supports ISO 10646 character sets and xml:lang for internationalization — advantages that HTTP headers cannot provide at scale.

http

Both text/xml and application/xml content types MUST be accepted in request and response bodies, though application/xml is preferred and text/xml is deprecated. This ensures compatibility with older RFC 2518 implementations.

http

For backwards compatibility with RFC 2518, servers MAY implement Lock-Null Resources (LNRs) instead of the recommended locked-empty-resource model. Clients can interoperate with both by only attempting PUT (not MKCOL or GET) after locking an unmapped URL.

http

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

http

A server receiving a LOCK request with no body MUST NOT create a new lock; a bodyless LOCK is only valid as a refresh of an existing lock, and any timers associated with the lock MUST be reset.

http

A successful LOCK request to an unmapped URL MUST result in the creation of a locked non-collection resource with empty content. The server MUST respond with 201 Created and include the DAV:lockdiscovery property in the body.

http

All DAV-compliant clients and resources MUST use XML parsers compliant with REC-XML and REC-XML-NAMES. All XML used in requests or responses MUST be at minimum well-formed and use namespaces correctly.

http

All DAV-compliant resources MUST support the PROPFIND method and the propfind XML element along with all XML elements defined for use with that element. Servers MUST support Depth '0' and '1' requests and SHOULD support 'infinity' requests.

http, routing

Any DAV-compliant resource that supports the LOCK method MUST support both the DAV:supportedlock property (for lock capability discovery) and the DAV:lockdiscovery property (for active lock discovery).

http

Clients MUST submit a lock token they are authorized to use in any request that modifies a write-locked resource, or the method MUST fail. The lock token is submitted via the If header.

http, security

If a server receives XML that is not well-formed it MUST reject the entire request with a 400 Bad Request. If a depth-infinity write LOCK request encounters a conflicting lock, the request MUST fail with 423 Locked.

http, security

Lock token URIs MUST be unique across all resources for all time. This uniqueness constraint allows lock tokens to be submitted across resources and servers without fear of confusion.

http, security

Servers MUST examine all requests for a body even when a body was not expected; if a request body is present but would be ignored, the server MUST reject the request with 415 Unsupported Media Type.

http

Servers MUST preserve specific XML Information Items in storage and transmission of dead properties, including namespace name, local name, attributes, and element/character children. Servers MUST ignore the xml:space attribute if present.

http, json

Servers MUST return authorization errors in preference to other errors. This avoids leaking information about protected resources (e.g., a client finding a hidden resource exists by seeing a 423 Locked response).

http, security

Lock tokens MAY be made publicly readable in DAV:lockdiscovery, revealing who locked a resource. Similarly, properties can expose sensitive metadata; servers should allow access control on property visibility.

http, privacy

DAV Compliance Classes define server capability levels. Class 1 requires full HTTP/1.1 and WebDAV method support. Class 2 adds locking support. Class 3 (new in RFC 4918) revises requirements relative to RFC 2518.

http

Lock timeout is server-chosen despite client suggestions via the Timeout request header. Clients MUST NOT assume a lock is gone when timeout expires, nor that it still exists before expiry. Servers SHOULD remove expired locks as if UNLOCK had been called.

http

The Depth header controls the scope of operations on collections: '0' applies only to the collection itself, '1' applies to the collection and its direct members, and 'infinity' applies recursively to all descendants.

http

The If request header is used for conditional operations and lock token submission. It supports tagged-list and no-tag-list forms, evaluating lists of state tokens and ETags. A lock token must appear in an If header to be considered 'submitted'.

http

The WebDAV lock model defines direct and indirect locking. An exclusive lock conflicts with any other lock on the same resource. A depth-infinity lock on a collection indirectly locks all member resources, and membership changes dynamically adjust the indirectly locked set.

http

The write lock is the only lock type defined in this specification. It protects changes to resource variants, dead properties, lockable live properties, collection internal member URIs, and the lock-root mapping. Methods affected include PUT, POST, PROPPATCH, LOCK, UNLOCK, MOVE, COPY (destination), DELETE, and MKCOL.

http

WebDAV defines two lock scopes: exclusive (prevents all other locks) and shared (multiple principals may hold simultaneous locks). A successful shared lock request MUST result in a unique lock and lock token per requesting principal.

http

RFC 4918 registers five new HTTP status codes: 207 Multi-Status, 422 Unprocessable Entity, 423 Locked, 424 Failed Dependency, and 507 Insufficient Storage.

http, registry

RFC 4918 registers seven HTTP header field names: DAV, Depth, Destination, If, Lock-Token, Overwrite, and Timeout in the Permanent Message Header Field Names registry.

http, registry

Locks represent a denial-of-service risk: a principal could lock all resources on a server and prevent others from working. Servers should impose limits on lock counts, depths, and timeouts.

http, security

Processing XML from untrusted sources creates risks: XML entity expansion attacks can cause denial of service. Servers MAY reject questionable well-formed XML requests, e.g., those with excessive entity references, with 400 Bad Request.

http, security

Write access and other privileges MUST be enforced through normal authentication mechanisms, not based on lock token obscurity. Having a lock does not confer full privilege; authentication checks MUST precede conditional header checks.

http, security

Lock lifecycle: (1) Created — LOCK request to mapped or unmapped URL generates a new lock with unique token; (2) Active — lock token must be submitted in If header to modify locked resources; (3) Refreshed — LOCK with If header and no body resets timer; (4) Terminated — UNLOCK request or timeout expiry or deletion of lock-root removes the lock.

http

The activelock XML element appears inside DAV:lockdiscovery and contains locktype, lockscope, depth, owner, timeout, locktoken (with href), and lockroot child elements describing a currently held lock.

http

The DAV response header advertises server compliance class using a comma-separated list of URIs or tokens (e.g., '1, 2, 3'). Class 1 is indicated by '1', class 2 by '2', and class 3 by '3'.

http

The lockinfo XML element is the request body for a LOCK request and contains lockscope (exclusive or shared), locktype (write), and owner (arbitrary XML identifying the lock principal) child elements.

http

The multistatus XML element (DAV: namespace) wraps 207 Multi-Status responses. Each response child contains an href element (resource URL), zero or more propstat elements (each with a prop and status), and an optional responsedescription. All href values within one Multi-Status MUST use the same format (absolute URI or absolute path).

http