Skip to main content

RFC 4918 附录技术要点

本文档总结RFC 4918附录A-F的关键内容。

Appendix A. Processing XML Elements (处理XML元素的注意事项)​

关键要点​

1. XML解析要求:

  • 必须使用符合W3C标准的XML解析器
  • 必须支持XML命名空间
  • 必须处理格式良好的XML

2. 未知元素处理:

  • 客户端和服务器必须忽略不认识的XML元素
  • 这确保了向前兼容性
  • 扩展不会破坏现有实现

3. 空白处理:

  • 属性值中的空白是有意义的
  • 必须保留属性值中的空白
  • 忽略xml:space属性

4. 安全考虑:

  • 禁用外部实体以防止XXE攻击
  • 限制XML文档大小
  • 限制解析深度

Appendix B. HTTP Client Compatibility (HTTP客户端兼容性注意事项)​

兼容性指南​

1. HTTP/1.1客户端:

  • 基本的HTTP/1.1客户端可以访问WebDAV资源
  • 但无法使用WebDAV特定功能（锁定、属性等）
  • 使用标准HTTP方法（GET、PUT、DELETE）

2. 部分WebDAV支持:

  • 客户端可以实现WebDAV的子集
  • 应该通过OPTIONS发现服务器能力
  • 优雅降级到HTTP/1.1功能

3. 互操作性:

  • 遵循HTTP规范
  • 正确处理重定向
  • 支持持久连接

Appendix C. The 'opaquelocktoken' Scheme (opaquelocktoken方案和URI)​

opaquelocktoken URI方案​

定义: 专门用于WebDAV锁令牌的URI方案

语法:

opaquelocktoken:<UUID>

示例:

opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

特性:

  • 全局唯一: 使用UUID确保唯一性
  • 不透明: 客户端不应该解析其内部结构
  • URL安全: 可以在HTTP头和XML中使用

使用场景:

  • LOCK方法返回的锁令牌
  • If头中提交的锁令牌
  • Lock-Token头中指定的锁令牌

与其他URI的区别:

  • 不可解引用（没有对应的资源）
  • 仅用于标识锁
  • 生命周期与锁相同

Appendix D. Lock-null Resources (锁空资源)​

锁空资源（LNR）概念​

定义: RFC 2518中定义的特殊资源类型，通过对未映射URL进行LOCK创建。

RFC 4918的变化:

  • RFC 4918推荐使用"锁定的空资源"而不是LNR
  • 但为了向后兼容，服务器可以继续支持LNR

锁定空资源 vs LNR​

特性锁定空资源 (推荐)Lock-Null Resource (兼容)
创建方式LOCK未映射URLLOCK未映射URL
GET行为返回200和空内容返回404
属性正常资源属性特殊LNR属性
可见性作为集合成员可见可能不可见
MKCOL失败（405）转换为集合

客户端兼容性建议:

  • 对未映射URL执行LOCK后，使用PUT添加内容
  • 不依赖GET或MKCOL的特定行为
  • 不依赖LNR的特定属性

Appendix E. Guidance for Clients Desiring to Authenticate (希望进行认证的客户端指南)​

认证发现​

问题: 客户端如何发现资源需要认证？

方法1 - 主动OPTIONS请求:

OPTIONS /resource HTTP/1.1
Host: example.com

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="WebDAV"

方法2 - 尝试操作并处理401:

PROPFIND /resource HTTP/1.1
Host: example.com

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest realm="WebDAV"

认证最佳实践​

1. 支持多种认证方案:

  • Basic认证（需要HTTPS）
  • Digest认证
  • OAuth 2.0 Bearer tokens
  • 客户端证书

2. 缓存认证凭据:

  • 为同一realm缓存凭据
  • 实施适当的超时
  • 安全存储敏感信息

3. 处理认证失败:

  • 提供清晰的错误消息
  • 允许重新认证
  • 避免锁定用户账户

4. 安全考虑:

  • 总是使用HTTPS传输凭据
  • 不在URL中包含密码
  • 实施速率限制防止暴力破解

Appendix F. Summary of Changes from RFC 2518 (与RFC 2518的变更摘要)​

RFC 4918废弃了RFC 2518，主要变更包括：

F.1 客户端和服务器实现的变更​

1. 移除锁空资源 (LNR):

  • 推荐使用"锁定的空资源"
  • 简化了实现
  • 提高了互操作性

2. If头语法澄清:

  • 更清晰的匹配规则
  • 改进的示例
  • 消除歧义

3. 集合行为:

  • 澄清了DELETE对集合的行为
  • 明确了Depth头的使用
  • 改进了错误处理

4. 属性处理:

  • 澄清了活属性 vs 死属性
  • 改进了PROPPATCH的原子性要求
  • 明确了属性值的XML处理

F.2 服务器实现的变更​

1. 207 Multi-Status响应:

  • 更严格的格式要求
  • 改进的错误报告
  • 必需的href元素

2. 锁定行为:

  • 澄清了锁刷新机制
  • 改进了超时处理
  • 明确了锁令牌提交要求

3. COPY/MOVE语义:

  • 澄清了Overwrite头行为
  • 改进了目标资源处理
  • 明确了锁的影响

F.3 其他变更​

1. 安全性增强:

  • 添加了XML安全指南
  • 改进了DoS防护建议
  • 明确了认证要求

2. 互操作性改进:

  • 更清晰的规范
  • 更多的示例
  • 消除了实现歧义

3. 废弃的功能:

  • 某些RFC 2518的可选功能
  • 简化了合规性要求
  • 减少了实现负担

附录总结​

附录提供了以下关键信息：

  1. 实现指南 (A, B): XML处理和HTTP兼容性
  2. 技术细节 (C, D): 锁令牌URI方案和锁空资源
  3. 实践建议 (E): 认证实现指南
  4. 演进历史 (F): 从RFC 2518到RFC 4918的变更

这些附录对于实现高质量的WebDAV客户端和服务器非常有价值。

Last updated on