RFC 2616 definiert den Header Location als:
Das Location-Response-Header-Feld wird verwendet, um den Empfänger an einen anderen Ort als den Request-URI umzuleiten, um die Anfrage oder Identifikation einer neuen Ressource zu vervollständigen ...
Bei 3xx-Antworten SOLLTE der Speicherort den bevorzugten URI des Servers für die automatische Weiterleitung an die Ressource angeben.
AFAIK, für 3xx Redirection codes ist der Header Location :
Aber das ist nur aus eigener Erfahrung. Gibt es einen Standard, der definiert, welche HTTP-Codes erfordern, dass der Header Location gesendet wird?
Das heißt, für welche 3xx-Codes sollte ein HTTP-Client eine Ausnahme auslösen, wenn er ohne einen entsprechenden Location -Header empfangen wird?
Diese Frage wurde in den Tagen gestellt, als RFC 2616 immer noch die Autorität war, also sah es nach einem spaßigen Forschungsprojekt aus, jetzt, da die RFCs 7230 bis 7235 vorhanden sind. Also, mal sehen, was wir hier haben.
Der Header Location ist jetzt in RFC 7231, Abschnitt 7.1.2 definiert:
Das Headerfeld "Location" wird in einigen Antworten verwendet, um sich auf eine bestimmte Ressource in Bezug auf die Antwort zu beziehen. Die Art der Beziehung wird durch die Kombination von Anforderungsmethode und Statuscode-Semantik definiert.
[...]
Für 201 (Created) Antworten bezieht sich der Location-Wert auf die primäre Ressource, die von erstellt wurde die Anfrage. Bei 3xx-Antworten (Umleitung) bezieht sich der Wert für die Position auf die bevorzugte Zielressource zum automatischen Umleiten der Anforderung.
Der Abschnitt beschränkt diesen Header nicht nur auf den 3xx-Bereich von Statuscodes. Tatsächlich sind die einzigen explizit genannten Statuscodes 201 (Created) und 303 (Siehe Andere) . Kein Wort über diesen Header wird jedoch von jedem Statuscode benötigt .
Der Zweck der 3xx-Reihe von Codes wird jetzt beschrieben von RFC 7231, Abschnitt 6.4 :
Die 3xx-Klasse (Umleitung) des Statuscodes zeigt an, dass der Benutzeragent weitere Aktionen ausführen muss, um die Anforderung zu erfüllen. Wenn ein Kopfzeilenfeld für den Standort bereitgestellt wird, leitet der Benutzeragent MAY automatisch seine Anforderung an den vom Feldwert referenzierten URI um, selbst wenn der spezifische Statuscode nicht verstanden wird.
Der Wortlaut legt nahe, dass weder die Anwesenheit noch die automatische Umleitung auf seinen Inhalt zwingend erforderlich ist.
Zum Zeitpunkt der Erstellung dieses Artikels war die IANA HTTP Status Code Registry listet die Codes 300 bis 308 als registriert auf. Wenn eine (305) veraltet ist und eine reserviert ist (306), bleiben sieben aktive Codes übrig:
Der Code 300 soll zurückgegeben werden, wenn der Server mehrere Darstellungen einer Ressource kennt. Ab RFC 7231 gibt es keine empfohlene Methode, eine Liste möglicher Repräsentationen zu übermitteln, obwohl der Header Link über RFC 5988 wird erwähnt. Bezüglich des Headers Location sagt der RFC:
Wenn der Server eine bevorzugte Wahl hat, SOLLTE der Server ein Location-Header-Feld erzeugen, das die URI-Referenz einer bevorzugten Auswahl enthält. Der Benutzeragent kann den Wert für das Feld Standort für die automatische Umleitung verwenden.
Das bedeutet, dass der Header Location nur verwendet werden soll, wenn der Server eine bevorzugte Repräsentation hat. Wenn es keine gibt, hat der Server einfach keine solche Präferenz.
Es muss erwähnt werden, dass der Header Location alleine nicht dazu geeignet ist, alle möglichen Repräsentationen aufzulisten, da es nach seiner Grammatik ein einwertiges Feld ist, das keine Liste enthalten kann. Daher die Bedeutung von
ist undefiniert.
Dieser Antwortcode soll dem Client mitteilen, dass für die angeforderte Ressource ein ganz neuer Speicherort vorhanden ist: Nachfolgende Anforderungen müssen an den Speicherort geleitet werden, der in der Kopfzeile Location angegeben ist.
Der Server sollte ein Location-Header-Feld in der Antwort generieren, die eine bevorzugte URI-Referenz für den neuen permanenten URI enthält. Der Benutzeragent kann den Wert für das Feld Standort für die automatische Umleitung verwenden.
Auch hier ist das Vorhandensein des Headers Location keine absolute Voraussetzung. Das Fehlen dieses Headers hätte eine fragliche Praktikabilität. Die Semantik war ähnlich, aber nicht gleich der 410 (Gone) Antwort: "Diese Ressource Es wurde dauerhaft an einen neuen, noch unbekannten Ort verschoben. "
Ursprünglich wurde dies als "Temporary Redirect" spezifiziert und in späteren Spezifikationen umbenannt. Im Gegensatz zu 301 kann man diese nicht zwischenspeichern (oder nicht) oder verwenden, um URLs permanent neu zu schreiben. Der relevante Teil der Spezifikation lautet:
Der Server SOLLTE ein Location-Header-Feld in der Antwort generieren, die eine URI-Referenz für die verschiedenen URIs enthält. Der Benutzeragent kann den Wert des Felds Standort für die automatische Umleitung verwenden.
Ich glaube, die Semantik eines fehlenden Location -Headers war ziemlich genau so wie bei 301: "Diese Ressource wurde vorübergehend an einen neuen, noch unbekannten Ort verschoben."
303 soll als Antwort auf eine POST -Anfrage zurückgegeben werden, ist aber für jede Methode anwendbar. Im Allgemeinen soll der Client wissen, dass es eine geeignetere Repräsentation an einer Ersatz-URL gibt oder die angeforderte Ressource nicht über HTTP übertragen werden kann.
Im Zusammenhang mit dieser Frage ist das ein bisschen ein Kopfzerbrechen. RFC 2616, Abschnitt 10.3.4 lautet:
Die verschiedenen URI SOLLEN durch das Feld Ort in der Antwort angegeben werden.
Der relevante Abschnitt des neueren RFC 7231 scheint einfach anzunehmen, dass der Header Location vorhanden ist:
Der Server leitet den Benutzeragenten auf eine andere Ressource um, wie durch einen URI im Feld Location header
angezeigt wird
Es gibt nichts in den Errata, um dies zu klären, daher neige ich dazu, die Position von RFC 2616 einzunehmen. Die Semantik eines abwesenden Location -Headers unterscheidet sich je nach Anfrage:
POST wäre dies dasselbe wie 201 (Erstellt) oder 202 (Akzeptiert)
Diese Antwort ist in gewisser Weise etwas Besonderes, da sie den Hinweis betont, dass der Benutzeragent weitere Schritte unternehmen muss, um die Anfrage zu erfüllen. Es sollte als eine Weiterleitung zu einem neuen URI aber zu einem lokalen Cache verstanden werden. In den relevanten Teilen von RFC 7232 wird der Header Location überhaupt nicht erwähnt. In der Tat würde dies wenig Sinn machen in Bezug auf mein Verständnis der Semantik war etwas wie "die angeforderte Präsentation dieser Entität ist unverkettet geblieben und Sie werden es in Ihrem lokalen Cache finden bei ..." Das war ein großer Bruch der Trennung von Bedenken, aber ist um nicht zu sagen Location waren an diesem Ort nicht erlaubt. Dennoch war Content-Location oder ein Link header mit einem rel=self part besser geeignet. Der ehemalige wird explizit erwähnt:
Der Server, der eine 304-Antwort generiert, MUSS eines der folgenden Header-Felder generieren, die in einem gesendet wurden 200 (OK) Antwort auf dieselbe Anfrage: Cache-Control , Content-Location , Datum , ETag , Expires und Vary .
Dieser Statuscode wurde aufgrund von Sicherheitsbedenken ab RFC 7231 als veraltet eingestuft (siehe Anhang B ). . Seine Definition in RFC 2616 lautet:
Auf die angeforderte Ressource muss über den Proxy zugegriffen werden, der durch das Feld Location angegeben wird.
Dies impliziert das Vorhandensein eines Location -Headers, erfordert dies jedoch nicht explizit . Das Weglassen dieses Headers hätte die semantische Bedeutung "Diese Ressource kann nur über einige -Proxy erreicht werden."
Dieser Code wurde als Entwurf eingeführt, nachdem RFC 2068 fertiggestellt wurde und bereits durch RFC 2616 ersetzt wurde. Soweit ich weiß, hat dieser Entwurf nie den Status einer Empfehlung erreicht, daher ist dies nur der Vollständigkeit halber. Der Grundgedanke dieses Entwurfs besteht darin, Proxys mit einem Mechanismus zu versehen, um Clients (temporär) auf andere Proxies für nachfolgende Anfragen zu verweisen.
Teil dieses Entwurfs ist die Einführung des Headers Set-Proxy , der anstelle des Headers Location pro Abschnitt 2.2 :
In der ursprünglichen HTTP / 1.1-Spezifikation wurde der Header 'Location' verwendet, um die Proxy-Einstellung anzugeben.Seine Verwendung wird im Rahmen einer 305-Antwort durch den Header 'Set-Proxy' dekomprimiert. Alle neuen Implementierungen MÜSSEN den Set-Proxy-Header senden. Implementierungen KÖNNEN den 'Location' Header senden, um Abwärtskompatibilität zu ermöglichen.
Set-Proxy ist dann erforderlich im Kontext von 306, während der Header Location rein optional ist. Da der erforderliche Set-Proxy -Mechanismus Location ersetzen soll, führt die Abwesenheit des letzten Headers zu keinen semantischen Änderungen.
307 wurde als Ergebnis einer semantischen Änderung von 302 in HTTP / 1.1 eingeführt: Während Weiterleitungen über 302 can Änderungsanforderungsmethoden haben können, muss die umgeleitete Anforderung dieselbe Anforderungsmethode wie die ursprüngliche Anforderung haben.
Der relevante Teil der Spezifikation lautet:
Der Server SOLLTE ein Location-Header-Feld in der Antwort generieren, die eine URI-Referenz für die verschiedenen URIs enthält. Der Benutzeragent kann den Wert für das Feld Standort für die automatische Umleitung verwenden.
Auch hier scheint Location optional zu sein. Zu semantischen Änderungen aufgrund eines fehlenden Headers siehe 302.
Wie bei 307 sollen Weiterleitungen über 308 ihre ursprüngliche Anfrage-Methode beibehalten. Man könnte sagen 308 wären 301 als 307 bis 302.
Aus Abschnitt 3 der Spezifikation:
Der Server sollte in der Antwort, die eine bevorzugte URI-Referenz für den neuen permanenten URI enthält, ein Location-Header-Feld erzeugen.
Also, zusammenfassend haben wir diese Situation:
Das "SOLLEN" ist im Zusammenhang mit RFC 2119 zu lesen:
Dieses Wort oder das Adjektiv "EMPFOHLEN" bedeutet, dass es in bestimmten Umständen gültige Gründe geben kann, einen bestimmten Gegenstand zu ignorieren, aber die vollständigen Implikationen müssen verstanden und sorgfältig abgewogen werden, bevor ein anderer Kurs gewählt wird.
Dies unterscheidet sich von der absoluten Anforderung eines "MUSS" oder "ERFORDERLICH" (auch in diesem RFC). Kurz gesagt: Es gibt keinen Code der 3xx-Klasse, in dem der Header Location obligatorisch ist.
Es sollte beachtet werden, dass das Problem eines fehlenden Location Headers kein neues ist . Von eine andere Antwort :
301, 302, 303 und 307 stellen nur dann eine Position bereit, wenn die nächste URL bekannt ist. Andernfalls muss der Client / Benutzer entscheiden, was als nächstes zu tun ist
Tags und Links http