If-Unmodified-Sinceが野生で実際に使用されていることはご存じですか？ descriptionから、このヘッダーは汚れた書き込みを回避するのに役立つと思われます。クライアントが最後に変更された時間以降に変更されていない場合にのみ、このリソースを更新する。 If-Modified-Sinceとは異なり、キャッシングには役立たないようです。何か不足していますか？If-Unmodified-Since HTTPヘッダーの使用方法は？
たとえば、 range requestの場合
例：クライアントはリソースhttp://examp.le/foo?id=3を要求し、コンテンツ長は4096ですが、クライアントは最初の1024バイトしか要求しません。その後、（後で）残りの3072バイトを要求することができますが、その間にリソースが変更された場合は意味がありません。
編集：一方でリソースが変更された場合は、データを変更/更新したくない場合もあります。例えば。お客様のレコードを要求して何かを編集します。その間に他の誰かがレコードを変更した場合、これは矛盾を引き起こす可能性があります。したがって、レコードが既に変更されている場合は、変更されていない場合（-I取得データ）のヘッダーを使用して更新を送信し、Webサーバーは更新を拒否する必要があります。
edit2：「野生でIf-Unmodified-Sinceの実用」を依頼しているので： http://msdn.microsoft.com/en-us/library/dd179371.aspx#Subheading1を参照してください。
まずはrequested the Blob propertiesとしましょう。今あなたは知っている。 Content-typeとContent-length（何らかの割り当てのためにこれが必要かもしれません）。誰か/何かが、あなたが2番目に、Get Blobリクエストを送る前に、ブロブを変更するかもしれません。 Last-Modifiedの値をIf-Unmodified-Sinceヘッダーの値として送信すると、BLOBが変更された場合、サーバーは適切なエラーコードで応答します。
与えられた場所の天気を示すアプリケーションを開発しているとします。サーバーが気象情報を「x」日だけ更新する場合、ブラウザーはその時間枠内で（更新があっても）http要求を行わないように注意します。
大きなダウンロードを再開するときに便利です。
1つの変更されていないリソースに関連して、一定期間にわたって実行される複数のリクエストに役立ちます。
例：
範囲要求。最初の範囲リクエスト（または予備のHEAD）に対する応答には、Last-Modifiedヘッダーが含まれています。後続のリクエストは、そのリソースの同じバージョンのみを対象としています。範囲リクエストのシーケンスを開始してからシーケンスの途中でリソースが変更された場合、最初からやり直したいと思っています。
楽観的同時実行制御。我々は最初にGETリソースを変更し、クライアント側にいくつかの変更を加え、PUT更新されたリソースにします。しかし、その間に誰も更新していない限り、更新されたリソースはPUTにしかなりません。私たちは誰の変更も上書きしたくありません。その間に誰かがリソースを変更してしまった場合は、GETにもう一度、変更内容を再度適用して（git rebaseのような）、変更されたリソースをもう一度試してみてください（git rebase）。
私の最初のところは、「並行性制御」でした。範囲の要求についてよく捉えてください！ – rix0rrr
これは同時実行制御に適しています。私はなぜこの答えが非常に高い票を持っているのかわかりませんが、範囲ヘッダーは範囲要求にもっと適しています。例えば範囲：bytes = 1024- – sotn
@sotn OPは「野生でIf-Unmodified-Sinceの実用」を求めていたので、私は答えとしてコンセプトを出していませんでしたが、並行制御の例は2.5でした。しかし、あなたが正しいかもしれません。別の小さな段落が追加されます。 – VolkerK