Zusammenfassung

  • Content-Location identifiziert die konkrete Ressource, die der in einer Nachricht enthaltenen Darstellung entspricht. Was daraus folgt, hängt von Methode, Status und dem Verhältnis zur Ziel-URI ab; die Ziel-URI wird niemals ersetzt.
  • Empfänger können die Angabe nutzen, um eine lokale Kopie zu aktualisieren, eine ausgehandelte Variante zu bezeichnen oder später einen Statusbericht abzurufen. Umleitung, kanonisches Eigentum, Schreibrecht oder ein neuer Request folgen daraus nicht.

Ein Client sendet einen POST an einen Kaufdienst. Die erfolgreiche Antwort enthält eine Quittung und das Feld Content-Location: /receipts/47. Was hat der Server damit erklärt?

Er hat erklärt, dass die übermittelte Darstellung einer durch /receipts/47 identifizierten Ressource entspricht und ein GET an dieser Adresse zum Zeitpunkt der Nachricht dieselbe Darstellung in einer 200-Antwort geliefert hätte. Er hat den Client nicht aufgefordert, den POST dort zu wiederholen. Er hat den Kauf nicht umgeleitet, die Quittungsadresse nicht zum kanonischen Ersatz des Kaufendpunkts gemacht und kein Recht zur Bearbeitung der Quittung verliehen.

Genau diese Trennungen bilden den Kern von Abschnitt 8.7 der RFC 9110. Zugleich sind sie ein Governance-Test: Kann ein gemeinsam verstandenes Feld eine nützliche Identitätsaussage transportieren, ohne nebenbei Routing-, Eigentums- und Handlungsmacht anzusammeln?

Das Request-Ziel bleibt das Request-Ziel

Jeder HTTP-Austausch beginnt mit einer Ziel-URI. Sie ist Teil des Routings und bestimmt die Ressource, auf die die Methode angewendet wird. Andere Felder können die ausgewählte Darstellung beschreiben, eine weitere Ressource in Beziehung setzen oder Kontext liefern. Sie schreiben den bereits ausgeführten Request nicht rückwirkend um.

RFC 9110 definiert Content-Location als URI-Referenz, die eine bestimmte Ressource identifiziert, welche der als Nachrichteninhalt mitgeführten Darstellung entspricht. Zum Erzeugungszeitpunkt hätte ein GET auf diese URI dieselbe Darstellung in einer 200-Antwort zurückgegeben. Der Wert darf absolut oder eine partielle Referenz sein, die relativ zur Ziel-URI aufgelöst wird.

Unmittelbar darauf folgt die Leitplanke: Der Wert ist kein Ersatz für die Ziel-URI. Er ist Metadatum der Darstellung.

Die Unterscheidung wird leicht übersehen, weil beide Werte wie Adressen aussehen. Die Ziel-URI beantwortet jedoch die Frage, auf welche Ressource die aktuelle Methode gerichtet war. Content-Location beantwortet, welcher Ressource der übertragene Inhalt entspricht. Wer die zweite Antwort wie die erste behandelt, macht aus Beschreibung einen Befehl.

Location hat wiederum eine andere Aufgabe. Je nach Statuscode kann es eine neu erzeugte Ressource bezeichnen oder eine Umleitungsreferenz liefern. Eine Antwort darf Location und Content-Location gleichzeitig enthalten, denn das durch die Statussemantik bezeichnete Ziel und die Ressource, die dem Antwortkörper entspricht, müssen nicht identisch sein.

Eine kleine Matrix statt einer übergroßen Regel

Die operative Bedeutung entsteht aus Methode, Statuscode und dem Verhältnis der URIs. Es gibt keinen universellen Befehl „folge dieser Adresse“. Mehrere Fälle müssen getrennt betrachtet werden.

Bei einer 2xx-Antwort auf GET oder HEAD mit einem Wert, der der Ziel-URI entspricht, erklärt der Origin, der Inhalt sei zum Ursprungsdatum der Nachricht eine aktuelle Darstellung dieser Ressource. Bei GET bestätigt dies meist die Erwartung des Empfängers. Bei HEAD beschreiben die Metadaten die ausgewählte Darstellung, ohne ihren Körper zu übertragen.

Dieselbe Gleichheit nach einer erfolgreichen zustandsändernden Operation wie PUT oder POST sagt mehr: Die in der Antwort gesendete Darstellung ist der neue Zustand der Zielressource. Ein Editor kann damit seine lokale Kopie aktualisieren, ohne sofort einen weiteren GET auszulösen. Daraus folgt nicht, dass jede erfolgreiche POST-Antwort den neuen Zustand enthält; Erfolg und erklärte Gleichheit gehören gemeinsam zum Nachweis.

Ist die Antwort erfolgreich und unterscheidet sich Content-Location von der Ziel-URI, behauptet der Origin, eine andere Ressource entspreche der mitgeführten Darstellung. RFC 9110 setzt hier eine wichtige Vertrauensgrenze: Die Aussage ist nur vertrauenswürdig, wenn beide Kennungen denselben Ressourceneigentümer haben. Das kann HTTP allein nicht programmgesteuert feststellen. Gleicher Netzwerk-Origin, gültiges Zertifikat oder ähnliche Namen reichen als Eigentumsnachweis nicht automatisch aus.

Bei GET oder HEAD kann der abweichende Wert eine spezifischere Kennung für die durch Inhaltsaushandlung ausgewählte Variante liefern. Angefordert wurde eine aushandelbare Ressource; die Antwort benennt genauer die deutsche Fassung, ein PDF oder eine andere ausgewählte Ausprägung. Das ist für Indexierung und Wiederverwendung nützlich, löst aber keine Navigation aus.

Wenn eine Erzeugungsoperation 201 zurückgibt und Content-Location mit Location übereinstimmt, ist der Körper eine aktuelle Darstellung der neu erzeugten Ressource. Unterscheiden sich die Werte, behält jedes Feld seine Funktion: Location bezeichnet die erzeugte Ressource, Content-Location die dem Körper entsprechende Ressource.

Nach einer anderen erfolgreichen zustandsändernden Operation kann ein abweichender Wert einen später per GET abrufbaren Statusbericht identifizieren. Die Quittung eines Kaufs ist das anschauliche Beispiel. Der Kauf wurde an den Transaktionsendpunkt gerichtet, der Antwortkörper entspricht einer separat abrufbaren Belegressource. Die Abrufbarkeit verlegt den Kauf nicht an die Belegadresse.

Eine zeitgebundene Aussage, kein ewiges Versprechen

Die Definition bindet die Gleichheit an den Zeitpunkt, zu dem die Nachricht erzeugt wurde. Diese Zeitangabe begrenzt die Aussage. Der Origin erklärt, ein GET hätte in diesem Moment dieselbe Darstellung geliefert. Später kann sich die Ressource ändern, ablaufen, eine andere Berechtigung verlangen oder verschwinden.

Ein Client darf die Beziehung samt Datum speichern. Er sollte sie nicht zu einer dauerhaft gültigen Äquivalenz versteinern. Validatoren, Cache-Steuerung und Anwendungsrichtlinien bleiben nötig. Eine identifizierende URI macht veränderliche Inhalte nicht unveränderlich.

Aus demselben Grund genügt das Feld nicht als globale kanonische Kennung. Ein Publikationssystem kann es als Indiz behandeln, dass eine konkrete Variante eine genauere Adresse besaß. Das Ersetzen von Indizes, Zusammenführen von Historien oder Festlegen einer kanonischen URL braucht jedoch eine zusätzliche Anwendungs- oder Redaktionsrichtlinie mit nachweisbarem Eigentum und nachweisbarer Absicht.

Im Request ändert das Feld den Request nicht

Content-Location kann auch in einer Anfrage erscheinen. Ein User Agent kann damit angeben, woher er den Inhalt ursprünglich bezogen hatte, bevor er ihn veränderte. Für Autorenwerkzeuge ist eine solche vorübergehende Provenienzangabe mitunter nützlich.

RFC 9110 schützt die Gegenseite ebenso deutlich: Ein Server soll diese Information nicht ungeprüft als dauerhaftes Metadatum speichern, und sie darf die Semantik des Requests nicht verändern. Die Methode wirkt weiterhin auf die Ziel-URI.

Angenommen, ein Client hat eine ausgehandelte Variante erhalten und will sie bearbeiten. Er kann den PUT nicht dadurch auf diese Variante umlenken, dass er ihre URI in Content-Location einträgt, während der Request an die aushandelbare Ressource geht. Soll die konkrete Variante aktualisiert werden, muss PUT unmittelbar an deren URI gerichtet sein. Sonst würde ein beschreibendes Feld zum verborgenen Kanal für eine Ausweitung des Schreibbereichs.

Diese Grenze ist sicherheitsrelevant. Gateway, Synchronisationsdienst und Origin könnten ein „Ziel in den Metadaten“ unterschiedlich auslegen. Indem die Absicht im Request-Ziel stehen muss, bleibt das Objekt der Autorisierung, Protokollierung und Richtlinienprüfung sichtbar.

Cache-Invalidierung ist keine Umleitung

RFC 9111 ergänzt eine Folge, die gelegentlich falsch gelesen wird. Nach einer fehlerfreien Antwort auf eine unsichere Methode muss ein durchlaufener Cache gespeicherte Antworten für die Ziel-URI invalidieren. Er darf außerdem die von Location oder Content-Location bezeichnete URI invalidieren, sofern sie demselben Origin angehört.

Diese Regel verleiht dem Feld keine Navigationsmacht. Sie ist eine vorsichtige Konsistenzmaßnahme: Die Zustandsänderung könnte eine verwandte gespeicherte Darstellung veraltet haben lassen. Die Same-Origin-Beschränkung verhindert, dass eine Antwort willkürlich Inhalte eines fremden Origins entwertet.

Auch innerhalb desselben Origins erreicht die Invalidierung nur Caches, die die Antwort durchlaufen hat. Sie ist kein globaler Rundruf und garantiert nicht, dass jede verteilte Kopie entfernt wurde. Anwendungen mit stärkeren Koordinationsanforderungen benötigen ausdrückliche eigene Mechanismen.

Drei Handlungen bleiben somit getrennt: den Körper einer Ressource zuordnen, eine möglicherweise alte Kopie invalidieren und einen neuen Request beginnen. Content-Location wirkt an der ersten mit und kann einen eng begrenzten Kandidaten für die zweite liefern. Die dritte Handlung führt es nicht aus.

Kryptografische Integrität schafft keine Befugnis

RFC 9421 ermöglicht Signaturen über ausgewählte Bestandteile von HTTP-Nachrichten. Eine gültige Signatur kann zeigen, dass die abgedeckten Bytes unverändert sind und sie an den verwendeten Schlüssel binden. Sie beweist allein weder, dass der Unterzeichner beide URIs besitzt, noch dass er eine davon ändern darf oder der Empfänger handeln soll.

Das ist wichtig, wenn Content-Location Vermittler passiert. Die Integrität des Wertes zu schützen, ist sinnvoll. Ressourceneigentum, Vertrauen in den Origin und Lese- oder Schreibberechtigung gehören dennoch zum Sicherheitssystem und zur Anwendungsrichtlinie. Kryptografie bewahrt die Behauptung; sie vergrößert ihren Bedeutungsumfang nicht.

Das permanente HTTP-Feldregister der IANA sorgt für eine andere Art von Stabilität. Es fixiert den Feldnamen und verweist auf die maßgebliche Spezifikation. Es erhebt jedoch weder jeden historischen Gebrauch zur aktuellen Norm noch lokale Lesarten zu allgemeiner Autorität. RFC 7231 und RFC 2557 dokumentieren die Entwicklung; normative Grundlage der heutigen HTTP-Semantik ist RFC 9110, im Juni 2022 als Standards Track veröffentlicht. Die Errata-Liste enthält keine angenommene Korrektur, welche die Grenze aus Abschnitt 8.7 verändert.

Eine Implementierung, die Rollen bewahrt

Eine Bibliothek kann die Information als eigenständige Beobachtung modellieren: Ziel-URI, aufgelöste Content-URI, Methode, Status, Nachrichtenzeitpunkt, Gleichheitsbeziehung und Origin. Das ist robuster, als eine allgemeine Eigenschaft namens url stillschweigend zu überschreiben.

Die Darstellungsschicht kann bei passendem Kontext „identifizierte Darstellung öffnen“ anbieten. Die Cache-Schicht kann Kandidaten nach RFC 9111 prüfen. Ein Editor darf seine lokale Kopie nur in dem nachgewiesenen Fall aktualisieren, in dem eine erfolgreiche Zustandsänderung einen mit dem Ziel identischen Wert zurückgibt. Jede zukünftige Operation wird vom Autorisierungssystem gegen ihr tatsächliches Ziel geprüft.

Auch die Herkunft der Schlussfolgerung sollte sichtbar bleiben. Ein Wert vom vertrauenswürdigen Origin, ein vom Proxy umgeschriebener Wert und ein vom Client in einer Anfrage geliefertes Feld verdienen nicht dieselbe Behandlung. Eine relative Referenz aufzulösen ist syntaktisch; der Beziehung zwischen Ressourcen zu vertrauen ist institutionell.

Tests sollten die Matrix abdecken und nicht nur beweisen, dass der Parser das Feld akzeptiert: GET mit gleichem Wert, ausgehandeltes GET mit abweichendem Wert, 201 mit identischen Location- und Content-Location-Werten, POST-Antwort mit Quittung, relative Referenz, Cross-Origin-Versuch und ein PUT, der über das Feld sein Ziel ändern will. Erwartete Ergebnisse sollten erklären, was gespeichert, invalidiert, angezeigt oder zurückgewiesen wird — und was ausdrücklich nicht geschieht.

Evidenz und Erkenntnisgrenzen

Die zentrale normative Quelle ist RFC 9110. RFC 3986 regelt die Auflösung von URI-Referenzen, RFC 9111 die Cache-Invalidierung, RFC 8288 hilft bei der Abgrenzung typisierter Link-Beziehungen, und RFC 9421 grenzt den Beweiswert von HTTP-Nachrichtensignaturen ein. Historische Dokumente zeigen Kontinuität, ersetzen aber nicht die aktuelle Spezifikation. Das IANA-Register bestätigt den permanenten Status des Feldes.

HTTP lässt Fragen offen. Das Protokoll kann nicht programmatisch feststellen, ob zwei URIs denselben Ressourceneigentümer haben. Ebenso weiß es nicht, ob die Beziehung nach dem Antwortzeitpunkt fortbesteht. Dafür sind konfiguriertes Vertrauen, Authentifizierung, redaktionelle Regeln, Anwendungskontrollen oder eine neue Beobachtung erforderlich.

Gerade deshalb sollte die gemeinsame Semantik zugleich hinreichend und eng sein. Sie ermöglicht Interoperabilität, ohne eine zentrale Vergabestelle für Darstellungskennungen zu errichten. Jede Implementierung darf lokal entscheiden, ob sie das Metadatum anzeigt, speichert oder ignoriert, solange sie die gemeinsame Regel nicht umdeutet und ihre Präferenz anderen Teilnehmern nicht aufzwingt.

Quellen