メインコンテンツまでスキップ

RFC 4918 附録技術要点 (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 (互換性)
作成方法マッピングされていないURLをLOCKマッピングされていないURLをLOCK
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トークン
  • クライアント証明書

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クライアントとサーバーを実装するために非常に価値があります。

に最終更新