# 附录F. 相比RFC 2518的变更摘要

本节列出了本文档与RFC 2518之间的主要变更，尤其是那些可能导致实现更改的内容。服务器将通过在DAV响应标头中返回兼容级别“3”来通告对本规范中所有更改的支持（请参见10.1和18.3节）。

# F.1 客户端和服务器实现的更改

PROPFIND'allprop'（第9.1节）的语义已放宽，以便服务器返回的结果至少包括本规范中定义的活属性，但不一定返回其他活属性。因此，“allprop”指令的含义更像是“返回请求'allprop'时应返回的所有属性” ，这是一组属性，其中可能包括自定义属性和其他规范中定义的属性（如果其他规范要求）。与此相关的是，'allprop'请求现在可以使用'include'语法进行扩展，以包括特定的命名属性，从而避免了由于'allprop'语义改变而导致的其他请求。
现在允许服务器拒绝Depth:Infinity的PROPFIND请求。使用此方法的客户端将需要能够执行一系列“Depth:1”的请求。
现在多状态响应主体可以在新的“location”元素中传输HTTP的Location响应标头的值。当存在带有3xx状态的“response”元素时，客户端可以使用它来避免到服务器的额外往返（请参阅第14.24节）。
COPY的定义已经放宽，因此不再需要服务器先删除目标资源（这是与[RFC3253]的不兼容）。请参阅第9.8节。

现在，“Destination”和“If”请求标头除了允许完整的URI外，还允许使用绝对路径（请参见第8.3节）。这对于通过反向代理运行的客户端很有用，因为反向代理可能只重写了主机请求标头，但没有重写WebDAV特定的标头。
本规范采用错误编组扩展和[RFC3253]中定义的“前提条件/后置条件”术语（请参见第16节）。与此相关的是，它在多状态响应主体中添加了“error” XML元素（请参阅第14.5节，但是请注意，它使用的格式与RFC 3253中建议的格式不同）。
现在要求发送者和接收者在XML消息正文中支持UTF-16字符编码（请参见第19节）。
现在要求客户端在PROPFIND请求上发送Depth标头，尽管仍然鼓励服务器去支持那些不支持的客户端。

RFC 2518的“lock-null resources”（LNRs）概念已由一种简化的方法“locked empty resources”取代（请参见7.3节）。lock-null的资源的客户端在某些方面不再可靠，具体说就是，用它们来创建锁定集合的能力，或者在没有发出PUT或MKCOL请求时就发出UNLOCK会导致lock-null资源消失的事实。请注意，根据RFC 2518，仍然允许服务器实现LNR。
不再隐式刷新锁。仅在明确请求时才刷新锁（请参见第9.10.2节）。
阐明了LOCK请求中提供的DAV:owner值必须像死属性一样由服务器保留（第14.17节）。还添加了DAV:lockroot元素（第14.12节），该元素允许客户端发现锁根。

由于互操作性问题，多状态响应中“href”元素的内容允许的格式受到限制（请参见第8.3节）。
由于缺乏实施，已删除了对COPY和MOVE的“propertybehavior”请求主体的支持。取而代之的是，预留属性的要求被声明（请参阅第9.8节和第9.9节）。

结合属性的定义已经被修复，因此不会再因Request-URI而不同（请参见5.2节）。

由于缺乏实际使用，[RFC2518] 4.6节中引入的DAV:source属性已被删除。

DAV标头现在除了兼容性级别之外，还允许通过URI进行非IETF扩展。现在，它也可以在请求中使用，尽管该规范并未为此处定义的兼容性级别定义任何关联的语义（请参见10.1节）。

在RFC2518中，Depth标头的定义（第9.2节）要求，默认情况下，请求中的所有标头将应用于范围内的每个资源。根据实施经验，默认设置现已撤销（请参见第10.2节）。

由于缺乏实现，已删除了HTTP状态代码102（[RFC2518]，第10.1节）和Status-URI响应标头（第9.7节）的定义。

Timeout请求标头中使用的TimeType格式和XML元素中的“timeout”曾经是可扩展的。现在，仅允许使用本规范定义的两种格式（请参见10.7节）。