9. Danksagungen (Acknowledgments)
Siehe Abschnitt 10 von [RFC7230].
10. Referenzen (References)
10.1. Normative Referenzen (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. Informative Referenzen (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.
Anhang A. Änderungen gegenüber RFC 2616 (Changes from RFC 2616)
Diese Spezifikation wurde zur besseren Klarheit erheblich umgeschrieben.
Die Bedingungen, unter denen eine authentifizierte Antwort zwischengespeichert werden kann, wurden geklärt. (Abschnitt 3.2)
Neue Statuscodes können nun festlegen, dass Caches mit ihnen eine heuristische Frische (Freshness) verwenden dürfen. Caches ist nun erlaubt, eine heuristische Frische für URIs mit Abfragekomponenten zu berechnen. (Abschnitt 4.2.2)
Der Algorithmus zur Berechnung des Alters (Age) ist nun weniger konservativ. Caches MÜSSEN (MUST) Daten mit Zeitzonen als ungültig behandeln, da diese nicht zuverlässig erraten werden können. (Abschnitt 4.2.3)
Das Antwort-Header-Feld Content-Location wird nicht mehr verwendet, um die geeignete Antwort für die Validierung auszuwählen. (Abschnitt 4.3)
Der Algorithmus zur Auswahl einer zwischengespeicherten ausgehandelten Antwort wurde in mehrerer Hinsicht geklärt. Insbesondere erlaubt er nun ausdrücklich eine header-spezifische Kanonisierung bei der Verarbeitung auswählender Header-Felder. (Abschnitt 4.1)
Die Anforderungen zur Vermeidung von Denial-of-Service-Angriffen bei der Invalidierung wurden geklärt. (Abschnitt 4.4)
Die Cache-Invalidierung erfolgt nur bei Erhalt einer erfolgreichen Antwort. (Abschnitt 4.4)
Cache-Direktiven sind ausdrücklich als groß- und kleinschreibungsunabhängig definiert. Der Umgang mit mehreren Instanzen von Cache-Direktiven, wenn nur eine erwartet wird, ist nun definiert. (Abschnitt 5.2)
Die "no-store"-Anfragedirektive gilt nicht für Antworten; das heißt, ein Cache kann eine Anfrage mit no-store erfüllen, ohne sie zu invalidieren. (Abschnitt 5.2.1.5)
Die qualifizierten Formen der Cache-Direktiven private und no-cache werden als wenig verbreitet eingestuft; beispielsweise wird "private=foo" von vielen Caches einfach als "private" interpretiert. Zudem wurde die Bedeutung der qualifizierten Form von no-cache geklärt. (Abschnitt 5.2.2)
Die Bedeutung der "no-cache"-Antwortdirektive wurde geklärt. (Abschnitt 5.2.2.2)
Die Ein-Jahres-Grenze für Werte des Expires-Header-Feldes wurde entfernt; stattdessen wird der Grund für die Verwendung eines sinnvollen Wertes genannt. (Abschnitt 5.3)
Das Pragma-Header-Feld ist nun nur noch für die Abwärtskompatibilität definiert; künftige Pragmas sind veraltet. (Abschnitt 5.4)
Einige Anforderungen an die Erzeugung und Verarbeitung der Warning-Header-Felder wurden gelockert, da diese kaum implementiert sind. Zudem verwendet das Warning-Header-Feld nicht mehr die RFC-2047-Kodierung und erlaubt keine mehreren Sprachen, da diese Aspekte nicht implementiert waren. (Abschnitt 5.5)
Diese Spezifikation führt die Cache-Direktiven- und Warncode-Registries ein und definiert Überlegungen zu neuen Cache-Direktiven. (Abschnitte 7.1 und 7.2)
Anhang B. Importiertes ABNF (Imported ABNF)
Die folgenden Kernregeln sind als Referenz enthalten, wie sie in Anhang B.1 von [RFC5234] definiert sind: ALPHA (Buchstaben), CR (Wagenrücklauf), CRLF (CR LF), CTL (Steuerzeichen), DIGIT (Dezimal 0-9), DQUOTE (doppeltes Anführungszeichen), HEXDIG (hexadezimal 0-9/A-F/a-f), LF (Zeilenvorschub), OCTET (jede 8-Bit-Datensequenz), SP (Leerzeichen) und VCHAR (jedes sichtbare US-ASCII-Zeichen).
Die folgenden Regeln sind in [RFC7230] definiert:
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>
Die folgenden Regeln sind in anderen Teilen definiert:
HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1>
Anhang C. Gesammeltes ABNF (Collected ABNF)
Im gesammelten ABNF unten werden Listenregeln gemäß Abschnitt 1.2 von [RFC7230] erweitert.
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
]