https://uga-box.hatenablog.com/entry/2020/12/07/000000

HTTP/1.1には仕様が新旧2つあって、この新旧の違いとしてCache-Controlが明確にHop-by-hopではないという記述がなくなったという話を聞いたのでメモしておく

古い方のRFC 2616ではHop-by-hopのヘッダーの記述がある

https://tools.ietf.org/html/rfc2616#section-13.5.1

The following HTTP/1.1 headers are hop-by-hop headers:

      - Connection
      - Keep-Alive
      - Proxy-Authenticate
      - Proxy-Authorization
      - TE
      - Trailers
      - Transfer-Encoding
      - Upgrade

ここにCache-Controlヘッダは含まれていないのでEnd-to-endヘッダということになる

ただ、これだと新しいHop-by-hopヘッダを追加することが困難になるので、Connectionヘッダに列挙したものはHop-by-hopヘッダになることが決められている

HTTP/1.1の新しいRFC 7230では、Hop-by-hopヘッダの列挙の記述がなくなった

Hop-by-hopヘッダは全てConnectionヘッダに列挙することが求められるようになった

変更点
https://tools.ietf.org/html/rfc7230#appendix-A.2

そのため、ヘッダの名前だけ見てEnd-to-endかHop-by-hopかは言えなくなった

しかし、Cache-ControlはConnectionヘッダに列挙するなと記載されているので、実質Hop-by-hopヘッダではない

A sender MUST NOT send a connection option corresponding to a header field that is intended for all recipients of the payload. For example, Cache-Control is never appropriate as a connection option (Section 5.2 of [RFC7234]).

Cache-ControlはEnd-to-endではあるがCDN等プロキシのキャッシュを想定しているもののある

Cache-Controlが想定しているキャッシュには「Private」キャッシュ (ブラウザのキャッシュ) と「Shared」キャッシュ (CDN等プロキシのキャッシュ) があり、ディレクティブ毎にどちらのキャッシュに適用されるかが決められている

例えば、privateの場合はCDN等プロキシのキャッシュでの保存の禁止になるため、Cache-Controlヘッダに関してはヘッダ自体がEnd-to-endということは重要ではなく、ディレクティブ毎にEnd to End か Hop By Hop を意識すべき