Aller au contenu principal

9. Remerciements (Acknowledgments)

Voir la 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. Modifications par rapport à la RFC 2616 (Changes from RFC 2616)

Cette 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)

De nouveaux codes de statut peuvent désormais définir que les caches sont autorisés à utiliser avec eux la fraîcheur heuristique. Les caches sont désormais autorisés à calculer une 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 (MUST) à présent traiter les dates comportant un fuseau horaire comme si elles étaient invalides, car il n'est pas possible de le 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 en cache à utiliser a été clarifié de plusieurs manières. En particulier, il autorise désormais explicitement la canonicalisation spécifique à 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 survient que lors de la réception d'une réponse réussie. (Section 4.4)

Les directives de cache sont explicitement définies comme insensibles à la casse. Le traitement de plusieurs instances de directives de cache lorsqu'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 ; c'est-à-dire qu'un cache peut satisfaire une requête comportant no-store et ne l'invalide pas. (Section 5.2.1.5)

Les formes qualifiées des directives de cache private et no-cache sont signalées comme peu implantées ; par exemple, "private=foo" est interprété par de nombreux caches simplement comme "private". Par ailleurs, 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, la raison d'utiliser une valeur raisonnable est donnée. (Section 5.3)

Le champ d'en-tête Pragma n'est désormais 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 ils ne sont pas largement implémentés. En outre, le champ d'en-tête Warning n'utilise plus l'encodage RFC 2047, ni ne permet plusieurs langues, ces aspects n'ayant 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. (Sections 7.1 et 7.2)

Annexe B. ABNF importée (Imported ABNF)

Les règles centrales suivantes sont incluses par référence, telles que définies dans l'annexe B.1 de [RFC5234] : ALPHA (lettres), CR (retour chariot), CRLF (CR LF), CTL (caractères de contrôle), 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 données de 8 bits), SP (espace) et VCHAR (tout caractère US-ASCII visible).

Les règles ci-dessous sont définies dans [RFC7230] :

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

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

Les règles ci-dessous sont définies dans d'autres parties :

HTTP-date     = <HTTP-date, see [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 conformément à 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, see [RFC7231], Section 7.1.1.1>

OWS = <OWS, see [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, see [RFC7230], Section 3.2>

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

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

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

uri-host = <uri-host, see [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
 ]