6. Listes d'Historique (History Lists)

Les agents utilisateurs ont souvent des mécanismes d'historique, tels que des boutons "Retour" et des listes d'historique, qui peuvent être utilisés pour réafficher une représentation récupérée plus tôt dans une session.

Le modèle de fraîcheur (Section 4.2) ne s'applique pas nécessairement aux mécanismes d'historique. C'est-à-dire qu'un mécanisme d'historique peut afficher une représentation précédente même si elle a expiré.

Cela n'empêche pas le mécanisme d'historique d'informer l'utilisateur qu'une vue pourrait être périmée ou de respecter les directives de cache (par ex., Cache-Control: no-store).

7. Considérations IANA (IANA Considerations)

7.1. Registre des Directives de Cache (Cache Directive Registry)

Le "Registre des Directives de Cache du Protocole de Transfert Hypertexte (HTTP)" définit l'espace de noms pour les directives de cache. Il a été créé et est maintenant maintenu à http://www.iana.org/assignments/http-cache-directives.

7.1.1. Procédure (Procedure)

Une inscription DOIT inclure les champs suivants :

• Nom de la Directive de Cache (Cache Directive Name)
• Pointeur vers le texte de spécification (Pointer to specification text)

Les valeurs à ajouter à cet espace de noms nécessitent un examen IETF (voir [RFC5226], Section 4.1).

7.1.2. Considérations pour les Nouvelles Directives de Contrôle de Cache (Considerations for New Cache Control Directives)

Les nouvelles directives d'extension devraient envisager de définir :

• Ce que signifie qu'une directive soit spécifiée plusieurs fois,
• Lorsque la directive n'accepte pas d'argument, ce que signifie la présence d'un argument,
• Lorsque la directive nécessite un argument, ce que signifie son absence,
• Si la directive est spécifique aux requêtes, aux réponses ou peut être utilisée dans les deux.

Voir aussi Section 5.2.3.

7.1.3. Inscriptions (Registrations)

Le registre a été rempli avec les inscriptions suivantes :

Directive de Cache (Cache Directive)	Référence (Reference)
max-age	Section 5.2.1.1, Section 5.2.2.8
max-stale	Section 5.2.1.2
min-fresh	Section 5.2.1.3
must-revalidate	Section 5.2.2.1
no-cache	Section 5.2.1.4, Section 5.2.2.2
no-store	Section 5.2.1.5, Section 5.2.2.3
no-transform	Section 5.2.1.6, Section 5.2.2.4
only-if-cached	Section 5.2.1.7
private	Section 5.2.2.6
proxy-revalidate	Section 5.2.2.7
public	Section 5.2.2.5
s-maxage	Section 5.2.2.9
stale-if-error	[RFC5861], Section 4
stale-while-revalidate	[RFC5861], Section 3

7.2. Registre des Codes d'Avertissement (Warn Code Registry)

Le "Registre des Codes d'Avertissement du Protocole de Transfert Hypertexte (HTTP)" définit l'espace de noms pour les codes d'avertissement. Il a été créé et est maintenant maintenu à http://www.iana.org/assignments/http-warn-codes.

7.2.1. Procédure (Procedure)

Une inscription DOIT inclure les champs suivants :

• Code d'Avertissement (3 chiffres) (Warn Code (3 digits))
• Description Courte (Short Description)
• Pointeur vers le texte de spécification (Pointer to specification text)

Les valeurs à ajouter à cet espace de noms nécessitent un examen IETF (voir [RFC5226], Section 4.1).

7.2.2. Inscriptions (Registrations)

Le registre a été rempli avec les inscriptions suivantes :

Code d'Avertissement (Warn Code)	Description Courte (Short Description)	Référence (Reference)
110	La Réponse est Périmée (Response is Stale)	Section 5.5.1
111	Échec de Revalidation (Revalidation Failed)	Section 5.5.2
112	Opération Déconnectée (Disconnected Operation)	Section 5.5.3
113	Expiration Heuristique (Heuristic Expiration)	Section 5.5.4
199	Avertissement Divers (Miscellaneous Warning)	Section 5.5.5
214	Transformation Appliquée (Transformation Applied)	Section 5.5.6
299	Avertissement Persistant Divers (Miscellaneous Persistent Warning)	Section 5.5.7

7.3. Inscription de Champ d'En-tête (Header Field Registration)

Les champs d'en-tête HTTP sont enregistrés dans le registre "Message Headers" maintenu à http://www.iana.org/assignments/message-headers/.

Ce document définit les champs d'en-tête HTTP suivants, donc le registre "Permanent Message Header Field Names" a été mis à jour en conséquence (voir [BCP90]).

Nom du Champ d'En-tête (Header Field Name)	Protocole (Protocol)	Statut (Status)	Référence (Reference)
Age	http	standard	Section 5.1
Cache-Control	http	standard	Section 5.2
Expires	http	standard	Section 5.3
Pragma	http	standard	Section 5.4
Warning	http	standard	Section 5.5

Le contrôleur de changement est : "IETF ([email protected]) - Internet Engineering Task Force".

8. Considérations de Sécurité (Security Considerations)

Cette section vise à informer les développeurs, les fournisseurs d'informations et les utilisateurs des problèmes de sécurité connus spécifiques à la mise en cache HTTP. Des considérations de sécurité plus générales sont abordées dans la messagerie HTTP [RFC7230] et la sémantique [RFC7231].

Les caches exposent des vulnérabilités potentielles supplémentaires, car le contenu du cache représente une cible attrayante pour l'exploitation malveillante. Étant donné que le contenu du cache persiste après la fin d'une requête HTTP, une attaque sur le cache peut révéler des informations longtemps après qu'un utilisateur croit que les informations ont été retirées du réseau. Par conséquent, le contenu du cache doit être protégé comme des informations sensibles.

En particulier, diverses attaques peuvent être amplifiées en étant stockées dans un cache partagé ; de telles attaques d'"empoisonnement de cache" utilisent le cache pour distribuer une charge utile malveillante à de nombreux clients, et sont particulièrement efficaces lorsqu'un attaquant peut utiliser des défauts d'implémentation, des privilèges élevés ou d'autres techniques pour insérer une telle réponse dans un cache. Un vecteur d'attaque courant pour l'empoisonnement de cache consiste à exploiter les différences d'analyse de messages sur les proxys et dans les agents utilisateurs ; voir Section 3.3.3 de [RFC7230] pour les exigences pertinentes.

De même, les défauts d'implémentation (ainsi qu'une mauvaise compréhension du fonctionnement du cache) peuvent conduire à la mise en cache d'informations sensibles (par ex., des informations d'authentification) qui sont considérées comme privées, les exposant à des parties non autorisées.

En outre, l'utilisation même d'un cache peut soulever des préoccupations en matière de confidentialité. Par exemple, si deux utilisateurs partagent un cache et que le premier navigue vers un site, le second peut être en mesure de détecter que l'autre est allé sur ce site, car les ressources de celui-ci se chargent plus rapidement, grâce au cache.

Notez que le champ d'en-tête de réponse Set-Cookie [RFC6265] n'inhibe pas la mise en cache ; une réponse cacheable avec un champ d'en-tête Set-Cookie peut être (et est souvent) utilisée pour satisfaire des requêtes ultérieures aux caches. Les serveurs qui souhaitent contrôler la mise en cache de ces réponses sont encouragés à émettre des champs d'en-tête de réponse Cache-Control appropriés.

9. Remerciements (Acknowledgments)

Voir Section 10 de [RFC7230].

10. Références (References)

10.1. Références Normatives (Normative References)

• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

• [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

• [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014.

• [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.

• [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, June 2014.

• [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, June 2014.

• [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014.

10.2. Références Informatives (Informative References)

• [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.

• [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

• [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

• [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale Content", RFC 5861, April 2010.

• [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.

• [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011.

Annexe A. Changements par rapport à RFC 2616 (Changes from RFC 2616)

La spécification a été substantiellement 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)

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

L'algorithme de calcul de l'âge est maintenant moins conservateur. Les caches sont maintenant tenus de traiter les dates avec des fuseaux horaires comme invalides, car il n'est pas possible de 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é de plusieurs manières. En particulier, il permet maintenant explicitement la canonisation spécifique à l'en-tête lors du traitement des champs d'en-tête de sélection. (Section 4.1)

Les exigences concernant l'évitement des attaques par déni de service lors de l'invalidation ont été clarifiées. (Section 4.4)

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

Les directives de cache sont explicitement définies comme insensibles à la casse. La gestion de plusieurs instances de directives de cache lorsqu'une seule est attendue est maintenant définie. (Section 5.2)

La directive de requête "no-store" ne s'applique pas aux réponses ; c'est-à-dire qu'un cache peut satisfaire une requête avec no-store dessus et ne l'invalide pas. (Section 5.2.1.5)

Les formes qualifiées des directives de cache private et no-cache sont notées comme n'étant 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 pour utiliser une valeur raisonnable est donné. (Section 5.3)

Le champ d'en-tête Pragma n'est maintenant défini que pour la rétrocompatibilité ; les futurs pragmas sont dépréciés. (Section 5.4)

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

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

Annexe B. ABNF Importée (Imported ABNF)

Les règles de base suivantes sont incluses par référence, comme défini dans l'Annexe B.1 de [RFC5234] : ALPHA (lettres), CR (retour chariot), CRLF (CR LF), CTL (contrôles), DIGIT (décimal 0-9), DQUOTE (guillemet double), HEXDIG (hexadécimal 0-9/A-F/a-f), LF (saut de ligne), OCTET (toute séquence de 8 bits de données), SP (espace) et VCHAR (tout caractère US-ASCII visible).

Les règles suivantes sont définies dans [RFC7230] :

OWS           = <OWS, voir [RFC7230], Section 3.2.3>
field-name    = <field-name, voir [RFC7230], Section 3.2>
quoted-string = <quoted-string, voir [RFC7230], Section 3.2.6>
token         = <token, voir [RFC7230], Section 3.2.6>

port          = <port, voir [RFC7230], Section 2.7>
pseudonym     = <pseudonym, voir [RFC7230], Section 5.7.1>
uri-host      = <uri-host, voir [RFC7230], Section 2.7>

Les règles suivantes sont définies dans d'autres parties :

HTTP-date     = <HTTP-date, voir [RFC7231], Section 7.1.1.1>

Annexe C. ABNF Collectée (Collected ABNF)

Dans l'ABNF collectée ci-dessous, les règles de liste sont développées selon la Section 1.2 de [RFC7230].

Age = delta-seconds

Cache-Control = *( "," OWS ) cache-directive *( OWS "," [ OWS
 cache-directive ] )

Expires = HTTP-date

HTTP-date = <HTTP-date, voir [RFC7231], Section 7.1.1.1>

OWS = <OWS, voir [RFC7230], Section 3.2.3>

Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS
 pragma-directive ] )

Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ]
 )

cache-directive = token [ "=" ( token / quoted-string ) ]

delta-seconds = 1*DIGIT

extension-pragma = token [ "=" ( token / quoted-string ) ]

field-name = <field-name, voir [RFC7230], Section 3.2>

port = <port, voir [RFC7230], Section 2.7>
pragma-directive = "no-cache" / extension-pragma
pseudonym = <pseudonym, voir [RFC7230], Section 5.7.1>

quoted-string = <quoted-string, voir [RFC7230], Section 3.2.6>

token = <token, voir [RFC7230], Section 3.2.6>

uri-host = <uri-host, voir [RFC7230], Section 2.7>

warn-agent = ( uri-host [ ":" port ] ) / pseudonym
warn-code = 3DIGIT
warn-date = DQUOTE HTTP-date DQUOTE
warn-text = quoted-string
warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date
 ]

---

Adresses des Auteurs (Authors' Addresses)

Roy T. Fielding (éditeur)
Adobe Systems Incorporated
345 Park Ave
San Jose, CA 95110
USA

EMail: [email protected]
URI: http://roy.gbiv.com/

Mark Nottingham (éditeur)
Akamai

EMail: [email protected]
URI: http://www.mnot.net/

Julian F. Reschke (éditeur)
greenbytes GmbH
Hafenweg 16
Muenster, NW 48155
Germany

EMail: [email protected]
URI: http://greenbytes.de/tech/webdav/