Zum Hauptinhalt springen

6. Verlaufslisten (History Lists)

User Agents haben oft Verlaufsmechanismen, wie "Zurück"-Buttons und Verlaufslisten, die verwendet werden können, um eine früher in einer Sitzung abgerufene Darstellung erneut anzuzeigen.

Das Frische-Modell (Abschnitt 4.2) gilt nicht notwendigerweise für Verlaufsmechanismen. Das heißt, ein Verlaufsmechanismus kann eine vorherige Darstellung anzeigen, selbst wenn sie abgelaufen ist.

Dies verbietet nicht, dass der Verlaufsmechanismus dem Benutzer mitteilt, dass eine Ansicht möglicherweise veraltet ist, oder Cache-Direktiven befolgt (z.B. Cache-Control: no-store).

7. IANA-Überlegungen (IANA Considerations)

7.1. Cache-Direktiven-Register (Cache Directive Registry)​

Das "Hypertext Transfer Protocol (HTTP) Cache Directive Registry" definiert den Namensraum für die Cache-Direktiven. Es wurde erstellt und wird jetzt unter http://www.iana.org/assignments/http-cache-directives gepflegt.

7.1.1. Verfahren (Procedure)​

Eine Registrierung MUSS die folgenden Felder enthalten:

  • Cache-Direktivenname (Cache Directive Name)
  • Verweis auf Spezifikationstext (Pointer to specification text)

Werte, die zu diesem Namensraum hinzugefügt werden sollen, erfordern IETF Review (siehe [RFC5226], Abschnitt 4.1).

7.1.2. Überlegungen für neue Cache-Control-Direktiven (Considerations for New Cache Control Directives)​

Neue Erweiterungsdirektiven sollten erwägen zu definieren:

  • Was es bedeutet, wenn eine Direktive mehrfach angegeben wird,
  • Wenn die Direktive kein Argument akzeptiert, was es bedeutet, wenn ein Argument vorhanden ist,
  • Wenn die Direktive ein Argument erfordert, was es bedeutet, wenn es fehlt,
  • Ob die Direktive spezifisch für Anfragen, Antworten oder in beiden verwendbar ist.

Siehe auch Abschnitt 5.2.3.

7.1.3. Registrierungen (Registrations)​

Das Register wurde mit den folgenden Registrierungen gefüllt:

Cache-Direktive (Cache Directive)Referenz (Reference)
max-ageAbschnitt 5.2.1.1, Abschnitt 5.2.2.8
max-staleAbschnitt 5.2.1.2
min-freshAbschnitt 5.2.1.3
must-revalidateAbschnitt 5.2.2.1
no-cacheAbschnitt 5.2.1.4, Abschnitt 5.2.2.2
no-storeAbschnitt 5.2.1.5, Abschnitt 5.2.2.3
no-transformAbschnitt 5.2.1.6, Abschnitt 5.2.2.4
only-if-cachedAbschnitt 5.2.1.7
privateAbschnitt 5.2.2.6
proxy-revalidateAbschnitt 5.2.2.7
publicAbschnitt 5.2.2.5
s-maxageAbschnitt 5.2.2.9
stale-if-error[RFC5861], Abschnitt 4
stale-while-revalidate[RFC5861], Abschnitt 3

7.2. Warn-Code-Register (Warn Code Registry)​

Das "Hypertext Transfer Protocol (HTTP) Warn Codes" Register definiert den Namensraum für Warn-Codes. Es wurde erstellt und wird jetzt unter http://www.iana.org/assignments/http-warn-codes gepflegt.

7.2.1. Verfahren (Procedure)​

Eine Registrierung MUSS die folgenden Felder enthalten:

  • Warn-Code (3 Ziffern) (Warn Code (3 digits))
  • Kurzbeschreibung (Short Description)
  • Verweis auf Spezifikationstext (Pointer to specification text)

Werte, die zu diesem Namensraum hinzugefügt werden sollen, erfordern IETF Review (siehe [RFC5226], Abschnitt 4.1).

7.2.2. Registrierungen (Registrations)​

Das Register wurde mit den folgenden Registrierungen gefüllt:

Warn-Code (Warn Code)Kurzbeschreibung (Short Description)Referenz (Reference)
110Antwort ist veraltet (Response is Stale)Abschnitt 5.5.1
111Revalidierung fehlgeschlagen (Revalidation Failed)Abschnitt 5.5.2
112Getrennte Operation (Disconnected Operation)Abschnitt 5.5.3
113Heuristische Ablauf (Heuristic Expiration)Abschnitt 5.5.4
199Verschiedene Warnung (Miscellaneous Warning)Abschnitt 5.5.5
214Transformation angewendet (Transformation Applied)Abschnitt 5.5.6
299Verschiedene persistente Warnung (Miscellaneous Persistent Warning)Abschnitt 5.5.7

7.3. Header-Feld-Registrierung (Header Field Registration)​

HTTP-Header-Felder werden im "Message Headers" Register registriert, das unter http://www.iana.org/assignments/message-headers/ gepflegt wird.

Dieses Dokument definiert die folgenden HTTP-Header-Felder, daher wurde das "Permanent Message Header Field Names" Register entsprechend aktualisiert (siehe [BCP90]).

Header-Feldname (Header Field Name)Protokoll (Protocol)Status (Status)Referenz (Reference)
AgehttpstandardAbschnitt 5.1
Cache-ControlhttpstandardAbschnitt 5.2
ExpireshttpstandardAbschnitt 5.3
PragmahttpstandardAbschnitt 5.4
WarninghttpstandardAbschnitt 5.5

Der Change Controller ist: "IETF ([email protected]) - Internet Engineering Task Force".

8. Sicherheitsüberlegungen (Security Considerations)

Dieser Abschnitt soll Entwickler, Informationsanbieter und Benutzer über bekannte Sicherheitsprobleme informieren, die spezifisch für HTTP-Caching sind. Allgemeinere Sicherheitsüberlegungen werden in HTTP-Messaging [RFC7230] und Semantik [RFC7231] behandelt.

Caches exponieren zusätzliche potenzielle Schwachstellen, da die Inhalte des Caches ein attraktives Ziel für böswillige Ausnutzung darstellen. Da Cache-Inhalte nach Abschluss einer HTTP-Anfrage bestehen bleiben, kann ein Angriff auf den Cache Informationen lange nachdem ein Benutzer glaubt, dass die Informationen aus dem Netzwerk entfernt wurden, offenlegen. Daher müssen Cache-Inhalte als sensible Informationen geschützt werden.

Insbesondere können verschiedene Angriffe durch Speicherung in einem gemeinsam genutzten Cache verstärkt werden; solche "Cache-Poisoning"-Angriffe verwenden den Cache, um eine bösartige Payload an viele Clients zu verteilen, und sind besonders effektiv, wenn ein Angreifer Implementierungsfehler, erhöhte Berechtigungen oder andere Techniken verwenden kann, um eine solche Antwort in einen Cache einzufügen. Ein häufiger Angriffsvektor für Cache-Poisoning ist die Ausnutzung von Unterschieden im Message-Parsing auf Proxys und in User Agents; siehe Abschnitt 3.3.3 von [RFC7230] für die relevanten Anforderungen.

Ebenso können Implementierungsfehler (sowie Missverständnisse des Cache-Betriebs) zum Caching sensibler Informationen (z.B. Authentifizierungsanmeldeinformationen) führen, die als privat angesehen werden, und diese unbefugten Parteien zugänglich machen.

Darüber hinaus kann die bloße Verwendung eines Caches Datenschutzbedenken aufwerfen. Wenn beispielsweise zwei Benutzer einen Cache teilen und der erste zu einer Website surft, kann der zweite möglicherweise erkennen, dass der andere auf dieser Website war, da die Ressourcen davon dank des Caches schneller geladen werden.

Beachten Sie, dass das Set-Cookie-Antwort-Header-Feld [RFC6265] das Caching nicht hemmt; eine cachbare Antwort mit einem Set-Cookie-Header-Feld kann (und wird oft) verwendet werden, um nachfolgende Anfragen an Caches zu erfüllen. Server, die das Caching dieser Antworten steuern möchten, werden ermutigt, geeignete Cache-Control-Antwort-Header-Felder auszusenden.

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)

Die Spezifikation wurde zur Verbesserung der Klarheit erheblich überarbeitet.

Die Bedingungen, unter denen eine authentifizierte Antwort gecacht werden kann, wurden geklärt. (Abschnitt 3.2)

Neue Statuscodes können jetzt definieren, dass Caches heuristische Frische mit ihnen verwenden dürfen. Caches dürfen jetzt heuristische Frische für URIs mit Query-Komponenten berechnen. (Abschnitt 4.2.2)

Der Algorithmus zur Berechnung des Alters ist jetzt weniger konservativ. Caches müssen jetzt Daten mit Zeitzonen als ungültig behandeln, da es nicht möglich ist, sie genau zu erraten. (Abschnitt 4.2.3)

Das Content-Location-Antwort-Header-Feld wird nicht mehr verwendet, um die geeignete Antwort bei der Validierung zu bestimmen. (Abschnitt 4.3)

Der Algorithmus zur Auswahl einer gecachten verhandelten Antwort wurde auf verschiedene Weise geklärt. Insbesondere erlaubt er jetzt explizit header-spezifische Kanonisierung bei der Verarbeitung von Selecting-Header-Feldern. (Abschnitt 4.1)

Anforderungen zur Vermeidung von Denial-of-Service-Angriffen bei der Durchführung der Invalidierung wurden geklärt. (Abschnitt 4.4)

Cache-Invalidierung tritt nur auf, wenn eine erfolgreiche Antwort empfangen wird. (Abschnitt 4.4)

Cache-Direktiven werden explizit als Groß-/Kleinschreibung nicht beachtend definiert. Die Behandlung mehrerer Instanzen von Cache-Direktiven, wenn nur eine erwartet wird, ist jetzt definiert. (Abschnitt 5.2)

Die "no-store"-Anfragedirektive gilt nicht für Antworten; d.h. ein Cache kann eine Anfrage mit no-store erfüllen und invalidiert sie nicht. (Abschnitt 5.2.1.5)

Die qualifizierten Formen der private- und no-cache-Cache-Direktiven werden als nicht weit verbreitet implementiert festgestellt; zum Beispiel wird "private=foo" von vielen Caches einfach als "private" interpretiert. Zusätzlich 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 Expires-Header-Feldwerte wurde entfernt; stattdessen wird die Begründung für die Verwendung eines vernünftigen Werts gegeben. (Abschnitt 5.3)

Das Pragma-Header-Feld wird jetzt nur noch für Rückwärtskompatibilität definiert; zukünftige Pragmas sind veraltet. (Abschnitt 5.4)

Einige Anforderungen bezüglich Produktion und Verarbeitung der Warning-Header-Felder wurden gelockert, da es nicht weit verbreitet implementiert ist. Darüber hinaus verwendet das Warning-Header-Feld keine RFC 2047-Kodierung mehr und erlaubt auch keine mehreren Sprachen, da diese Aspekte nicht implementiert wurden. (Abschnitt 5.5)

Diese Spezifikation führt die Cache Directive- und Warn Code-Register ein und definiert Überlegungen für neue Cache-Direktiven. (Abschnitt 7.1 und Abschnitt 7.2)

Anhang B. Importierte ABNF (Imported ABNF)

Die folgenden Kernregeln sind durch Verweis enthalten, wie in Anhang B.1 von [RFC5234] definiert: ALPHA (Buchstaben), CR (Carriage Return), CRLF (CR LF), CTL (Controls), DIGIT (Dezimal 0-9), DQUOTE (Doppeltes Anführungszeichen), HEXDIG (Hexadezimal 0-9/A-F/a-f), LF (Line Feed), OCTET (beliebige 8-Bit-Datensequenz), SP (Leerzeichen) und VCHAR (beliebiges sichtbares US-ASCII-Zeichen).

Die folgenden Regeln sind in [RFC7230] definiert:

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

port          = <port, siehe [RFC7230], Abschnitt 2.7>
pseudonym     = <pseudonym, siehe [RFC7230], Abschnitt 5.7.1>
uri-host      = <uri-host, siehe [RFC7230], Abschnitt 2.7>

Die folgenden Regeln sind in anderen Teilen definiert:

HTTP-date     = <HTTP-date, siehe [RFC7231], Abschnitt 7.1.1.1>

Anhang C. Gesammelte ABNF (Collected ABNF)

In der unten gesammelten ABNF 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, siehe [RFC7231], Abschnitt 7.1.1.1>

OWS = <OWS, siehe [RFC7230], Abschnitt 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, siehe [RFC7230], Abschnitt 3.2>

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

quoted-string = <quoted-string, siehe [RFC7230], Abschnitt 3.2.6>

token = <token, siehe [RFC7230], Abschnitt 3.2.6>

uri-host = <uri-host, siehe [RFC7230], Abschnitt 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
 ]

Autoren-Adressen (Authors' Addresses)​

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

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

Mark Nottingham (Herausgeber)
Akamai

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

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

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

Letztes Update am