1. Introduction

Le protocole de transfert hypertexte (Hypertext Transfer Protocol, HTTP) est un protocole de requête/réponse sans état au niveau de la couche application qui utilise une sémantique extensible et des messages auto-descriptifs pour une interaction flexible avec les systèmes d'information hypertexte basés sur le réseau. HTTP est couramment utilisé dans les systèmes d'information distribués où l'utilisation de caches de réponse (Response Caches) peut améliorer les performances. Ce document définit les aspects de HTTP liés à la mise en cache et à la réutilisation des messages de réponse.

Un "cache (Cache)" HTTP est un stockage local de 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 futures requêtes équivalentes. Tout client ou serveur peut (MAY) utiliser un cache, sauf lorsqu'il agit en tant que tunnel (Tunnel) (voir la section 3.7 de [HTTP]).

Un "cache partagé (Shared Cache)" est un cache qui stocke des réponses pour être réutilisées par plusieurs utilisateurs ; les caches partagés sont généralement (mais pas toujours) déployés en tant que partie d'un intermédiaire (Intermediary). En revanche, un "cache privé (Private Cache)" est dédié à un seul utilisateur ; généralement, ils sont déployés en tant que composants d'un agent utilisateur (User Agent).

L'objectif de la mise en cache HTTP est d'améliorer considérablement les performances en réutilisant les messages de réponse précédents pour satisfaire les requêtes actuelles. Comme défini dans la section 4.2, un cache considère une réponse stockée comme "fraîche (Fresh)" s'il peut réutiliser la réponse stockée sans "validation (Validation)" (c'est-à-dire vérifier auprès du serveur d'origine si la réponse mise en cache est toujours valide pour cette requête). Ainsi, chaque fois qu'un cache réutilise une réponse fraîche, la latence et la charge réseau peuvent être réduites. Lorsqu'une réponse mise en cache n'est pas fraîche, elle peut toujours être réutilisable si la validation peut la rafraîchir (section 4.3) ou si le serveur d'origine n'est pas disponible (section 4.2.4).

Ce document rend obsolète le RFC 7234, avec un résumé des changements dans l'annexe B.

1.1 Requirements Notation (Notation des exigences)

Les mots-clés "doit (MUST)", "ne doit pas (MUST NOT)", "requis (REQUIRED)", "doit (SHALL)", "ne doit pas (SHALL NOT)", "devrait (SHOULD)", "ne devrait pas (SHOULD NOT)", "recommandé (RECOMMENDED)", "non recommandé (NOT RECOMMENDED)", "peut (MAY)" et "optionnel (OPTIONAL)" dans ce document doivent être interprétés comme décrit dans le BCP 14 [RFC2119] [RFC8174] lorsque, et seulement lorsque, ils apparaissent en majuscules, comme indiqué ici.

La section 2 de [HTTP] définit les critères de conformité et contient des considérations concernant la gestion des erreurs.

1.2 Syntax Notation (Notation syntaxique)

Cette spécification utilise la notation Augmented Backus-Naur Form (ABNF) de [RFC5234], étendue avec la notation de chaîne sensible à la casse définie dans [RFC7405].

Elle utilise également l'extension de liste définie dans la section 5.6.1 de [HTTP], qui permet une définition compacte de listes séparées par des virgules en utilisant l'opérateur "#" (similaire à la façon dont l'opérateur "*" indique la répétition). L'annexe A montre la grammaire collectée avec tous les opérateurs de liste développés en notation ABNF standard.

1.2.1 Imported Rules (Règles importées)

Les règles de base suivantes sont incluses par référence telles que définies dans l'annexe B.1 de [RFC5234] : DIGIT (décimal 0-9).

[HTTP] définit les règles suivantes :

HTTP-date     = <HTTP-date, see [HTTP], Section 5.6.7>
OWS           = <OWS, see [HTTP], Section 5.6.3>
field-name    = <field-name, see [HTTP], Section 5.1>
quoted-string = <quoted-string, see [HTTP], Section 5.6.4>
token         = <token, see [HTTP], Section 5.6.2>

1.2.2 Delta Seconds (Secondes delta)

La règle delta-seconds spécifie un entier non négatif représentant le temps en secondes.

delta-seconds  = 1*DIGIT

Un destinataire qui analyse une valeur delta-seconds et la convertit 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 supérieure au plus grand entier qu'il peut représenter, ou si l'un de ses calculs ultérieurs déborde, le cache doit (MUST) traiter cette valeur comme 2147483648 (2^31) ou le plus grand entier positif qu'il peut commodément représenter.

Note : La valeur 2147483648 existe pour des raisons historiques, représentant l'infini (plus de 68 ans), et n'a pas besoin d'être stockée sous forme binaire ; les implémentations peuvent la générer sous forme de chaîne même si le calcul utilise un type arithmétique qui ne peut pas représenter directement ce nombre. Ce qui importe ici, c'est que le débordement soit détecté plutôt que traité comme une valeur négative dans les calculs ultérieurs.