HTTPでキャッシュは、サーバがHTTPレスポンスを返す際、Cache-Controlヘッダをつけることで、どのようにキャッシュするか指示することができます。ヘッダ自体はレスポンスボディより前に送る必要があります。
Mark Nottingham氏らによって提案された「Updating HTTP Caching Policy in Trailers」という仕様では、HTTPレスポンスボディを送り終わってから、Cache-Controlを変更可能にします。
具体的には、Trailer FieldでCache-Controlを送った際の挙動について定義を与えています。
HTTP Trailer Field
まずは、Trailer Fieldについて説明します。
HTTPのセマンティクスの仕様(URL)では、HTTPボディを送ったあとにあとからヘッダ(正確にはFieldと呼ぶ)を送ることができます。これをTrailerと呼びます。HTTPセマンティクスで定義されていますので、HTTP/1.1 ~ HTTP/3どれでも使うことができます。
余談ですが、ヘッダ という呼び方は不正確ですので、ヘッダフィールド、トレーラフィールドという呼び方について別記事を書いています。ご参照いただければと思います。
qiita.com
Updating HTTP Caching Policy in Trailers
この仕様では、トレーラフィールドでCache-Controlを送りキャッシュ制御を更新する手順を定義しています。
具体例とともに見ていきましょう。
HTTP/1.1 200 OK Content-Type: text/html Cache-Control: no-store; trailer-update [body] Cache-Control: max-age=3600
- ヘッダフィールドでは、Cache-Controlヘッダにtrailer-updateディレクティブを使用し、トレーラにCache-Controlがあることを示唆します。それまでは、no-storeとして扱わせます。
- レスポンスボディを送信します
- サーバはレスポンスボディを送り終わったら、トレーラでmax-age=3600とし、キャッシュを指示します。(トレーラのCache-Controlで、ヘッダのCache-Controlを置き換える)
これがどのようなケースに役に立つかと言うと、レスポンスボディを動的に生成しながらクライアントに返し始めるケースです。レスポンスボディを生成しながら返し始めているので、送ってる途中でサーバ側で不具合が起こってしまった場合などは、そのコンテンツはキャッシュをしてほしくありません。今回の提案仕様を用いれば、問題なくレスポンスボディが生成し終わったら、あらためてキャッシュの許可を出すことができます。
なお、trailer-updateを認識できないクライアントからは単純に無視されるだけです。
