Annexe A. Changements par rapport au RFC 2616

La spécification a été largement réécrite pour plus de clarté.

Les conditions dans lesquelles une réponse authentifiée peut être mise en cache ont été clarifiées. (Section 3.2)

De nouveaux codes d'état peuvent désormais définir que les caches sont autorisés à utiliser la fraîcheur heuristique avec eux. Les caches sont désormais autorisés à calculer la fraîcheur heuristique pour les URI comportant des composants de requête. (Section 4.2.2)

L'algorithme de calcul de l'âge est désormais moins conservateur. Les caches doivent désormais traiter les dates comportant des fuseaux horaires comme si elles étaient invalides, car il n'est pas possible de les deviner avec précision. (Section 4.2.3)

Le champ d'en-tête de réponse Content-Location n'est plus utilisé pour déterminer la réponse appropriée à utiliser lors de la validation. (Section 4.3)

L'algorithme de sélection d'une réponse négociée mise en cache à utiliser a été clarifié à plusieurs égards. En particulier, il autorise désormais explicitement la canonisation propre à un en-tête lors du traitement des champs d'en-tête de sélection. (Section 4.1)

Les exigences relatives à la prévention des attaques par déni de service lors de l'invalidation ont été clarifiées. (Section 4.4)

L'invalidation du cache ne se produit que lorsqu'une réponse réussie est reçue. (Section 4.4)

Les directives de cache sont explicitement définies comme insensibles à la casse. Le traitement de plusieurs occurrences de directives de cache alors qu'une seule est attendue est désormais défini. (Section 5.2)

La directive de requête « no-store » ne s'applique pas aux réponses ; autrement dit, un cache peut satisfaire une requête comportant no-store et ne l'invalide pas. (Section 5.2.1.5)

Il est noté que les formes qualifiées des directives de cache private et no-cache ne sont pas largement implémentées ; par exemple, « private=foo » est interprété par de nombreux caches comme simplement « private ». De plus, la signification de la forme qualifiée de no-cache a été clarifiée. (Section 5.2.2)

La signification de la directive de réponse « no-cache » a été clarifiée. (Section 5.2.2.2)

La limite d'un an sur les valeurs du champ d'en-tête Expires a été supprimée ; à la place, le raisonnement justifiant l'emploi d'une valeur raisonnable est donné. (Section 5.3)

Le champ d'en-tête Pragma n'est désormais défini que pour la compatibilité descendante ; les pragmas futurs sont obsolètes. (Section 5.4)

Certaines exigences concernant la production et le traitement des champs d'en-tête Warning ont été assouplies, car ce n'est pas largement implémenté. En outre, le champ d'en-tête Warning n'utilise plus l'encodage RFC 2047 et n'autorise plus plusieurs langues, car ces aspects n'ont pas été implémentés. (Section 5.5)

Cette spécification introduit les registres des directives de cache et des codes d'avertissement, et définit des considérations pour les nouvelles directives de cache. (Section 7.1 et Section 7.2)