構文
[46] 作成の要求の payload body は XML でなければなりません >>40。
lockinfo 要素を根要素とする文書が想定されているようです。
[51] 更新の要求は payload body を持ってはなりません >>40, >>35。
[52] 更新の要求は If: ヘッダーにロックトークンを1つだけ指定しなければなりません >>40, >>35。
[48] 通常の要求も更新の要求も、 Timeout:
ヘッダーを指定しても構いません >>40, >>75。
[58] Depth: 0 または Depth: infinity
を指定することができますが、それ以外を使ってはなりません >>40。
[78] DAV: 名前空間の lockinfo
要素は、作成したいロックの種類を指定します >>77。
[79] lockinfo 要素の内容は要素内容で、
lockscope 要素、
locktype 要素、
owner 要素を指定します >>77。
順序は意味を持ちません >>83。
ただし owner 要素は省略できます >>77。
処理
[85] WebDAV 適合クラス 2 に対応する資源は、
LOCK メソッドに対応しなければなりません >>84。
[43] LOCK メソッドに対応する資源は、
最低でも WebDAV の XML 形式の要求・応答に対応しなければなりません
>>40。成功した場合には prop 要素を根要素とする
XML文書を応答とすることが想定されているようです。
[45] 対象資源が既に衝突するロックの対象となっていなければ、
対象URLをロック根とするロックを作成します >>40, >>11。
[38] 鯖は本体が空の LOCK 要求を受信したら、
新しいロックを作ってはなりません。その場合は少なくても既存のロックをリセットして「更新」しなければなりません。 >>35
[73] If: が指定された場合で対象資源がその範囲内にない場合
(ロックの範囲外である場合、既に破棄された場合、不正なロックトークンの場合など)
には、 412 応答を返すことができます。
応答には事前条件符号 lock-token-matches-request-uri
を指定できます。 >>40
[50] 要求に Timeout: ヘッダーが含まれていれば、
その値を元に新しいタイムアウトを決めることができます >>40, >>75。
ロックタイムアウトも参照。[39] クライアントは LOCK 要求による更新にエラーが返された時、
ロックが更新されたと仮定してはなりません >>35。
[10] ある資源の URL に対する LOCK
要求で新しいロックが作られるなら、その資源は直接ロックされます。 >>6
[59] LOCK メソッドに対応する場合は、
Depth: ヘッダーにも対応しなければなりません >>40。
WebDAV コレクションに対する LOCK
要求では、 Depth: ヘッダーの値により適用範囲を決定します。
Depth: ヘッダーが指定されなかった場合には、
Depth: infinity が指定されたとみなさなければなりません
>>40。
[60] Depth: 0 は対象資源のみをロックすることを意味します
>>40。
Depth: infinity の場合には、
対象資源とそのメンバーを (再帰的にすべて) ロックします >>40。
深さ無限のロックによりロックされているコレクションは、
そのメンバーである資源すべてが間接的にロックされます >>6。
[62] 階層の一部のみをロックすることはできず、
ロックは全体として成功するか失敗するかのいずれかのみです >>40。[54] 更新の要求の場合には、 Depth: ヘッダーを無視しなければなりません >>40。
[8] ロックされているコレクションについて新しい資源をメンバーとするとき、
その資源もコレクションのロックによって間接的にロックしなければなりません。
その資源は既に衝突するロックを有していてはなりません。 >>6, >>33
[9] 排他的ロックは、同じ資源の直接または間接のいかなる種類のロックとも衝突します。
鯖は、ある資源において衝突するロックを作ってはなりません。 >>6
- [66] ロックされていなければ、ロックを作成できます >>40。
- [67] 共有ロックされていれば、共有ロックを作成できます >>40。
- [68] 共有ロックされていれば、排他ロックを作成してはなりません >>40。
- [69] 排他ロックされていれば、ロックしてはなりません >>40。
429 も参照。[72] 対象資源が衝突によりロックできない場合には、 423
応答を返すことができます >>40。
[55] 更新の要求の場合には、ロックを更新しても他のロックは影響を受けませんし、
他のロックによって更新が妨げられることもありません >>40。
[23] ロックを作成した principal は、そのロックのロック作成者となります。
鯖はロックを作成できる principal を制限しても構いません >>6。
鯖は、要求の owner 要素で指定された情報を保持しなければなりません >>40。
[49] 応答には、 prop 要素を含め、そこに
DAV:lockdiscovery 特性として作成したロックの情報を含めなければなりません >>40。
更に他のロックの情報も含めて構いません >>40。
prop
DAV:lockdiscovery
[19] ロックに成功したら、 (再帰的にロックした場合でも)
ロックトークンを1つだけ返さなければなりません >>40。
応答の Lock-Token: ヘッダーにはロックトークンを指定しなければなりません >>40, >>74。
ロックトークンは応答の本体でもクライアントに通知されます。
[56] 更新の要求に対する応答では、 Lock-Token:
ヘッダーは返しません >>40。
[57] 更新の要求に対する応答の DAV:lockdiscovery
特性には新しいロックトークンの値を含めなければなりません >>40。
[81] 応答には lockroot 要素を含めるべきです >>80。
[24] ロックを作成すると、鯖はロックタイムアウトの値を決めて計測を開始します。
[70] 既存の資源をロックした場合は、 DAV:lockdiscovery
特性を含む 200 応答を返すことができます >>40。
[14] 写像がない URL をロックした場合、空の資源
(ロックされた空の資源) を新たに作らなければなりません >>40, >>6, >>7。
[31] 鯖は、 RFC 2518 との互換性のため、空の資源でなく
LNRs (Lock-Null Resources) を実装しても構いません >>7。
[71] ただしいくつかの中間のコレクションが存在しない場合は、これを自動的に作ってはなりません。
409 応答を返すことができます。 >>40
[32] クライアントは、 LNR と locked empty resource
のどちらを鯖が実装していても、写像のない URL をロックしたら直ちに
PUT することや、 LNR 特有の特性に依存しないことで、
相互運用できます >>7。[30] クライアントは応答の後すぐに PUT や
PROPPATCH でロックした資源を更新することが期待されています >>7。[29] 空の資源を作成した場合の応答は、 201 でなければなりません >>7。
3xx を返してはなりません >>76。
応答には DAV:lockdiscovery 特性を含める必要があります >>7。
[63] 一部の資源についてロックできなかった場合は、
ロックはすべて作成できなかったこととなりますが、
207 応答を返して、ロックを作成できない原因となった資源最低1つの
response 要素を含めなければなりません。
その場合には失敗を表す適切な状態符号を使います。 >>40
書き込みロックが要求された場合で、
新しいロックと衝突する形でロックされている資源のメンバーURLがコレクションに含まれる場合には、
423 応答によりエラーを返さなければなりません >>33。
その他 403 など適切な状態符号を使うこともできます >>40。
原因が対象資源以外の場合には、対象資源についての response
要素も含めて、その状態符号は 424 とするべきです
>>40。
[34] 状態符号が 423 の場合には事前条件符号
no-conflicting-lock >>82 を含めるべきです。 >>33, >>40
[44] 応答は、キャッシュ不可能です >>40。