Aller au contenu principal

3. Storing Responses in Caches (Stockage des réponses dans les caches)

Un cache ne doit pas (MUST NOT) stocker une réponse à une requête à moins que toutes les conditions suivantes ne soient remplies :

  • La méthode de requête est comprise par le cache ;

  • Le code d'état de la réponse est final (Final) (voir la section 15 de [HTTP]) ;

  • Si le code d'état de la réponse est 206 ou 304, ou qu'une directive de cache must-understand est présente (voir la section 5.2.2.3) : le cache comprend le code d'état de la réponse ;

  • La directive de cache no-store n'est pas présente dans la réponse (voir la section 5.2.2.5) ;

  • Si le cache est partagé : la directive de réponse private n'est pas présente ou permet aux caches partagés de stocker une réponse modifiée (voir la section 5.2.2.7) ;

  • Si le cache est partagé : le champ d'en-tête Authorization (voir la section 11.6.2 de [HTTP]) n'est pas présent dans la requête ou une directive de réponse autorise explicitement les caches partagés (voir la section 3.5) ; et

  • La réponse contient au moins l'un des éléments suivants :

    • Une directive de réponse public (voir la section 5.2.2.9) ;

    • Une directive de réponse private, si le cache n'est pas partagé (voir la section 5.2.2.7) ;

    • Un champ d'en-tête Expires (voir la section 5.3) ;

    • Une directive de réponse max-age (voir la section 5.2.2.1) ;

    • Si le cache est partagé : une directive de réponse s-maxage (voir la section 5.2.2.10) ;

    • Une extension de cache qui permet la mise en cache (voir la section 5.2.3) ; ou

    • Un code d'état défini comme heuristiquement cacheable (Heuristically Cacheable) (voir la section 4.2.2).

Notez que les extensions de cache peuvent remplacer l'une des exigences énumérées ci-dessus ; voir la section 5.2.3.

Dans ce contexte, un cache "comprend (Understood)" une méthode de requête ou un code d'état de réponse si le cache le reconnaît et implémente tout le comportement lié au cache spécifié.

Notez qu'en fonctionnement normal, certains caches ne stockeront pas les réponses qui n'ont ni validateur de cache (Cache Validator) ni temps d'expiration explicite, car ces réponses ne valent souvent pas la peine d'être stockées. Cependant, les caches ne sont pas interdits de stocker de telles réponses.

3.1 Storing Header and Trailer Fields (Stockage des champs d'en-tête et de fin)​

Un cache doit (MUST) inclure tous les champs d'en-tête de réponse reçus lors du stockage d'une réponse -- y compris les champs non reconnus ; cela garantit que les nouveaux champs d'en-tête HTTP peuvent être déployés avec succès. Cependant, les exceptions suivantes existent :

  • Le champ d'en-tête Connection et les champs dont les noms y sont énumérés doivent (MUST) être supprimés avant le transfert des messages conformément à la section 7.6.1 de [HTTP]. Cela peut (MAY) être réalisé en les supprimant avant le stockage.

  • De même, la sémantique de certains champs nécessite de les supprimer avant de transférer les messages, ce qui peut (MAY) être réalisé en les supprimant avant le stockage ; voir la section 7.6.1 de [HTTP] pour quelques exemples.

  • Les directives de cache no-cache (section 5.2.2.4) et private (section 5.2.2.7) peuvent avoir des paramètres qui empêchent respectivement tous les caches et les caches partagés de stocker les champs d'en-tête.

  • Les champs d'en-tête spécifiques au proxy qui sont utilisés par un cache lors du transfert de requêtes ne doivent pas (MUST NOT) être stockés à moins que le cache n'incorpore l'identité du proxy dans la clé de cache. En pratique, cela se limite à Proxy-Authenticate (section 11.7.1 de [HTTP]), Proxy-Authentication-Info (section 11.7.3 de [HTTP]) et Proxy-Authorization (section 11.7.2 de [HTTP]).

Un cache peut (MAY) stocker les champs de fin (Trailer Fields) séparément des champs d'en-tête ou les éliminer. Les caches ne doivent pas (MUST NOT) combiner les champs de fin avec les champs d'en-tête.

3.2 Updating Stored Header Fields (Mise à jour des champs d'en-tête stockés)​

Dans divers cas, un cache doit mettre à jour les champs d'en-tête d'une réponse stockée à partir d'une autre réponse (généralement plus récente) ; par exemple, voir les sections 3.4, 4.3.4 et 4.3.5.

Ce faisant, un cache doit (MUST) ajouter chaque champ d'en-tête de la réponse fournissant à la réponse stockée, en remplaçant les valeurs de champ existantes, avec les exceptions suivantes :

  • Les champs d'en-tête exclus du stockage selon la section 3.1,

  • Les champs d'en-tête dont dépend la réponse stockée du cache, comme décrit ci-dessous,

  • Les champs d'en-tête qui sont automatiquement traités et supprimés par le destinataire, comme décrit ci-dessous, et

  • Le champ d'en-tête Content-Length.

Dans certains cas, les caches (en particulier dans les agents utilisateurs) stockent le résultat du traitement des réponses reçues plutôt que les réponses elles-mêmes, et la mise à jour des champs d'en-tête qui influencent ce traitement pourrait entraîner un comportement incohérent et des problèmes de sécurité. Dans de tels cas, les caches peuvent (MAY) omettre ces champs d'en-tête de la mise à jour des réponses stockées dans les exceptions, mais devraient (SHOULD) limiter ces omissions aux champs nécessaires pour garantir l'intégrité de la réponse stockée.

Par exemple, un navigateur peut décoder le codage de contenu d'une réponse (Content Coding) lorsqu'elle est reçue, créant une déconnexion entre ses données stockées et les métadonnées d'origine de la réponse. Mettre à jour ces métadonnées stockées avec un champ d'en-tête Content-Encoding différent serait problématique. De même, un navigateur peut stocker un arbre HTML analysé plutôt que le contenu reçu dans la réponse ; la mise à jour du champ d'en-tête Content-Type dans cette situation ne serait pas réalisable, car toutes les hypothèses faites sur le format pendant l'analyse sont maintenant intégrées.

De plus, certains champs sont automatiquement traités et supprimés par les implémentations HTTP, tels que le champ d'en-tête Content-Range. Même si aucun traitement ne se produit réellement, les implémentations peuvent (MAY) automatiquement omettre ces champs d'en-tête des mises à jour.

Notez que le préfixe Content-* ne signifie pas qu'un champ d'en-tête est omis des mises à jour ; c'est une convention pour les champs d'en-tête MIME, pas HTTP.

3.3 Storing Incomplete Responses (Stockage des réponses incomplètes)​

Un cache peut (MAY) stocker une réponse incomplète (voir la section 6.1 de [HTTP]) si la méthode de requête est GET, le code d'état de la réponse est 200 (OK), et la section d'en-tête de réponse entière a été reçue, à condition que la réponse stockée soit enregistrée comme incomplète. De même, une réponse 206 (Partial Content) peut (MAY) être stockée comme une réponse 200 (OK) incomplète. Cependant, un cache ne doit pas (MUST NOT) stocker des réponses de contenu incomplet ou partiel si le cache ne prend pas en charge les champs d'en-tête Range et Content-Range ou ne comprend pas les unités de plage (Range Units) utilisées dans ces champs.

Un cache peut (MAY) compléter une réponse incomplète stockée en faisant des requêtes de plage ultérieures (voir la section 14.2 de [HTTP]) et en combinant les réponses réussies avec la réponse stockée comme défini dans la section 3.4. Un cache ne doit pas (MUST NOT) utiliser une réponse incomplète pour répondre à une requête à moins que la réponse n'ait été complétée ou que la requête soit partielle et spécifie une plage qui se trouve entièrement dans la réponse incomplète. Un cache ne doit pas (MUST NOT) envoyer une réponse partielle à un client à moins qu'elle ne soit explicitement marquée en utilisant le code d'état 206 (Partial Content).

3.4 Combining Partial Content (Combinaison de contenu partiel)​

Une réponse peut ne transférer qu'une représentation partielle si la connexion se ferme prématurément ou si la requête utilise un ou plusieurs spécificateurs Range (voir la section 14.2 de [HTTP]). Après plusieurs de ces transferts, un cache peut avoir reçu plusieurs plages de la même représentation. Un cache peut (MAY) combiner ces plages en une seule réponse stockée si elles partagent toutes le même validateur fort (Strong Validator) et que le cache se conforme aux exigences du client de la section 15.3.7.3 de [HTTP], et réutiliser cette réponse pour satisfaire les requêtes ultérieures.

Lors de la combinaison d'une nouvelle réponse avec une ou plusieurs réponses stockées, un cache doit (MUST) mettre à jour les champs d'en-tête de la réponse stockée en utilisant les champs d'en-tête fournis dans la nouvelle réponse, conformément à la section 3.2.

3.5 Storing Responses to Authenticated Requests (Stockage des réponses aux requêtes authentifiées)​

Un cache partagé ne doit pas (MUST NOT) utiliser une réponse mise en cache à une requête avec un champ d'en-tête Authorization (voir la section 11.6.2 de [HTTP]) pour satisfaire toute requête ultérieure à moins que la réponse ne contienne un champ Cache-Control avec une directive de réponse (section 5.2.2) qui permet de la stocker par un cache partagé et que le cache se conforme aux exigences de cette directive pour cette réponse.

Dans cette spécification, les directives de réponse suivantes ont cet effet : must-revalidate (section 5.2.2.2), public (section 5.2.2.9) et s-maxage (section 5.2.2.10).

Dernière mise à jour le