仕様書

意味

[3] LOCK 要求の要求URLが資源に写像されていない URL である場合、鯖は新しい資源を作ることになっています。 RFC 2518 ではこれは「ロック null 資源」 (LNR) を作ることとなっていました。 しかし複雑すぎて相互運用性と実装の問題があった >>1 として、 RFC 4918 ではロックされた空の資源を原則とし、 非推奨deprecated >>1 ながら互換性のために LNR を使っても良いこととしています。

鯖の動作

[5] LNR は、PUT、MKCOL、 OPTIONS、PROPFIND、 LOCK、UNLOCK を除き、 404 か 405 を返して存在しないように振る舞います >>1。

[6] LNR は、親のコレクションのメンバーとして現れます >>1。

[8] LNR は、 PUT が成功すると通常の資源に変換されます >>1。

[9] LNR は、 MKCOL が成功するとコレクションに変換されます >>1。

[7] LNR は、ロックが破棄された時点で通常の資源に変換されていなければ、 削除されます。ここでロックの破棄には、満期や UNLOCK の他、自身や親のコレクションの移動に伴うものも含まれます。 >>1

[11] LNR では DAV:lockdiscovery と DAV:supportedlock が定義されますが、 他の特性は定義される必要はありません >>1。

[13] LOCK 要求に対する応答のみから LNR かロックされた空の資源かを判定する方法はありません >>1。

クライアントの動作

[4] クライアントはロックされた空の資源も LNR も扱えなければなりません >>1。

[12] クライアントは LOCK の後 PUT のみ行い、 MKCOL や GET を使わないことで、ロックされた空の資源も LNR も扱えます >>1。

[15] LOCK 要求でどちらの種類でも新しい資源を作りたくない時には、 If-Match: * を指定することができます >>1。

[14] LOCK 要求で資源を作成して直後に COPY や MOVE で上書きしたい時は、 Overwrite: T を要求に指定するべきです >>1。

[16] LOCK 要求で新しい資源を作ったものの、 それを削除したい時は、 LNR では DELETE が存在しないとみなして失敗しますし、 ロックされた空の資源では UNLOCK で自動的に削除されることがないので、 UNLOCK と DELETE の両方を送信し、一方のみでエラーになっても無視すると良いです >>1。