Table of contents
DAV = "DAV" ":" #( compliance-class ) compliance-class = ( "1" | "2" | "3" | extend ) extend = Coded-URL | token ; token is defined in RFC 2616, Section 2.2 Coded-URL = "<" absolute-URI ">" ; No linear whitespace (LWS) allowed in Coded-URL ; absolute-URI defined in RFC 3986, Section 4.3
This general-header appearing in the response indicates that the resource supports the DAV schema and protocol as specified. All DAV-compliant resources MUST return the DAV header with compliance-class "1" on all OPTIONS responses. In cases where WebDAV is only supported in part of the server namespace, an OPTIONS request to non-WebDAV resources (including "/") SHOULD NOT advertise WebDAV support.
The value is a comma-separated list of all compliance class identifiers that the resource supports. Class identifiers may be Coded-URLs or tokens (as defined by [RFC2616]). Identifiers can appear in any order. Identifiers that are standardized through the IETF RFC process are tokens, but other identifiers SHOULD be Coded-URLs to encourage uniqueness.
A resource must show class 1 compliance if it shows class 2 or 3 compliance. In general, support for one compliance class does not entail support for any other, and in particular, support for compliance class 3 does not require support for compliance class 2. Please refer to Section 18 for more details on compliance classes defined in this specification.
Note that many WebDAV servers do not advertise WebDAV support in response to "OPTIONS *".
As a request header, this header allows the client to advertise compliance with named features when the server needs that information. Clients SHOULD NOT send this header unless a standards track specification requires it. Any extension that makes use of this as a request header will need to carefully consider caching implications.