クライアントキャッシュでHTTPのEtagの意味があまり感じられません。

Question

Flask(werkzeug)のetag周りのソースコードを見てみると、etag周りの処理は以下のようになっています。

1. responseオブジェクトを生成
2. そのレスポンスデータからetagをsha1で生成
3. リクエストのif-none-matchがあれば、そのetagと比較し、一致すれば304、違えば200とともにレスポンスデータを返す

つまり、レスポンスするのにDB等にアクセスが必要な場合、その処理はetagがあってもなくても同じで、etagのメリットはクライアントにデータを送らなくていいだけということだと認識しています。

したがって、データ量が多ければメリットはありますが、それほどデータが大きくない場合はあまり意味がないと考えていいのでしょうか。多くの小さなAPIはそこまで大きなデータを返さないと思うので個人開発などそのレベルならあまり意味がないのでしょうか。

一つ思ったのは、リクエストの度にレスポンスからetagを再作成するのではなく、リクエストの対象となるオブジェクトに変更があった際に、redisやサーバーのメモリなどにetagを予め保存しておき、リクエスト時にその保存しておいたetagと比較すれば毎回レスポンスを作る処理が省けると思ったのですが、このようなキャッシュの方法はあまり使われないのでしょうか？

ご教授いただけると幸いです。

Answer 1

例えば Apache だと Etag 生成は静的ファイルかつ、ファイルサイズ・最終更新時刻から生成される (昔は inode も含む) だったと思いますので、werkzeug の実装がほんとうにそうであるならば Etag そのものの問題ではなく werkzeug の問題だと思います。

また、Etag には weak Etag という概念があり、正確性重視かパフォーマンス重視かの選択肢はあります (それを実装するかどうかは Web サーバ次第)。

またもし動的ページの Etag 生成とキャッシュがサーバ側で行われるとしたら、現実的な可能性がどれくらいかはおいておくとしてたまたま Etag が一致して他人のログイン画面が返されるリスクがありますね (一般的には Cache-Control: no-store でコントロールするものと思いますが)。