Cache-Control  nach oben

Der Cache-Control Header ermöglicht die Beschreibung der Cache-Daten (Zwischenspeicher). Dazu gibt es eine Reihe von Request- und Responsewerten, die verwendet werden können. Requestwerte wie auch Responsewerte können untereinander durch Komma getrennt kombiniert werden. Die Requestwerte sind:

  • no-cache - der Client weist den Cache an, ihm ein nicht gespeichertes Dokument zu senden (also das aktuellste)
  • no-store - der Cache soll nach der Abwicklung des Responses alle Verbindungsdaten löschen.
  • max-age=Sekunden - der Cache soll keine Responses senden, die länger als die angegebene Zahl an Sekunden im Cache bereits vorhanden sind. Ist ein im Cache befindliches Dokument neuer, kann es gesendet werden.
  • max-stale=Sekunden - der Cache kann ein Response schicken, dass älter als sein "Verfallsdatum" ist. Die Angabe der Sekunden ist hier optional. Werden Sekunden angegeben, darf die Verfallszeit nicht um mehr als die angegebene Zahl an Sekunden überschritten sein.
  • min-fresh=Sekunden - der Cache soll nur Daten senden, die nach der angegebenen Zahl an Sekunden noch aktuell sind.
  • only-if-cached - der Cache soll nur selbst (zwischen-)gespeicherte Daten senden.

Als Responsewerte können folgende verwendet werden:

  • public - dem Empfänger wird mitgeteilt, dass das Dokument von jedem System gespeichert werden darf
  • private - dem Empfänger wird mitgeteilt, dass das Dokument nur von nicht-öffentlichen Systemen gespeichert werden darf
  • no-cache - dem Empfänger wird mitgeteilt, dass das Dokument gespeichert werden darf, aber jedes mal zuvor geprüft werden muss
  • no-store - nach der Abwicklung des Responses sollen alle Verbindungsdaten gelöscht werden
  • no-transform - der Nachrichtenbody soll vom Empfänger nicht verändert werden
  • must-revalidate - der Empfänger muss den Status gespeicherte Dokumente vor der Übertragung prüfen
  • proxy-revalidate - öffentliche Caches müssen den Status gespeicherter Dokumente vor der Übertragung prüfen
  • max-age=x - das Dokument darf ein maximales Alter von x Sekunden haben
  • s-maxage=x - das Dokument darf bei einem Cache maximal x Sekunden alt sein

Beispiel:

Cache-Control: no-cache

Connection  nach oben

Der Connection-Header gibt an, ob die Verbindung nach der Transaktion aufrecht erhalten werden soll (keep-alive) oder nicht (close). Bei HTTP 1.0 werden Verbindungen standardmäßig geschlossen. Soll die Verbindung dennoch geöffnet bleiben, muss keep-alive als Wert angegeben werden. HTTP 1.1 verwendet jedoch persistente (aufrechterhaltende) Verbindungen. Damit die Verbindung hier dennoch geschlossen wird, muss close als Wert angegeben werden. Beispiel:

Connection: keep-alive

Date  nach oben

Der Date-Header gibt das aktuelle Datum an. Hierzu gibt es drei Datumsformate, vorwiegend wird jedoch das in RFC 1123 beschriebene Format verwendet. Beispiel:

Date: Tue, 06 Apr 2004 21:45:13 GMT

Pragma  nach oben

Der Pragma-Header legt fest, wie Proxy-Server und Gateways mit der Nachricht bzw. der gesendeten Datei umgehen sollen. Der einzige Wert, der dafür definiert ist, ist no-cache. Soll ein Dokument nicht zwischen gespeichert werden, verwendet man diesen Header zusammen mit dem Wert - ansonsten wird der gesamte Header einfach weggelassen. Beispiel:

Pragma: no-cache

Trailer  nach oben

Der Trailer-Header gibt die Header an, die in einer aus mehreren Teilen bestehenden Nachricht, enthalten sein werden. Bei solchen Nachrichten ist es möglich nach den eigentlichen Daten noch weitere Header zu senden.

Transfer-Encoding  nach oben

Der Transfer-Encoding Header gibt an, ob und wie die Nachricht codiert wurde. Wurde die Nachricht codiert, muss als Wert das verwendete Verfahren angegeben werden. Als Verfahren verwendet werden können gzip bzw. x-gzip, compress bzw. x-compress, deflate und identity (kein Verfahren). Wurden mehrere Verfahren zum Codieren verwendet, müssen diese durch Komma getrennt und in der richtigen Reihenfolge angegeben werden. Außerdem kann noch das Verfahren chunked eingesetzt werden. Dabei handelt es sich im Gegensatz zu den vorher genannten nicht um die Codierung von Zeichen sondern um die Zerteilung der Nachricht in mehrere Teile. Das Verfahren wird im Kapitel "Anwendungsbeispiele" näher beschrieben. Beispiel:

Transfer-Encoding: chunked

Upgrade  nach oben

Der Upgrade-Header gibt an, welche weiteren Protokolle oder Protokollversionen der Client verarbeiten kann und dass er den Datenaustausch lieber mit einem dieser Protokolle vollziehen würde. Akzeptiert der Server die Forderung des Clients, sendet dieser den Response-Code 101 zurück und gibt seinerseits den Upgrade-Header mit dem ausgewählten Protokoll als Wert an. Beispiel:

Upgrade: HTTP/1.5, SHTTP/3.7

Via  nach oben

Der Via-Header dient der Zurückverfolgung des Nachrichtenweges. Proxy-Server sind angewiesen bei jeder durchlaufenden Nachricht diesen Header an zu hängen bzw. durch eigene Daten zu ergänzen. Als Wert wird dabei jeweils die Protokollinformationen, ein Leerzeichen, der Proxyname und ggf. der Port notiert. Die Protokollinformationen bestehen aus dem optinalen Protokollnamen, gefolgt von einem Schrägstrich (/), sowie der Protokollversion. Wird der Protokollname weggelassen entfällt auch der Schrägstrich.
Zusätzlich kann ausserdem, durch ein Leerzeichen getrennt, ein Kommentar angehängt werden. Erhält ein Proxy-Server eine Nachricht in der bereits der Via-Header enthalten ist, so ergänzt er seine Informationen indem er sie nach einem Komma an den besteheneden Wert notiert.
Ein Beispiel hierfür finden Sie im Kapitel "Request-Methoden" im Abschnitt "TRACE".

Warning  nach oben

Der Warning-Header enthält weitere Informationen zum Statuscode. Dabei wird als erstes der Warnungscode angegeben, gefolgt von einem Leerzeichen sowie den Serverinformationen (Name und ggf. Port) und einem Warnungstext. Optional kann noch ein in doppelte Anführungszeichen gesetztes Datum angegeben werden.
Folgende Warnungscodes sind definiert:

  • 110 - wird angegeben, wenn die Response-Daten veraltet sind
  • 111 - wird angegeben, wenn die Response-Daten veraltet sind, weil der Cache sie nicht prüfen konnte
  • 112 - wird angegeben, wenn der Cache vom Netzwerk getrennt wird/ist
  • 113 - wird angegeben, wenn die Daten und deren Ablaufdatum über 24 Stunden alt sind
  • 199 - wird angegeben, wenn zusätzliche Informationen enthalten sind
  • 214 - wird angegeben, wenn der Cache oder Proxy die Codierung oder den Medientyp ändern musste
  • 299 - wird angegeben, wenn zusätzliche persistente Informationen enthalten sind

Beispiel:

Warning: 110 proxy.com "Response is stale"