付録 A. RFC 2616 からの変更点

本仕様は、明確さのために大幅に書き直されました。

認証された応答をキャッシュできる条件が明確化されました。(セクション 3.2)

新しいステータスコードは、キャッシュがそれらに対してヒューリスティックな新鮮度を使用することを許可すると定義できるようになりました。キャッシュは、クエリコンポーネントを持つ URI についてもヒューリスティックな新鮮度を計算できるようになりました。(セクション 4.2.2)

年齢を計算するアルゴリズムは、以前よりも保守的でなくなりました。正確に推測することが不可能であるため、キャッシュはタイムゾーン付きの日付を無効であるかのように扱うことが要求されるようになりました。(セクション 4.2.3)

検証時に使用する適切な応答を決定するために、Content-Location 応答ヘッダーフィールドが使用されなくなりました。(セクション 4.3)

使用するキャッシュされたネゴシエーション済み応答を選択するアルゴリズムが、いくつかの点で明確化されました。特に、選択ヘッダーフィールドを処理する際に、ヘッダー固有の正規化を明示的に許可するようになりました。(セクション 4.1)

無効化を行う際のサービス妨害攻撃の回避に関する要件が明確化されました。(セクション 4.4)

キャッシュの無効化は、成功した応答を受信したときにのみ発生します。(セクション 4.4)

キャッシュディレクティブは、明示的に大文字と小文字を区別しないものと定義されました。1 つだけが期待される場合にキャッシュディレクティブの複数のインスタンスを処理する方法が定義されました。(セクション 5.2)

"no-store" リクエストディレクティブは応答には適用されません。つまり、キャッシュは no-store が付いたリクエストを満たすことができ、それを無効化しません。(セクション 5.2.1.5)

private および no-cache キャッシュディレクティブの限定形式は、広く実装されていないことが指摘されています。例えば、"private=foo" は多くのキャッシュによって単に "private" として解釈されます。さらに、no-cache の限定形式の意味が明確化されました。(セクション 5.2.2)

"no-cache" 応答ディレクティブの意味が明確化されました。(セクション 5.2.2.2)

Expires ヘッダーフィールドの値に対する 1 年間の制限が削除されました。代わりに、妥当な値を使用する理由が示されています。(セクション 5.3)

Pragma ヘッダーフィールドは、後方互換性のためだけに定義されるようになりました。将来の pragma は非推奨です。(セクション 5.4)

Warning ヘッダーフィールドの生成と処理に関する一部の要件は、広く実装されていないため緩和されました。さらに、Warning ヘッダーフィールドは RFC 2047 符号化を使用しなくなり、複数言語も許可しません。これらの側面は実装されなかったためです。(セクション 5.5)

本仕様は、キャッシュディレクティブレジストリと警告コードレジストリを導入し、新しいキャッシュディレクティブに関する考慮事項を定義します。(セクション 7.1 およびセクション 7.2)