ETagの生成および設定方法は？

Question

私は最近、ETag HTTPヘッダーという概念を経験しました。 （this）しかし、ETagsを生成する責任がある特定のHTTPリソースに対してはまだ問題がありますか？

つまり、実際のアプリケーション、コンテナ（例：Tomcat）、Webサーバー/ロードバランサ（例：Apache/Nginx）ですか？

誰でもお手伝いできますか？

Answer 1

HTTP仕様のほとんどの側面と同様に、責任は最終的にリソースを提供している人にあります。

もちろん、我々はそれらの責任を果たすのに役立つツール - サーバ、ロードバランサ、アプリケーションフレームワークなどを使用することがあります。しかし、アプリケーションとは対照的に "Webサーバー"が提供することが予想される仕様を定義する仕様はありません。使用しているツールでどの機能が利用できるかは現実的な問題です。

特に、ETagsを見ると、フレームワークまたはWebサーバーが自動的にレスポンス（本文やその他のもの）をハッシュし、その結果をETagに入れることが一般的な状況です。次に、条件付き要求では、レスポンスを生成し、ハッシュして変更があったかどうかを調べ、条件付きレスポンスを自動的に送信します。

私がよく知っている2つの例を挙げると、Webサーバーレベルの静的ファイルのあるnginx can do thisと、アプリケーションレベルの動的応答のDjango can do thisがあります。

このアプローチは一般的で、設定が簡単で、うまく機能します。ただし、状況によっては、ユースケースに最適なものではない場合もあります。たとえば、

• 入力したETagと比較するためにハッシュを計算するには、まずレスポンスが必要です。したがって、条件付き応答はの応答を送信するのオーバーヘッドを節約できますが、の応答を生成するコストを節約できません。したがって、応答が高価で、代替ソースがETags（たとえば、データベースに格納されているバージョン番号）の場合は、これを使用してパフォーマンスを向上させることができます。
• ETags〜prevent accidental overwrites with state-changing methodsを使用する予定がある場合は、おそらく、独自のアプリケーションコードを追加して、比較および設定ロジックをアトミックにする必要があります。

したがって、状況によっては、アプリケーションレベルでETagsを作成することができます。 Djangoを再び例に取るために、provide your own functionにはETagsを計算するための簡単な方法が用意されています。

あなたがコントロールするリソースにはETagsを提供することが最終的にはあなたの責任ですが、あなたのソフトウェアスタックのツールを活用して、あなたのためにできることは間違いありません。