1. Introduction (Introduction)
HTTP est généralement utilisé pour les systèmes d'information distribués dans lesquels les performances peuvent être améliorées par l'utilisation de caches de réponses. Ce document définit les aspects de HTTP/1.1 liés à la mise en cache et à la réutilisation des messages de réponse.
Un cache HTTP est un stockage local pour les messages de réponse et le sous-système qui contrôle le stockage, la récupération et la suppression des messages qu'il contient. Un cache stocke les réponses pouvant être mises en cache afin de réduire le temps de réponse et la consommation de bande passante réseau pour les demandes équivalentes futures. Tout client ou serveur PEUT (MAY) utiliser un cache, bien qu'un serveur agissant comme un tunnel ne puisse pas utiliser un cache.
Un cache partagé (Shared Cache) est un cache qui stocke des réponses destinées à être réutilisées par plus d'un utilisateur; les caches partagés sont généralement (mais pas toujours) fournis dans le cadre d'un intermédiaire. Un cache privé (Private Cache), en revanche, est dédié à un seul utilisateur; ils sont souvent fournis en tant que composant d'un agent utilisateur.
L'objectif de la mise en cache dans HTTP/1.1 est d'améliorer considérablement les performances en réutilisant un message de réponse antérieur pour satisfaire une demande actuelle. Une réponse stockée est considérée comme « fraîche » (Fresh), comme défini à la section 4.2, si la réponse peut être réutilisée sans « validation » (Validation) (vérification auprès du serveur d'origine que la réponse en cache est toujours valide pour cette demande). Une réponse fraîche peut donc réduire à la fois la latence et la surcharge réseau à chaque réutilisation. Si une réponse en cache n'est pas fraîche, elle peut néanmoins rester réutilisable si elle peut être actualisée par validation (section 4.3) ou si l'origine n'est pas disponible (section 4.2.4).
1.1. Conformité et gestion des erreurs (Conformance and Error Handling)
Les mots-clés « MUST », « MUST NOT », « REQUIRED », « SHALL », « SHALL NOT », « SHOULD », « SHOULD NOT », « RECOMMENDED », « MAY » et « OPTIONAL » dans ce document doivent être interprétés comme décrit dans [RFC2119].
Les critères de conformité et les considérations de gestion des erreurs sont définis à la section 2.5 de [RFC7230].
1.2. Notation syntaxique (Syntax Notation)
Cette spécification utilise la notation ABNF (Augmented Backus-Naur Form) de [RFC5234] avec une extension de liste définie dans la section 7 de [RFC7230] qui permet une définition compacte des listes séparées par des virgules en utilisant un opérateur '#' (de manière similaire à l'opérateur '*' qui indique la répétition). L'annexe B décrit les règles importées d'autres documents. L'annexe C montre la grammaire collectée avec tous les opérateurs de liste développés en notation ABNF standard.
1.2.1. Secondes delta (Delta Seconds)
La règle delta-seconds indique un entier non négatif représentant le temps en secondes.
delta-seconds = 1*DIGIT
Un récepteur analysant une valeur delta-seconds et la convertissant en forme binaire devrait (ought to) utiliser un type arithmétique d'au moins 31 bits de plage d'entiers non négatifs. Si un cache reçoit une valeur delta-seconds plus grande que le plus grand entier qu'il peut représenter, ou si l'un de ses calculs ultérieurs déborde, le cache DOIT (MUST) traiter la valeur soit comme 2147483648 (2^31), soit comme le plus grand entier positif qu'il peut représenter commodément.
Note : La valeur 2147483648 existe pour des raisons historiques et représente l'infini (plus de 68 ans), plutôt que d'être stockée sous forme binaire; les implémentations peuvent la générer comme une chaîne fixe lorsqu'un débordement se produit, même si le type arithmétique utilisé pour les calculs ne peut pas représenter directement ce nombre. Ce qui est important ici est que le débordement a été détecté et n'est ensuite pas traité comme une valeur négative.