[MS-WDVME]: Web Distributed Authoring and Versioning (Webdav) Protocol: Microsoft Extensions

[MS-WDVME]: Web Distributed Authoring and Versioning (WebDAV) Protocol: Microsoft Extensions

Intellectual Property Rights Notice for Open Specifications Documentation

. Technical Documentation. Microsoft publishes Open Specifications documentation for protocols, file formats, languages, standards as well as overviews of the interaction among each of these technologies. . Copyrights. This documentation is covered by Microsoft copyrights. Regardless of any other terms that are contained in the terms of use for the Microsoft website that hosts this documentation, you may make copies of it in order to develop implementations of the technologies described in the Open Specifications and may distribute portions of it in your implementations using these technologies or your documentation as necessary to properly document the implementation. You may also distribute in your implementation, with or without modification, any schema, IDL's, or code samples that are included in the documentation. This permission also applies to any documents that are referenced in the Open Specifications. . No Trade Secrets. Microsoft does not claim any trade secret rights in this documentation.

. Patents. Microsoft has patents that may cover your implementations of the technologies described in the Open Specifications. Neither this notice nor Microsoft's delivery of the documentation grants any licenses under those or any other Microsoft patents. However, a given Open Specification may be covered by Microsoft Open Specification Promise or the Community Promise. If you would prefer a written license, or if the technologies described in the Open Specifications are not covered by the Open Specifications Promise or Community Promise, as applicable, patent licenses are available by contacting [email protected]. . Trademarks. The names of companies and products contained in this documentation may be covered by trademarks or similar intellectual property rights. This notice does not grant any licenses under those rights. For a list of Microsoft trademarks, visit www.microsoft.com/trademarks. . Fictitious Names. The example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted in this documentation are fictitious. No association with any real company, organization, product, domain name, email address, logo, person, place, or event is intended or should be inferred. Reservation of Rights. All other rights are reserved, and this notice does not grant any rights other than specifically described above, whether by implication, estoppel, or otherwise.

Tools. The Open Specifications do not require the use of Microsoft programming tools or programming environments in order for you to develop an implementation. If you have access to Microsoft programming tools and environments you are free to take advantage of them. Certain Open Specifications are intended for use in conjunction with publicly available standard specifications and network programming art, and assumes that the reader either is familiar with the aforementioned material or has immediate access to it.

Preliminary Documentation. This Open Specification provides documentation for past and current releases and/or for the pre-release version of this technology. This Open Specification is final documentation for past or current releases as specifically noted in the document, as applicable; it is preliminary documentation for the pre-release versions. Microsoft will release final documentation in connection with the commercial release of the updated or new version of this technology. As the documentation may change between this preliminary version and the final version of this technology,

1 / 32 [MS-WDVME] - v20150824 Web Distributed Authoring and Versioning (WebDAV) Protocol: Microsoft Extensions Copyright © 2015 Microsoft Corporation Release: August 24, 2015 there are risks in relying on preliminary documentation. To the extent that you incur additional development obligations or any other costs as a result of relying on this preliminary documentation, you do so at your own risk.

Revision Summary

Revision Revision Date History Class Comments

10/8/2010 1.0 New Released new document.

11/19/2010 2.0 Major Significantly changed the technical content.

1/7/2011 2.0 No change No changes to the meaning, language, or formatting of the technical content.

2/11/2011 2.0 No change No changes to the meaning, language, or formatting of the technical content.

3/25/2011 2.0 No change No changes to the meaning, language, or formatting of the technical content.

5/6/2011 2.0 No change No changes to the meaning, language, or formatting of the technical content.

6/17/2011 2.1 Minor Clarified the meaning of the technical content.

9/23/2011 3.0 Major Significantly changed the technical content.

12/16/2011 4.0 Major Significantly changed the technical content.

3/30/2012 4.0 No change No changes to the meaning, language, or formatting of the technical content.

7/12/2012 4.0 No change No changes to the meaning, language, or formatting of the technical content.

9/12/2012 4.0 No Change No changes to the meaning, language, or formatting of the technical content.

10/8/2012 4.0 No Change No changes to the meaning, language, or formatting of the technical content.

2/11/2013 4.0 No Change No changes to the meaning, language, or formatting of the technical content.

7/30/2013 4.1 Minor Clarified the meaning of the technical content.

11/18/2013 4.1 No Change No changes to the meaning, language, or formatting of the technical content.

2/10/2014 4.2 Minor Clarified the meaning of the technical content.

4/30/2014 4.3 Minor Clarified the meaning of the technical content.

7/31/2014 4.4 Minor Clarified the meaning of the technical content.

8/24/2015 5.0 Major Significantly changed the technical content.

Table of Contents 1 Introduction ...... 6 1.1 Glossary ...... 6 1.2 References ...... 7 1.2.1 Normative References ...... 7 1.2.2 Informative References ...... 8 1.3 Overview ...... 8 1.4 Relationship to Other Protocols ...... 9 1.5 Prerequisites/Preconditions ...... 9 1.6 Applicability Statement ...... 9 1.7 Versioning and Capability Negotiation ...... 9 1.8 Vendor-Extensible Fields ...... 9 1.9 Standards Assignments ...... 9 2 Messages ...... 10 2.1 Transport ...... 10 2.2 Message Syntax ...... 10 2.2.1 Document Management Server Header ...... 10 2.2.2 MS-Doclib Header ...... 10 2.2.3 Repl-uid Header ...... 11 2.2.4 ResourceTag Header ...... 11 2.2.5 GETLIB Method ...... 11 2.2.6 Translate Header ...... 11 2.2.7 MS-Author-Via Header...... 11 2.2.8 User-Agent Header ...... 12 2.2.9 Extended DAV Properties ...... 12 2.2.9.1 DAV:iscollection Property ...... 12 2.2.9.2 DAV:isFolder Property ...... 12 2.2.9.3 DAV:ishidden Property ...... 12 2.2.10 Microsoft Extension Properties ...... 12 2.2.10.1 Repl:authoritative-directory Property ...... 12 2.2.10.2 Repl:resourcetag Property ...... 13 2.2.10.3 Repl:repl-uid Property ...... 13 2.2.10.4 Office:modifiedby Property ...... 13 2.2.10.5 Office:specialFolderType Property ...... 13 2.2.10.6 Z:Win32CreationTime Property ...... 13 2.2.10.7 Z:Win32FileAttributes Property ...... 13 2.2.10.8 Z:Win32LastAccessTime Property ...... 13 2.2.10.9 Z:Win32LastModifiedTime ...... 13 3 Protocol Details ...... 14 3.1 WebDAV Microsoft Extensions Client Details ...... 14 3.1.1 Abstract Data Model ...... 14 3.1.2 Timers ...... 14 3.1.3 Initialization ...... 14 3.1.4 Higher-Layer Triggered Events ...... 14 3.1.5 Processing Events and Sequencing Rules ...... 14 3.1.5.1 Extensions to OPTIONS ...... 14 3.1.5.2 GETLIB Method ...... 14 3.1.5.3 PROPFIND Extensions ...... 15 3.1.5.3.1 PROPFIND as an Alternative to GETLIB ...... 15 3.1.5.4 Write Lock Limitations ...... 15 3.1.5.5 If Header Modification ...... 15 3.1.5.6 Client Properties ...... 16 3.1.6 Timer Events ...... 16 3.1.7 Other Local Events ...... 16

3.2 WebDAV Microsoft Extensions Server Details ...... 16 3.2.1 Abstract Data Model ...... 16 3.2.2 Timers ...... 16 3.2.3 Initialization ...... 16 3.2.4 Higher-Layer Triggered Events ...... 16 3.2.5 Processing Events and Sequencing Rules ...... 17 3.2.5.1 Extensions to OPTIONS ...... 17 3.2.5.2 GETLIB Method ...... 17 3.2.5.3 PROPFIND Extensions ...... 18 3.2.5.3.1 PROPFIND and Depth:0 ...... 18 3.2.5.3.2 PROPFIND as an Alternative to GETLIB ...... 18 3.2.5.3.3 PROPFIND Lock Properties ...... 18 3.2.5.4 Write Lock Limitations ...... 18 3.2.5.5 If Header Modification ...... 18 3.2.5.6 Server Properties ...... 18 3.2.6 Timer Events ...... 19 3.2.7 Other Local Events ...... 19 4 Protocol Examples ...... 20 4.1 OPTIONS Verb ...... 20 4.1.1 Client OPTIONS Request ...... 20 4.1.2 FrontPage Server Extension-Compliant Server Response ...... 20 4.2 GETLIB Verb and PROPFIND Extension for Document Library Support ...... 20 4.2.1 Client Request ...... 20 4.2.2 Server Response ...... 21 4.2.3 Client Request Using PROPFIND ...... 21 4.3 If Header Usage ...... 21 4.3.1 Client GET Request ...... 21 4.3.2 GET Request: Server Response ...... 22 4.3.3 Client PUT Request with If Header ...... 22 4.3.4 Server Response to PUT ...... 22 4.3.5 Client PUT Request with If Header with Incorrect ResourceTag ...... 22 4.3.6 Server PUT Response to Incorrect ResourceTag in If Header ...... 23 5 Security ...... 24 5.1 Security Considerations for Implementers ...... 24 5.2 Index of Security Parameters ...... 24 6 Appendix A: Product Behavior ...... 25 7 Change Tracking ...... 29 8 Index ...... 31

1 Introduction

The Web Distributed Authoring and Versioning Protocol (WebDAV), as specified in [RFC2518], extends the standard Hypertext Transfer Protocol (HTTP) mechanisms specified in [RFC2616] in order to provide file access and content management over the Internet. The WebDAV Protocol enables an Internet-based file system. However, some types of files—for example, files with programmatically derived content—are not easily managed by WebDAV. Also, some protocol interactions, such as the separation of properties and content, are less than optimal for file system usage.

This specification, Web Distributed Authoring and Versioning (WebDAV) Protocol: Microsoft Extensions, documents extensions to the WebDAV Protocol specified in [RFC2518]. Extensions include a new verb and new headers, and properties that enable previously unmanageable file types and optimize protocol interactions for file system clients. These extensions introduce new functionality into WebDAV, optimize processing, and eliminate the need for special-case processing.

Sections 1.8, 2, and 3 of this specification are normative and can contain the terms MAY, SHOULD, MUST, MUST NOT, and SHOULD NOT as defined in [RFC2119]. Sections 1.5 and 1.9 are also normative but do not contain those terms. All other sections and examples in this specification are informative.

1.1 Glossary

The following terms are specific to this document:

document library: A type of list that is a container for documents and folders.

forms authentication: An authentication (2) method in which protocol clients redirect unauthenticated requests to an HTML form by using HTTP. If the protocol client authenticates the request, the system issues a cookie that stores the credentials or a key for reacquiring the identity. In subsequent requests, the cookie is submitted in request headers and the requests are authenticated and authorized by an ASP.NET event handler that uses the validation method that is specified by the protocol client.

GUIDString: A GUID in the form of an ASCII or Unicode string, consisting of one group of 8 hexadecimal digits, followed by three groups of 4 hexadecimal digits each, followed by one group of 12 hexadecimal digits. It is the standard representation of a GUID, as described in [RFC4122] section 3. For example, "6B29FC40-CA47-1067-B31D-00DD010662DA". Unlike a curly braced GUID string, a GUIDString is not enclosed in braces.

Hypertext Transfer Protocol (HTTP): An application-level protocol for distributed, collaborative, hypermedia information systems (text, graphic images, sound, video, and other multimedia files) on the World Wide Web.

Hypertext Transfer Protocol Secure (HTTPS): An extension of HTTP that securely encrypts and decrypts web page requests. In some older protocols, “Hypertext Transfer Protocol over Secure Sockets Layer” is still used (Secure Sockets Layer has been deprecated). For more information, see [SSL3] and [RFC5246].

Integrated Windows authentication: A configuration setting that enables negotiation of authentication (2) protocols in Internet Information Services (IIS). Integrated Windows authentication is more secure than Basic authentication, because the user name and password are hashed instead of plaintext.

resource: Any component that a computer can access where data can be read, written, or processed. This resource could be an internal component such as a disk drive, or another computer on a network that is used to access a file.

Secure Sockets Layer (SSL): A security protocol that supports confidentiality and integrity of messages in client and server applications that communicate over open networks. SSL uses two keys to encrypt data-a public key known to everyone and a private or secret key known only to the recipient of the message. SSL supports server and, optionally, client authentication (2) using X.509 certificates (2). For more information, see [X509]. The SSL protocol is precursor to Transport Layer Security (TLS). The TLS version 1.0 specification is based on SSL version 3.0 [SSL3].

Transport Layer Security (TLS): A security protocol that supports confidentiality and integrity of messages in client and server applications communicating over open networks. TLS supports server and, optionally, client authentication by using X.509 certificates (as specified in [X509]). TLS is standardized in the IETF TLS working group. See [RFC4346].

Uniform Resource Identifier (URI): A string that identifies a resource. The URI is an addressing mechanism defined in Internet Engineering Task Force (IETF) Uniform Resource Identifier (URI): Generic Syntax [RFC3986].

Uniform Resource Locator (URL): A string of characters in a standardized format that identifies a document or resource on the World Wide Web. The format is as specified in [RFC1738].

Web Distributed Authoring and Versioning Protocol (WebDAV): The Web Distributed Authoring and Versioning Protocol, as described in [RFC2518] or [RFC4918].

WebDAV client: A computer that uses WebDAV, as described in [RFC2518] or [RFC4918], to retrieve data from a WebDAV server.

WebDAV server: A computer that supports WebDAV, as described in [RFC2518] or [RFC4918], and responds to requests from WebDAV clients.

MAY, SHOULD, MUST, SHOULD NOT, MUST NOT: These terms (in all caps) are used as defined in [RFC2119]. All statements of optional behavior use either MAY, SHOULD, or SHOULD NOT.

1.2 References

Links to a document in the Microsoft Open Specifications library point to the correct section in the most recently published version of the referenced document. However, because individual documents in the library are not updated at the same time, the section numbers in the documents may not match. You can confirm the correct section numbering by checking the Errata.

1.2.1 Normative References

We conduct frequent surveys of the normative references to assure their continued availability. If you have any issue with finding a normative reference, please contact [email protected]. We will assist you in finding the relevant information.

[MC-FPSEWM] Microsoft Corporation, "FrontPage Server Extensions: Website Management Protocol".

[MS-WDVSE] Microsoft Corporation, "Web Distributed Authoring and Versioning (WebDAV) Protocol: Server Extensions".

[MS-WDV] Microsoft Corporation, "Web Distributed Authoring and Versioning (WebDAV) Protocol: Client Extensions".

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, http://www.rfc-editor.org/rfc/rfc2119.txt

[RFC2246] Dierks, T., and Allen, C., "The TLS Protocol Version 1.0", RFC 2246, January 1999, http://www.rfc-editor.org/rfc/rfc2246.txt

[RFC2518] Goland, Y., Whitehead, E., Faizi, A., et al., "HTTP Extensions for Distributed Authoring - WebDAV", RFC 2518, February 1999, http://www.ietf.org/rfc/rfc2518.txt

[RFC2616] Fielding, R., Gettys, J., Mogul, J., et al., "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999, http://www.rfc-editor.org/rfc/rfc2616.txt

[RFC3986] Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005, http://www.ietf.org/rfc/rfc3986.txt

[RFC4122] Leach, P., Mealling, M., and Salz, R., "A Universally Unique Identifier (UUID) URN Namespace", RFC 4122, July 2005, http://www.ietf.org/rfc/rfc4122.txt

1.2.2 Informative References

[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000, http://www.rfc- editor.org/rfc/rfc2818.txt

1.3 Overview

The WebDAV Protocol allows data to be written to Internet servers and is an Internet standard for collaborative authoring, as described in [RFC2518]. WebDAV is a set of methods, headers, and content types that extend HTTP 1.1, as described in [RFC2616].

WebDAV expands the basic support in HTTP 1.1 for content authoring by introducing additional methods and headers that provide support for resource properties and other base functions, such as resource locking. These new capabilities make the WebDAV Protocol suitable for basic remotely mountable file systems.

The WebDAV Protocol: Microsoft Extensions specify the following extensions to the base WebDAV Protocol described in [MS-WDVSE]:

. A mechanism, based on WebDAV and HTTP, to indicate support for the extensions covered in this document. The extensions to the OPTIONS verb is described in section 3.1.5.1.

. A header to indicate whether the server supports various capabilities for document management through other protocols. The Document Management Server header is described in section 2.2.1.

. An extension method, GETLIB, that provides a way to determine the relative location of resource collections with specific properties implemented through other protocols. The GETLIB method is described in section 2.2.5.

. A header that extends the PROPFIND client request method, described in [RFC2518] section 8.1, to obtain the same information as the GETLIB extension method, and which is also used in a server response to either method to return the requested information. The MS-Doclib header is described in section 2.2.2.

. A header and property that return a value uniquely identifying a resource at a particular version, used to extend the handling of the If header. The ResourceTag: header and Repl:resourcetag property are described in sections 2.2.4 and 2.2.10.2.

. A header and property that return a uniquely identifying value associated with a resource. The Repl-uid: header and Repl:repl-uid property are described in sections 2.2.3 and 2.2.10.3.

. A User-Agent header used for customized responses to requests made by unauthenticated clients. The User-Agent header is described in section 2.2.8.

. A series of extension properties for Distributed Authoring and Versioning (DAV), described in section 2.2.9, and properties used for client property storage and interaction with other clients, described in section 2.2.10.

The WebDAV Protocol: Microsoft Extensions adopt the following extensions to the base WebDAV Protocol described in [MS-WDVSE]:

A header (Translate, section 2.2.6) indicating if an entity is to be returned as-is, or if any associated programmatic processing is performed and the result returned. The Translate header is described in [MS-WDVSE] section 2.2.1.

A header (MS-Author-Via, section 2.2.7) indicating which authoring tools are used. The MS-Author-Via Header is described in [MS-WDVSE] section 2.2.2.

1.4 Relationship to Other Protocols

The WebDAV Protocol: Microsoft Extensions is dependent on the WebDAV Protocol as described in [RFC2518]. WebDAV, in turn, relies on HTTP 1.1, as described in [RFC2616]. These extensions also rely on the HTTPS, as described in [RFC2818], for data protection services. The WebDAV Protocol: Microsoft Extensions also implement some of the WebDAV Protocol server extensions, as described in [MS-WDVSE].

1.5 Prerequisites/Preconditions

WebDAV Protocol: Microsoft Extensions require WebDAV clients that make use of these extensions to query for them through the OPTIONS command. Clients fall back to basic WebDAV client behavior, as described in [RFC2518], if the server does not advertise availability of the extensions in its OPTIONS command response.

1.6 Applicability Statement

The WebDAV Protocol: Microsoft Extensions apply in scenarios requiring efficient file operations. This document specifies only those extensions needed to enable efficient file system clients. These extensions do not add any functionality. Instead, they help reduce network traffic and increase performance of clients using the WebDAV Protocol, as described in [RFC2518].<1>

1.7 Versioning and Capability Negotiation

Supported Transports: WebDAV Protocol: Microsoft Extensions use HTTP as their only transport.

Versioning: This document introduces no new versioning mechanisms except those that already exist in WebDAV and HTTP as described in [RFC2518] and [RFC2616].

Capability Negotiation: Negotiation of WebDAV and HTTP capabilities is described in [RFC2518] sections 9.1 and 15, and in [RFC2616] section 9.2, via the OPTIONS method. This document specifies extensions to the OPTIONS method, using HTTP response headers to indicate which server capabilities are present, which method verbs are available, and which authoring tools are used, as described in section 3.2.5.1.

1.8 Vendor-Extensible Fields

None.

1.9 Standards Assignments

No standards body has approved or governs this document or its header names and values. This specification conforms to the form and behavior of other custom HTTP headers, as described in [RFC2616] section 4.2.

2 Messages

This section describes transport requirements and syntax of WebDAV Protocol: Microsoft Extensions.

2.1 Transport

Messages are transported using HTTP, as specified in [RFC2518] and [RFC2616].

This protocol MAY be used with Secure Sockets Layer (SSL)/Transport Layer Security (TLS), as specified in [RFC2246].<2>

Port 80 is the standard port assignment for HTTP, and port 443 is the standard port assignment for HTTP over SSL/TLS. Implementations MAY support other ports.<3>

2.2 Message Syntax

The extension headers in this protocol conform to the form and behavior of other custom HTTP headers, as specified in [RFC2616] section 4.2. They are consistent with the WebDAV verbs and headers, as specified in [RFC2518] sections 8 and 9. Definitions are specified using the Augmented Backus-Naur Form (ABNF) syntax specified in [RFC2616] section 2.1.

2.2.1 Document Management Server Header

The Document Management Server header is used to advertise certain extended capabilities of the WebDAV server. This new header is specified as follows.

"DocumentManagementServer" ":" DMS-Options DMS-Options = *(DMS-Option ";") DMS-Option = DMS-Properties-Schema | DMS-Source-Control | DMS-Version-History | token DMS-Properties-Schema = "Properties Schema" DMS-Source-Control = "Source Control" DMS-Version-History = "Version History"

WebDAV servers implementing WebDAV Protocol: Microsoft Extensions use the options listed under DMS-Option to indicate to WebDAV clients support for various capabilities, which is extended by WebDAV Protocol: Microsoft Extensions servers to advertise additional capabilities through the use of new tokens. These capabilities are not part of the WebDAV Protocol: Microsoft Extensions, but are only advertised using this protocol extension.

For information about the use of this header with the OPTIONS verb, see section 3.1.5.1.

2.2.2 MS-Doclib Header

The MS-Doclib header is used to request and respond with information about the URL of a document library collection. This new header is specified as follows.

MS-Doclib-Header = "MS-Doclib" ":" MS-Doclib-Result MS-Doclib-Result = [absolute-URI]

The absolute-URI ABNF production rule is defined in [RFC3986]. The MS-Doclib-Header usage is specified in section 3.1.5.3.

2.2.3 Repl-uid Header

The Repl-uid header contains a repl-uid. This identifier is available in a read-only property that can be requested. When a PUT is called where the IF-Match header was used or an ETag was specified in an if header with an rt:GUID@version where the version is nonzero, then it is returned in a Repl-uid header in the response to a successful PUT operation. Otherwise the repl-uid is returned in a Recourse Tag in the response to a successful PUT operation.

Repl-Uid-Header = "Repl-uid" ":" Repl-Uid Repl-Uid = %x72.69.64 ":{" DocumentID "}" ; %x72.69.64 is "rid" case-sensitive. DocumentID = UUID

The DocumentID is a GUIDString that is unique for a given resource, without regard to the resource's location or version. A GUIDString is defined as the UUID ABNF production rule as found in [RFC4122] section 3. The Repl-uid header usage is specified in section 3.2.5.1.<4>

2.2.4 ResourceTag Header

The ResourceTag header contains a ResourceTag. This identifier is available in a read-only property that can be requested, and is returned in the body of the result for a PROPFIND method, but it is also returned in a ResourceTag header in the response to a successful GET, HEAD, or POST operation.

ResourceTag-Header = "ResourceTag" ":" ResourceTag ResourceTag = "rt:" DocumentID "@" 11DIGIT

The ResourceTag is an absolute-URI, as defined in [RFC3986], using the unregistered "rt" scheme. The value consists of a DocumentID followed by the at sign (@) followed by 11 decimal digits containing a version number for the resource. The ResourceTag header usage is specified in sections 3.1.5.5 and 3.2.5.5.

2.2.5 GETLIB Method

A server implementing the WebDAV Protocol: Microsoft Extensions MUST include the extension- method GETLIB in the list of methods returned in an Allow header, as specified in [RFC2616] section 5.1.1.

Method |= "GETLIB"

The GETLIB method is specified in section 3.1.5.2.

2.2.6 Translate Header

A WebDAV server implementing WebDAV Protocol: Microsoft Extensions MUST implement the Translate header as specified in [MS-WDVSE] section 2.2.1. <5>

2.2.7 MS-Author-Via Header

A WebDAV server implementing WebDAV Protocol: Microsoft Extensions MUST implement the MS- Author-Via header as specified in [MS-WDVSE] section 2.2.2.

2.2.8 User-Agent Header

A server implementing the WebDAV Protocol: Microsoft Extensions SHOULD use the information sent by the client in the User-Agent request header field for customized responses to requests made by unauthenticated clients<6>.

2.2.9 Extended DAV Properties

A WebDAV server implementing WebDAV Protocol: Microsoft Extensions MUST implement certain extended properties as elements in the DAV namespace.

2.2.9.1 DAV:iscollection Property

The DAV:iscollection property is a way of indicating that the requested resource is a collection. The value of this property is either "1" or "0" depending on whether the resource is a collection. This property appears within the DAV:prop element collection.<7>

2.2.9.2 DAV:isFolder Property

The DAV:isFolder property is a way of indicating that the requested resource is a folder. This property's value is either "t" or "f" depending on whether the resource is a folder. This property appears within the DAV:prop element collection.<8>

2.2.9.3 DAV:ishidden Property

The DAV:ishidden property reflects the state of the resource, indicating whether it would appear hidden if viewed as a file system item by a client. This property's value is either "1" or "0" depending on whether the resource is considered hidden. This property appears within the DAV:prop element collection.<9>

2.2.10 Microsoft Extension Properties

A WebDAV server implementing WebDAV Protocol: Microsoft Extensions SHOULD implement the following extended properties. The XML elements use the following schema namespace aliases for their definitions.

xmlns:Office="urn:schemas-microsoft-com:office:office" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:Z="urn:schemas-microsoft-com:"

When these elements appear in a response to a WebDAV client request, their schema aliases SHOULD be included.<10>

2.2.10.1 Repl:authoritative-directory Property

The Repl:authoritative-directory property, which indicates whether the directory listing is complete. This property's value is set to "t" for collection type resources when every resource in the collection is listed. If the property is set to "f", the directory listing could be incomplete and not contain every resource in the collection. This property appears within the DAV:prop element collection.<11>

2.2.10.2 Repl:resourcetag Property

The Repl:resourcetag property is a read-only property that contains a string with the document's ResourceTag. This property appears within the DAV:prop element collection.

2.2.10.3 Repl:repl-uid Property

The Repl:repl-uid property is a read-only property that contains a string with the document's Repl-uid. This property appears within the DAV:prop element collection.

2.2.10.4 Office:modifiedby Property

The Office:modifiedby property is a read-only property that contains a string with the user name of the last person to modify the document, as determined by the authentication mechanism used for the modification. This property appears within the DAV:prop element collection.

2.2.10.5 Office:specialFolderType Property

The Office:specialFolderType property is a dead property that can be set by a WebDAV client. The value of this property is restricted to a value stored in a 32-bit integer. This property appears within the DAV:prop element collection.

2.2.10.6 Z:Win32CreationTime Property

The Z:Win32CreationTime property is a dead property that can be set by a WebDAV client. The value of this property can be any string. This property appears within the DAV:prop element collection.

2.2.10.7 Z:Win32FileAttributes Property

The Z:Win32FileAttributes property is a live property that the server stores as a string on behalf of the client. This property appears within the DAV:prop element collection.

2.2.10.8 Z:Win32LastAccessTime Property

The Z:Win32LastAccessTime property is a dead property that the server stores as a string on behalf of the client. This property appears within the DAV:prop element collection.

2.2.10.9 Z:Win32LastModifiedTime

The Z:Win32LastModifiedTime property is a dead property that the server stores as a string on behalf of the client. This property appears within the DAV:prop element collection.<12>

3 Protocol Details

As specified in [RFC2518], WebDAV operates between an initiator (a WebDAV client) and a responder (a WebDAV server). This section specifies client and server behaviors with respect to the WebDAV Protocol: Microsoft Extensions.

3.1 WebDAV Microsoft Extensions Client Details

3.1.1 Abstract Data Model

No additional data is required beyond that in the base protocol. A WebDAV client MAY maintain state information about server support for WebDAV Protocol: Microsoft Extensions and about the contents of the MS-Author-Via header (section 2.2.7) and the Document Management Server header (section 2.2.1) for the duration of a connection session.

3.1.2 Timers

No new timers are required except those in the base protocol.

3.1.3 Initialization

No additional initialization is required beyond that in the base protocol.

3.1.4 Higher-Layer Triggered Events

No new events are triggered except those in the base protocol.

3.1.5 Processing Events and Sequencing Rules

A WebDAV Protocol: Microsoft Extensions client MUST send an OPTIONS request to the server and query the headers in the server response for the presence of an Allow header containing a GETLIB method (section 3.1.5.2), which signals the presence of a WebDAV Protocol: Microsoft Extensions- compliant server. The client SHOULD use this information when it sends requests to this server. The client MUST NOT add the WebDAV extensions specified in WebDAV Protocol: Microsoft Extensions to the commands when it communicates with a server that responds to the OPTIONS command without the GETLIB method in the Allow header.<13>

If the client does not support the extensions, the client MAY ignore the GETLIB value (section 2.2.5) in the Allow header or any other headers sent as part of the protocol and SHOULD NOT use the WebDAV extensions specified in WebDAV Protocol: Microsoft Extensions. If the server adds the optional headers, the headers SHOULD be ignored by the client as unrecognized.<14>

3.1.5.1 Extensions to OPTIONS

A WebDAV Protocol: Microsoft Extensions-compliant server advertises its capabilities via headers returned in response to a client's OPTIONS request. A client MUST use an OPTIONS request to determine server support for the WebDAV Protocol: Microsoft Extensions.<15>

3.1.5.2 GETLIB Method

The GETLIB method is part of the WebDAV Protocol: Microsoft Extensions provided to support interaction with a Document Library. Document Libraries can only be implemented in servers that support the FrontPage Server Extensions: Website Management Protocol, as documented in [MC- FPSEWM].

The GETLIB method is used to identify the absolute URL of a Document Library collection containing the resource URL given in the request, if any. A WebDAV Protocol: Microsoft Extensions client that also implements the FrontPage Server Extensions Website Management Protocol and includes support for interaction with a Document Library has the option of using the GETLIB method to request the absolute URL of the first collection at or above the requested resource in the hierarchy that is a Document Library.

3.1.5.3 PROPFIND Extensions

3.1.5.3.1 PROPFIND as an Alternative to GETLIB

In addition to the GETLIB verb (section 4.2) for finding the root of a Document Library collection, a WebDAV Protocol: Microsoft Extensions client that also implements the FrontPage Server Extensions: Website Management Protocol, as documented in [MC-FPSEWM], and includes support for interaction with a Document Library MAY use the PROPFIND method to request the absolute URL of the first collection at or above the requested resource in the hierarchy that is a Document Library. To use this extension, the client uses the PROPFIND method with the resource the client wants to find the containing Document Library for, and includes an MS-Doclib header (section 2.2.2) with the request. The MS-Doclib header in the request SHOULD be empty, and there SHOULD be no request body.

3.1.5.4 Write Lock Limitations

A WebDAV Protocol: Microsoft Extensions-compliant server MAY be noncompliant with [RFC2518] section 7, which specifies the behavior of the Write Lock. A client of a server implementing this protocol SHOULD NOT expect nonexclusive locks or locks on null resources to be issued.<16>

3.1.5.5 If Header Modification

A WebDAV Protocol: Microsoft Extensions-compliant server MAY<17> be noncompliant with [RFC2518] section 9.4, but MUST implement at least an alternative If header syntax that uses a ResourceTag as a State token. A WebDAV Protocol: Microsoft Extensions-compliant client communicating with a WebDAV Protocol: Microsoft Extensions-compliant server using a method such as PUT that makes use of an If header MUST limit the content of that If header in the following way:

Using the definitions specified in [RFC2518] section 9.4, the If header MUST contain a single no-tag- list consisting of a single list (that contains a single instance of the content), an optional "Not" followed by a State token, (that MUST be a Coded-URL containing an absolute-URI, which MUST be a ResourceTag). The modified ABNF definition specified in [RFC2518] for the If header is as follows.

If = "If" ":" No-tag-list No-Tag-List = List List = "(" ["Not"] State-token ")" State-token = Coded-URL Coded-URL = "<" ResourceTag ">"

When an If header is included in a GET/HEAD/POST with "Not" specified, and the ResourceTag is incorrect, the behavior is to return a HTTP status code of Precondition Failed. Without the "Not" specified, ignore the header.

When an If header is included in a PUT without "Not" specified, the behavior is the same as if there was an if-match with an Etag. With "Not" specified, the server will ignore the ResourceTag as long as it is valid and will fail this PUT request.<18>

The ResourceTag value is obtained from the ResourceTag header (section 2.2.4) returned in the result of a GET, HEAD, or POST request, or the Repl:resourcetag entity in the result body of a PROPFIND method for the specified resource.

Note If-Match or If-None-Match takes an ETag; If header takes a ResourceTag. An ETag is an opaque string which happens to contain a docid and a version. A ResourceTag is explicitly a GUID and a version.

3.1.5.6 Client Properties

A WebDAV client SHOULD NOT attempt to store arbitrary dead properties on a WebDAV server implementing WebDAV Protocol: Microsoft Extensions. A WebDAV Protocol: Microsoft Extensions- aware WebDAV client MAY set the following dead properties in the xmlns:Z="urn:schemas-microsoft- com:" XML namespace.<19>

Z:Win32FileAttributes Z:Win32CreationTime Z:Win32LastAccessTime Z:Win32LastModifiedTime

A WebDAV client MAY set the following dead property in the xmlns:Office="urn:schemas-microsoft- com:office:office" XML namespace.<20>

Office:specialFolderType

3.1.6 Timer Events

No new timers are required except those in the base WebDAV Protocol.

3.1.7 Other Local Events

There are no new local events other than those specified in the base protocol.

3.2 WebDAV Microsoft Extensions Server Details

3.2.1 Abstract Data Model

No additional data is required beyond that in the base protocol.

3.2.2 Timers

No new timers are required except those in the base protocol.

3.2.3 Initialization

No additional initialization is required beyond that in the base protocol.

3.2.4 Higher-Layer Triggered Events

No new events are triggered except those in the base protocol.

3.2.5 Processing Events and Sequencing Rules

None.

3.2.5.1 Extensions to OPTIONS

A WebDAV Protocol: Microsoft theft Extensions-compliant server advertises its capabilities via headers returned in response to a client's OPTIONS request.<21>

The Allow entity header field, as specified in [RFC2616] section 14.7, of the OPTIONS response SHOULD include the methods supported by compliant WebDAV servers as well as the GETLIB extension method (section 2.2.5).

In addition to the headers normally returned by a WebDAV-compliant server to the OPTIONS request, as specified in [RFC2518], a server compliant with the WebDAV Protocol: Microsoft Extensions MUST respond with the MS-Author-Via header (section 2.2.7). The server MAY send the Document Management Server header (section 2.2.1) as specified below.<22>

A Public-Extension header with the schema http://schemas.microsoft.com/repl-2 SHOULD<23> be sent to provide the definitions for the XML tags Repl-uid and ResourceTag.

The MS-Author-Via header is specified in [MS-WDVSE]. A server implementing the WebDAV Protocol: Microsoft Extensions MUST include the DAV option in this header.

The Document Management Server header (section 2.2.1) SHOULD NOT be sent unless the server implements one or more of the capabilities listed (or other extended capabilities) in its implementation of the FrontPage Server Extensions: Website Management Protocol, as specified in [MC-FPSEWM]. The capabilities listed are not part of the WebDAV Protocol: Microsoft Extensions. They are listed in this header to inform clients capable of using the FrontPage Server Extensions: Website Management Protocol, as documented in [MC-FPSEWM].

3.2.5.2 GETLIB Method

The GETLIB method is part of the WebDAV Protocol: Microsoft Extensions provided to support interaction with a Document Library. Document Libraries can only be implemented by servers that support the FrontPage Server Extensions: Website Management Protocol, as specified in [MC- FPSEWM].

. If the server does not implement Document Library collection capabilities, the server MUST respond with an HTTP 404 Not Found.

Otherwise, the server MUST do the following:

. If the request is from a client that has not been authenticated, or a client that does not have appropriate permissions to open the requested resource, the server MUST respond with an HTTP 401 error.

. If the requested resource is not path to a Document Library, the server MUST respond with an HTTP 404 Not Found.

. If the requested resource is part of a Document Library, and the client has appropriate permissions to open the resource, the server MUST respond with an HTTP 200 OK, and include an MS-Doclib header (section 2.2.2) with the absolute URL of the containing Document Library collection that is nearest in the resource hierarchy to the requested resource. The server SHOULD leave the response body empty.

3.2.5.3 PROPFIND Extensions

3.2.5.3.1 PROPFIND and Depth:0

When a WebDAV client requests a PROPFIND with a Depth header (as specified in [RFC2518] section 9.2) with a value of 0 for a resource that does not exist and the client does not have permission to access the document library, a WebDAV Protocol: Microsoft Extensions server SHOULD<24> respond with a message body indicating that the resource exists and is a collection. When a WebDAV client requests a PROPFIND with a Depth header (as specified in [RFC2518] section 9.2) with a value of 0 for a resource that does not exist and the client has permission to access the document library, a WebDAV Protocol: Microsoft Extensions server SHOULD respond with a "HTTP 404 File not Found".<25>

3.2.5.3.2 PROPFIND as an Alternative to GETLIB

In addition to the GETLIB verb (section 4.2) for finding the root of a Document Library collection, if the client request includes an MS-Doclib header (section 2.2.2), a WebDAV Protocol: Microsoft Extensions server SHOULD extend the PROPFIND verb to behave identically to the GETLIB verb, as specified in section 3.2.5.2.

The server MUST ignore the contents of the MS-Doclib header and MUST ignore the contents of the request body. The server response to this request MUST return only the headers and response body specified in section 3.1.5.2 for the GETLIB method.

3.2.5.3.3 PROPFIND Lock Properties

A WebDAV Protocol: Microsoft Extensions server SHOULD NOT include DAV:activelock property elements in the DAV:lockdiscovery property for any resource if the user agent header contains the string "Microsoft-WebDAV-MiniRedir" and the version is prior to 5.2.3718.0.<26>

3.2.5.4 Write Lock Limitations

[RFC2518] section 7 specifies the behavior of the write lock. A server implementing the WebDAV Protocol: Microsoft Extensions MAY be compliant with the requirements of [RFC2518] section 7.<27>

3.2.5.5 If Header Modification

A server compliant with the WebDAV Protocol: Microsoft Extensions MAY be compliant with the If header specification in [RFC2518] section 9.4.<28>

Whether or not a WebDAV Protocol: Microsoft Extensions server is in compliance with If header semantics as specified in [RFC2518] section 9.4, a WebDAV Protocol: Microsoft Extensions server MUST allow for an If header of the form specified in section 3.1.5.5 and perform the checks specified in [RFC2518] required to honor the If header.<29>

3.2.5.6 Server Properties

A WebDAV Protocol: Microsoft Extensions-compliant WebDAV server MAY allow a client to set arbitrary dead values, as specified in [RFC2518] section 8.2.<30>

A WebDAV Protocol: Microsoft Extensions-compliant server MUST support client setting of the following properties in the xmlns:Z="urn:schemas-microsoft-com:" XML namespace.

Z:Win32FileAttributes Z:Win32CreationTime Z:Win32LastAccessTime

Z:Win32LastModifiedTime

A WebDAV Protocol: Microsoft Extensions-compliant WebDAV server MUST support the following read- only property in the xmlns:Office="urn:schemas-microsoft-com:office:office" XML namespace.

Office:modifiedby

A WebDAV Protocol: Microsoft Extensions-compliant WebDAV server SHOULD support the following dead property in the xmlns:Office="urn:schemas-microsoft-com:office:office" XML namespace.

Office:specialFolderType

A WebDAV Protocol: Microsoft Extensions-compliant WebDAV server MUST support the following read- only properties in the xmlns:Repl="http://schemas.microsoft.com/repl/" XML namespace.

Repl:authoritative-directory Repl:repl-uid Repl:resourcetag

A WebDAV Protocol: Microsoft Extensions-compliant WebDAV server SHOULD support the following read-only properties in the xmlns:D="DAV:" XML namespace.

D:iscollection D:isFolder D:ishidden

3.2.6 Timer Events

No new timers are required except those in the base WebDAV Protocol.

3.2.7 Other Local Events

There are no new local events other than those specified in the base WebDAV Protocol.

4 Protocol Examples

This section provides examples of the WebDAV Protocol: Microsoft Extensions. In these examples, several common general and implementation-specific headers in the client requests and server responses have been omitted for clarity.

4.1 OPTIONS Verb

The following is an example of a WebDAV client request and the response generated by a WebDAV server that implements WebDAV Protocol: Microsoft Extensions.

4.1.1 Client OPTIONS Request

In this example request, the client sends the OPTIONS verb to the root of the server at www.contoso.com. Other client-specific headers have been left out for readability.

OPTIONS / HTTP/1.1 Host: www.contoso.com Accept: */* Connection: Keep-Alive

4.1.2 FrontPage Server Extension-Compliant Server Response

The following example shows a response from a server that fully supports the FrontPage Server Extensions: Website Management Protocol, as specified in [MC-FPSEWM], and the Document Management Server capabilities.

HTTP/1.1 200 OK Date: Tue, 05 Jun 2007 02:00:02 GMT MS-Author-Via: MS-FP/4.0,DAV DocumentManagementServer: Properties Schema;Source Control; Version History; DAV: 1,2 Allow: GET, POST, OPTIONS, HEAD, MKCOL, PUT, PROPFIND, PROPPATCH, DELETE, MOVE, COPY, GETLIB, LOCK, UNLOCK Content-Length: 0 Public-Extension: http://schemas.microsoft.com/repl-2

Because this server fully implements the FrontPage Server Extensions: Website Management Protocol, as specified in [MC-FPSEWM], it includes the Document Management Server header (section 2.2.1) with all three options, and includes the "MS-FP/4.0" option in its MS-Author-Via header (section 2.2.7), as specified in [MS-WDVSE].

4.2 GETLIB Verb and PROPFIND Extension for Document Library Support

A server that implements both WebDAV Protocol: Microsoft Extensions and supports Document Library functionality uses the GETLIB verb or the GETLIB support through the PROPFIND verb to communicate the root of the Document Library to a client.

4.2.1 Client Request

The following is an example of a client request to find the root of the Document Library for the resource "/Shared Documents/testing/Files" with other client-specific headers left out, and assuming an anonymous connection.

GETLIB /Shared%20Documents/testing/Files HTTP/1.1 Host: www.contoso.com Accept: */* Connection: Keep-Alive

4.2.2 Server Response

The MS-Doclib header (section 2.2.2) in the result contains the absolute URI of the Document Library containing the resource "/Shared Documents/testing/Files", which in this case is http://www.contoso.com/Shared Documents. The response from a server that implements WebDAV Protocol: Microsoft Extensions with support for a Document Library can safely include other general, server, and implementation-specific headers in any order.

HTTP/1.1 200 OK Date: Tue, 05 Jun 2007 20:05:01 GMT MS-Doclib: http://www.contoso.com/Shared Documents Content-Length: 0 Public-Extension: http://schemas.microsoft.com/repl-2

4.2.3 Client Request Using PROPFIND

When the PROPFIND verb (section 4.2) is used with an MS-Doclib header (section 2.2.2), the request may look like the following example.

PROPFIND /Shared%20Documents/testing/Files HTTP/1.1 Host: www.contoso.com Accept: */* Connection: Keep-Alive MS-Doclib: some random value

Note that, as specified, a client does not send a value in the MS-Doclib header, and the server ignores any value that is present. The order of the headers is not significant, as specified in [RFC2616] section 4.2, and the request may include other client-specific headers. The server response should be identical to the server's GETLIB verb (section 4.2) response for the same resource.

4.3 If Header Usage

The following example shows the interaction between a WebDAV client and a WebDAV server implementing WebDAV Protocol: Microsoft Extensions as the client first makes a GET request for a file, and a subsequent PUT of a modified file with an If header to make sure that the file has not changed in the interim. Then the client attempts to PUT the file with an If header with an incorrect ResourceTag, and the server response is shown.

4.3.1 Client GET Request

First, the client makes a GET request, using the Translate: f header to get the document without server processing.

GET /Shared%20Documents/simple.txt HTTP/1.1 Host: www.contoso.com Accept: */* Translate: f Connection: Keep-Alive

4.3.2 GET Request: Server Response

The WebDAV Protocol: Microsoft Extensions server responds with the following (with some headers omitted for clarity).

HTTP/1.1 200 OK Date: Thu, 14 Jun 2007 21:27:17 GMT Server: Microsoft-IIS/6.0 Last-Modified: Thu, 14 Jun 2007 21:14:42 GMT ETag: "{93DAE904-C4AE-4B5F-A7F6-BDF4FAACEF5F},2" ResourceTag: rt:93DAE904-C4AE-4B5F-A7F6-BDF4FAACEF5F@00000000002 Content-Type: text/plain Cache-Control: private Content-Length: 53 Public-Extension: http://schemas.microsoft.com/repl-2

This is a simple document that has some text in it.

The response includes the ResourceTag needed for an If header in a conditional action.

4.3.3 Client PUT Request with If Header

A PUT request with new content for the resource the client just performed a GET request on, using an If header to make sure the document hasn't changed in the interim.

PUT /Shared%20Documents/simple.txt HTTP/1.1 If: () Host: www.contoso.com Accept: */* Content-Length: 67 Connection: Keep-Alive

This is a simple document that has some newly changed text in it.

4.3.4 Server Response to PUT

The client has the If header set to the correct value for the ResourceTag, so the server responds with the following.<31>

HTTP/1.1 200 OK Date: Thu, 14 Jun 2007 21:30:07 GMT Server: Microsoft-IIS/6.0 Cache-Control: private Content-Length: 0 Public-Extension: http://schemas.microsoft.com/repl-2

4.3.5 Client PUT Request with If Header with Incorrect ResourceTag

In the following example, the client performs a PUT request with new content for the document, using an If header with the old ResourceTag, which no longer matches the new value on the server.

PUT /Shared%20Documents/simple.txt HTTP/1.1 If: () Host: www.contoso.com Accept: */* Content-Length: 67 Connection: Keep-Alive

This is a simple document that has some other changed text in it.

4.3.6 Server PUT Response to Incorrect ResourceTag in If Header

The server responds to the PUT request with an incorrect ResourceTag, as follows.

HTTP/1.1 412 PRECONDITION FAILED Date: Thu, 14 Jun 2007 21:30:44 GMT Server: Microsoft-IIS/6.0 Cache-Control: private Content-Length: 0 Public-Extension: http://schemas.microsoft.com/repl-2

5 Security

5.1 Security Considerations for Implementers

WebDAV servers that support the translate: f header needs to perform access checks before returning the source of the file to protect any source content (for example, database passwords).

5.2 Index of Security Parameters

No new security parameters are required beyond those in the base protocol.

6 Appendix A: Product Behavior

The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include released service packs.

. Windows 2000 operating system

. Windows XP operating system

. Windows Server 2003 operating system

. Windows Vista operating system

. Windows Server 2008 operating system with Service Pack 2 (SP2)

. Windows 7 operating system

. Windows Server 2008 R2 operating system

. Windows SharePoint Services 2.0

. Windows SharePoint Services 3.0

. Microsoft SharePoint Foundation 2010

. Microsoft SharePoint Foundation 2013

. Microsoft SharePoint Server 2016 Preview

Exceptions, if any, are noted below. If a service pack or Quick Fix Engineering (QFE) number appears with the product version, behavior changed in that service pack or QFE. The new behavior also applies to subsequent service packs of the product unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.

Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms SHOULD or SHOULD NOT implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term MAY implies that the product does not follow the prescription.

<1> Section 1.6: The WebDAV server is available as an Internet Server API (ISAPI) extension in Internet Information Services (IIS), Windows SharePoint Services 2.0 and Windows SharePoint Services 3.0.

<2> Section 2.1: Client support for SSL/TLS is available only in Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2. WebDAV servers that run on IIS, on Windows SharePoint Services 3.0, support SSL/TLS.

<3> Section 2.1: Windows XP, Windows Server 2003, Windows 7, and Windows Server 2008 R2 WebDAV clients support only port 80. Support for other ports is available only in Windows Vista and Windows Server 2008. The WebDAV client in Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2 uses port 80 by default for HTTP, and port 443 for HTTP over SSL/TLS. WebDAV servers that run on IIS or on Windows SharePoint Services 3.0 support any port.

<4> Section 2.2.3: Windows SharePoint Services 2.0 does not support this header.

<5> Section 2.2.6: For a Translate header (section 2.2.6) value of FALSE, the WebDAV server included in IIS for Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2 requires WRITE access to return the source of the file.

<6> Section 2.2.8: The WebDAV server in Windows SharePoint Services 3.0 technology checks the product tokens in the User-Agent request header field sent with a request for the presence of "Mozilla" and the absence of either "Office", "FrontPage", or "non-browser" to determine whether to send an HTTP 302 redirect message to a login page when using ASP.NET forms authentication for unauthenticated clients. Otherwise, the server assumes that the client user agent is not a browser and will return either an HTTP 401 "Unauthorized" error to prompt authentication when using Integrated Windows authentication, or an HTTP 403 "Forbidden" error when using ASP.NET forms authentication along with an X-MSDAVEXT_ERROR message ([MS-WDV] section 2.2.3) with an Extended-error value of 917656. This specific error combination is used by the client WebDAV Redirector as a signal to send a Cookies request header along with the request. If the client does not have a Forms Authentication cookie, the server will resend the HTTP 403 error with the X- MSDAVEXT_ERROR message with an Extended-error value of 917656, as a signal to the client that it needs to prompt the user to authenticate.

In the case where the server determines that the client user agent is not a browser, the server additionally checks for the absence of any additional tokens (beyond "non-browser") in the User-Agent request header field. If no other tokens are found, the server assumes that the client is capable of opening documents in a folder only if the user first navigates into the containing folder and it returns HTML markup consistent with that limited capability. Otherwise, the server assumes that the client is capable of opening documents in a folder by using the full path to the document (without requiring explicit navigation into the appropriate folder) and returns HTML markup consistent with that greater capability.

<7> Section 2.2.9.1: Windows SharePoint Services 2.0, Windows SharePoint Services 3.0, SharePoint Foundation 2010 and SharePoint Foundation 2013 only return this property for collections, and only as part of a PROPFIND allprop request, not when requested individually with PROPFIND using a property list. It is always set to 1.

<8> Section 2.2.9.2: Windows SharePoint Services 2.0, Windows SharePoint Services 3.0, SharePoint Foundation 2010 and SharePoint Foundation 2013 only return this property for collections. It is always set to "t".

<9> Section 2.2.9.3: Windows SharePoint Services 2.0, Windows SharePoint Services 3.0, SharePoint Foundation 2010 and SharePoint Foundation 2013 only return this property for collections, and only as part of a PROPFIND allprop request, not when requested individually with PROPFIND using a property list. It is always set to 0.

<10> Section 2.2.10: XML parser limitations in Windows SharePoint Services 2.0, Windows SharePoint Services 3.0, SharePoint Foundation 2010 and SharePoint Foundation 2013 require that the XML namespace aliases that clients send always appear as listed in section 2.2.10. Windows SharePoint Services 2.0, Windows SharePoint Services 3.0, SharePoint Foundation 2010 and SharePoint Foundation 2013 do not recognize any other form of these element names, including fully qualified element names.

<11> Section 2.2.10.1: Windows SharePoint Services 2.0, Windows SharePoint Services 3.0, SharePoint Foundation 2010 and SharePoint Foundation 2013 only return this property for collections, and only as part of a PROPFIND allprop request, not when requested individually with PROPFIND using a property list. It is always set to "t".

<12> Section 2.2.10.9: SharePoint 2010 cumulative update for June 2013 does not return Z:Win32LastModifiedTime property.

<13> Section 3.1.5: The WebDAV client sends an OPTIONS command to verify server support for extensions.

<14> Section 3.1.5: In Windows XP and Windows Server 2003, the WebDAV client does not support the extensions and, therefore, the new headers are ignored on the OPTIONS response. In Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2 the WebDAV client supports the extensions, and the new headers in the server OPTIONS response are not ignored.

<15> Section 3.1.5.1: While a WebDAV-compliant server could choose to implement WebDAV on some resources and not on others, and allow the client to distinguish this fact by sending an OPTIONS verb to any resource, limitations in the client WebDAV implementation do not allow for a WebDAV server that supports WebDAV on only some resources. To support the client, Windows SharePoint Services 2.0 and Windows SharePoint Services 3.0 do not implement this capability, and instead only allow a server-wide setting of the WebDAV capabilities and the WebDAV Protocol: Microsoft Extensions. Therefore, a single OPTIONS verb sent to a server tells a WebDAV client whether these extensions are available server-wide. Due to a defect in Windows SharePoint Services 2.0 and Windows SharePoint Services 3.0, the OPTIONS request is sent with an actual resource location in the Request-URI, and not to the asterisk (*) general location.

<16> Section 3.1.5.4: Windows SharePoint Services 2.0 and Windows SharePoint Services 3.0 are not compliant with [RFC2518] section 7.4, and do not implement write locks on null resources.

<17> Section 3.1.5.5: Windows SharePoint Services 2.0 and Windows SharePoint Services 3.0 are not compliant with [RFC2518] section 9.4 and do not implement the If header except as specified in this extension.

<18> Section 3.1.5.5: The If-None-Match request header field is used with a method to make it conditional. When a client has obtained one or more entities from a resource, it can verify that none of those entities is current by including a list of their associated entity tags in the If-None-Match header field. The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead, and to prevent a method such as PUT from inadvertently modifying an existing resource when the client believes that the resource does not exist.

<19> Section 3.1.5.6: These dead properties are used by the Client WebDAV Redirector to store implementation-specific file attributes in these properties, but Windows SharePoint Services accepts any value for these properties. Windows SharePoint Services 3.0 provides a default value for the Z:Win32FileAttributes property (section 2.2.10.7) for certain collections on the server that are hidden and not normally accessible, if no value has been set by the client. The Windows SharePoint Services 3.0 server provides a default value of "00000016" (which is interpreted by the Client WebDAV Redirector as a combination of HIDDEN and SYSTEM attributes) for a directory that begins with an underscore (_). The Windows SharePoint Services 3.0 server provides a default value of "00000012" (which is interpreted by the Client WebDAV Redirector as the HIDDEN attributes) for a directory that is contained within a Document Library and is named "Forms".

<20> Section 3.1.5.6: This dead property is supported by Windows SharePoint Services 2.0, Windows SharePoint Services 3.0, SharePoint Foundation 2010 and SharePoint Foundation 2013 but is not used by the Client or by any version of Microsoft Office. When this property is set with a PROPPATCH command, Windows SharePoint Services 2.0, Windows SharePoint Services 3.0, SharePoint Foundation 2010 and SharePoint Foundation 2013 parse the input as an unsigned decimal string and stores it internally in a signed 32-bit integer. Windows SharePoint Services 2.0, Windows SharePoint Services 3.0, SharePoint Foundation 2010 and SharePoint Foundation 2013 return this property in a PROPFIND request as a signed decimal string.

<21> Section 3.2.5.1: Windows SharePoint Services 3.0 maintains a state flag indicating whether it should advertise its extended capabilities in response to an OPTIONS request. If the state flag is not set, Windows SharePoint Services returns the usual headers returned by a WebDAV-compliant server, as specified in [RFC2518], including the Allow header with the GETLIB method (section 3.1.5.2), but it will not send the MS-WebDAV-Extension, MS-Author-Via (section 2.2.7), Document Management Server (section 2.2.1), or Microsoft Office Web Server headers.

<22> Section 3.2.5.1: The WebDAV server in Windows SharePoint Services 3.0 technology checks whether the user agent header string sent with an OPTIONS request is "Microsoft Data Access Internet Publishing Provider". In this case, the server sends an additional Microsoft Office Web Server header of the following form with content of "5.0_Collab" in the OPTIONS response.

MicrosoftOfficeWebServer: 5.0_Collab

Windows SharePoint Services 3.0 server does not send this header in response to a client sending any other user agent header string. Sending this additional header overcomes a defect in the Microsoft Data Access Internet Publishing Provider (MSDAIPP) component in versions of the Client prior to Windows Vista, which otherwise might not recognize the presence of WebDAV Protocol client extensions in the server and thus fall back to basic WebDAV behavior. Adding this header allows this component to optimize its behavior to take advantage of WebDAV Protocol client extensions.

<23> Section 3.2.5.1: If the WebDAV server in Windows SharePoint Services 3.0 technology detects that the user agent string sent with an OPTIONS request is "Microsoft Data Access Internet Publishing Provider", then the server does not send the Public-Extension header with the http://schemas.microsoft.com/repl-2 schema option, to overcome a defect in the Client MSDAIPP component in Windows XP and Windows Server 2003.

<24> Section 3.2.5.3.1: SharePoint Foundation 2013 will respond an HTTP 401 "Unauthorized" error.

<25> Section 3.2.5.3.1: WebDAV clients in Windows XP and Windows Server 2003 may attempt to walk the resource hierarchy for a particular resource, even when elements of that hierarchy are nonexistent or otherwise not available for access, such as when a user has permissions to access resources at a certain level in the hierarchy, but not above that level. Windows SharePoint Services 2.0 and Windows SharePoint Services 3.0 report the existence of any such inaccessible resource that is requested, and report whether a resource is a directory (that is, a resource collection) to enable WebDAV clients to succeed. This behavior has the side effect of allowing the user to explicitly browse with the WebDAV client to a nonexistent directory, even though all user actions, such as listing the directory contents or putting a file in that directory, will fail.

<26> Section 3.2.5.3.3: In versions of Windows prior to Windows Server 2003, the Client WebDAV Redirector was not aware of WebDAV locks and the related properties for lock discovery and reporting. If a DAV:activelock property is returned by a PROPFIND to these older versions of the Client, the client appends the value returned in the DAV:href element within the DAV:locktoken to the name of the resource. Because this results in an incorrect name that is unusable for further navigation, Windows SharePoint Services 2.0, Windows SharePoint Services 3.0, SharePoint Foundation 2010 and SharePoint Foundation 2013 perform this check before sending a PROPFIND response to the affected Clients and modifies its output accordingly.

<27> Section 3.2.5.4: Windows SharePoint Services 2.0 and Windows SharePoint Services 3.0 are not compliant with [RFC2518] section 7.4 and do not implement write locks on null resources.

<28> Section 3.2.5.5: Windows SharePoint Services 2.0 and Windows SharePoint Services 3.0 are not compliant with [RFC2518] section 9.4 and do not implement the If header except as specified in this extension.

<29> Section 3.2.5.5: Windows SharePoint Services 2.0 and Windows SharePoint Services 3.0 do not check for the existence of multiple ResourceTag state tokens or for other allowed list combinations that include ResourceTag state tokens.

<30> Section 3.2.5.6: Windows SharePoint Services 2.0 and Windows SharePoint Services 3.0 do not allow setting arbitrary dead properties other than ones listed as supported for WebDAV clients.

<31> Section 4.3.4: Windows SharePoint Services 3.0 returns two ResourceTag headers (section 2.2.4) in response to any PUT request; one containing the ResourceTag value passed in by the WebDAV client's request in an If header and an additional ResourceTag header, which contains the updated ResourceTag value. WebDAV clients do not rely on the ResourceTag values returned in the response to a PUT request to make any subsequent changes to the resource.

7 Change Tracking

This section identifies changes that were made to this document since the last release. Changes are classified as New, Major, Minor, Editorial, or No change.

The revision class New means that a new document is being released.

The revision class Major means that the technical content in the document was significantly revised. Major changes affect protocol interoperability or implementation. Examples of major changes are:

. A document revision that incorporates changes to interoperability requirements or functionality.

. The removal of a document from the documentation set.

The revision class Minor means that the meaning of the technical content was clarified. Minor changes do not affect protocol interoperability or implementation. Examples of minor changes are updates to clarify ambiguity at the sentence, paragraph, or table level.

The revision class Editorial means that the formatting in the technical content was changed. Editorial changes apply to grammatical, formatting, and style issues.

The revision class No change means that no new technical changes were introduced. Minor editorial and formatting changes may have been made, but the technical content of the document is identical to the last released version.

Major and minor changes can be described further using the following change types:

. New content added.

. Content updated.

. Content removed.

. New product behavior note added.

. Product behavior note updated.

. Product behavior note removed.

. New protocol syntax added.

. Protocol syntax updated.

. Protocol syntax removed.

. New content added due to protocol revision.

. Content updated due to protocol revision.

. Content removed due to protocol revision.

. New protocol syntax added due to protocol revision.

. Protocol syntax updated due to protocol revision.

. Protocol syntax removed due to protocol revision.

. Obsolete document removed.

Editorial changes are always classified with the change type Editorially updated.

Some important terms used in the change type descriptions are defined as follows:

. Protocol syntax refers to data elements (such as packets, structures, enumerations, and methods) as well as interfaces.

. Protocol revision refers to changes made to a protocol that affect the bits that are sent over the wire.

The changes made to this document are listed in the following table. For more information, please contact [email protected].

Tracking number (if Major change Section Change type applicable) and description (Y or N)

2.2.10.9 Fixed the TDI 67708 by adding N Content update. Z:Win32LastModifiedTime a product behavior node.

6 Appendix A: Product Updated list of supported Content updated due Y Behavior products. to protocol revision.

8 Index A client GET request 21 client PUT request with If header 22 Abstract data model client PUT request with If header with incorrect client 14 ResourceTag 22 server 16 GET request – server response 22 Applicability 9 server PUT response to If header with incorrect ResourceTag 23 C server response to PUT 22 Implementer - security considerations 24 Capability negotiation 9 Index of security parameters 24 Change tracking 29 Informative references 8 Client Initialization abstract data model 14 client 14 higher-layer triggered events 14 server 16 initialization 14 Introduction 6 message processing 14 other local events 16 M sequencing rules 14 timer events 16 Message processing timers 14 client 14 server 17 D Messages Document Management Server Header 10 Data model - abstract Extended DAV Properties 12 client 14 GETLIB Method 11 server 16 Microsoft Extension Properties 12 Document Management Server Header message 10 MS-Author-Via Header 11 MS-Doclib Header 10 E Repl-uid Header 11 ResourceTag Header 11 Examples syntax 10 GETLIB verb and PROPFIND extensions for Translate Header 11 Document Library support 20 transport 10 If header usage 21 User-Agent Header 12 OPTIONS verb 20 Microsoft Extension Properties message 12 overview 20 MS-Author-Via Header message 11 Extended DAV Properties message 12 MS-Doclib Header message 10

F N

Fields - vendor-extensible 9 Normative references 7

G O

GETLIB Method message 11 OPTIONS verb example 20 GETLIB verb and PROPFIND extensions for Document client OPTIONS request 20 Library support example 20 FrontPage Server extension-compliant server client request 20 response 20 client request using PROPFIND 21 Other local events server response 21 client 16 Glossary 6 server 19 Overview (synopsis) 8 H P Higher-layer triggered events client 14 Parameters - security index 24 server 16 Preconditions 9 Prerequisites 9 I Product behavior 25 Protocol Details

overview 14 If header usage example 21

References 7 informative 8 normative 7 Relationship to other protocols 9 Repl-uid Header message 11 ResourceTag Header message 11

Security implementer considerations 24 parameter index 24 Sequencing rules client 14 server 17 Server abstract data model 16 higher-layer triggered events 16 initialization 16 message processing 17 other local events 19 sequencing rules 17 timer events 19 timers 16 Standards assignments 9 Syntax 10

Timer events client 16 server 19 Timers client 14 server 16 Tracking changes 29 Translate Header message 11 Transport 10 Triggered events - higher-layer client 14 server 16

User-Agent Header message 12

Vendor-extensible fields 9 Versioning 9