Location

Verwendung

Server fügen Location ein, wenn sie Clients an eine andere URL verweisen. Der Header tritt in zwei Zusammenhängen auf: bei Weiterleitungsantworten und bei der Erstellung von Ressourcen.

Bei Weiterleitungen teilt der Location-Wert dem Client mit, wohin die nächste Anfrage zu senden ist. Das Verhalten hängt vom Statuscode ab:

Bei der Erstellung von Ressourcen enthält eine 201 Created-Antwort ein Location, das auf die neu erstellte Ressource verweist. Damit erhält der Client eine direkte Referenz, ohne anschließend suchen zu müssen.

Der Location-Wert akzeptiert sowohl absolute als auch relative URLs. Relative URLs werden gegen die Anfrage-URI aufgelöst.

Hinweis

Der Location-Header und der Content-Location-Header erfüllen unterschiedliche Zwecke. Location verweist auf das Weiterleitungsziel oder die neu erstellte Ressource. Content-Location gibt die direkte URL der zurückgegebenen Repräsentation an.

Hinweis

Suchmaschinen folgen Weiterleitungen und übertragen bei permanenten Weiterleitungen (301, 308) die Linkstärke (Ranking-Wert) auf die Ziel-URL. Temporäre Weiterleitungen (302, 307) geben die Linkstärke nicht immer weiter. Der korrekte Statuscode bei URL-Migrationen bewahrt die Suchrankings.

URL

Der Wert ist eine einzelne URI-Referenz, die auf den Zielort verweist.

Location: <url>

Die URL ist entweder eine absolute URI mit Schema und Host oder eine relative Referenz, die gegen die Anfrage-URI aufgelöst wird.

Beispiel

Eine permanente Weiterleitung von einer alten Domain auf eine neue fordert Clients auf, Lesezeichen und Links zu aktualisieren. Bei 301 dürfen Clients die Anfragemethode von POST auf GET ändern.

HTTP/1.1 301 Moved Permanently
Location: https://new.example.re/products

Eine permanente 308-Weiterleitung behält die ursprüngliche Anfragemethode bei und macht die Weiterleitung damit für POST und andere Nicht-GET-Anfragen sicher.

HTTP/1.1 308 Permanent Redirect
Location: https://new.example.re/products

Nach dem Erstellen einer Ressource über eine POST-Anfrage gibt der Server 201 mit dem Location der neuen Ressource zurück.

HTTP/1.1 201 Created
Location: /api/orders/7891
Content-Type: application/json

Eine 303-Antwort nach dem Absenden eines Formulars leitet den Client mittels GET auf eine Ergebnisseite weiter.

HTTP/1.1 303 See Other
Location: /search/results?q=http+headers

Fehlersuche

Fehlgeschlagene Weiterleitungen zeigen sich häufig als Endlosschleifen, defekte URLs oder fehlende Header in der Antwort.

Weiterleitungsschleife. Der Location-Header verweist zurück auf die aktuelle URL oder auf eine andere URL, die wiederum zurückleitet, wodurch ein endloser Kreislauf entsteht. Browser brechen nach einer festgelegten Anzahl von Sprüngen ab und zeigen einen ERR_TOO_MANY_REDIRECTS-Fehler an. Verfolgen Sie die Kette mit curl -L -v, um die Schleife zu identifizieren. Häufige Ursachen sind eine Serverregel, die HTTP auf HTTPS weiterleitet, während ein Load-Balancer HTTPS zurück auf HTTP leitet, oder nginx-return-301-Regeln, die auf die Ziel-URL zutreffen. Setzen Sie in nginx if ($scheme = http)-Schutzbedingungen eng begrenzt ein und testen Sie mit beiden Protokollen.

Relative URL wird nicht korrekt aufgelöst. Der Location-Wert akzeptiert relative Referenzen, aber manche älteren Clients und Zwischeninstanzen erwarten eine absolute URL. Ein Pfad wie /new-page wird gegen die Anfrage-URI aufgelöst. Lässt man den führenden Schrägstrich weg, entsteht ein relativer Pfad, der gegen das aktuelle Verzeichnis aufgelöst wird und unerwartete Ergebnisse liefert. Verwenden Sie absolute URLs mit Schema und Host, um Mehrdeutigkeit zu vermeiden.

Fehlender Location-Header bei einer 3xx-Antwort. Ein Weiterleitungsstatuscode ohne Location-Header lässt den Client ohne Ziel zurück. Browser zeigen eine leere Seite oder einen Fehler an. Prüfen Sie die Serverantwort mit curl -I https://example.re/old-path und bestätigen Sie, dass der Header vorhanden ist. In Apache enthalten die Direktiven Redirect und RedirectMatch den Header stets. Eigener Anwendungscode muss den Header ausdrücklich setzen.

Protokoll-Abweichung im Weiterleitungsziel. Eine HTTP-URL im Location-Header auf einer HTTPS-Site löst Mixed-Content-Warnungen aus oder blockiert die Weiterleitung in strengen Umgebungen. Stellen Sie sicher, dass die Ziel-URL zum ursprünglichen Protokoll passt oder auf HTTPS hochstuft. Verwenden Sie in nginx return 301 https://$host$request_uri;, um das sichere Schema beizubehalten.

Fragment wird über Weiterleitungen hinweg nicht beibehalten. Der Fragmentbezeichner (#section) aus der ursprünglichen URL wird im Location-Header nicht weitergegeben. Browser hängen das ursprüngliche Fragment nur dann wieder an das Weiterleitungsziel an, wenn die Ziel-URL kein eigenes Fragment enthält. Enthält der Location-Wert ein anderes Fragment, geht das ursprüngliche verloren. Serverseitiger Code hat keinen Zugriff auf Fragmente, da Browser sie nicht in Anfragen mitsenden.

Weiterleitungsketten debuggen. Führen Sie curl -L -v https://example.re/start aus, um allen Weiterleitungen zu folgen und jeden Sprung mit Statuscodes und Headern zu sehen. Auch der Netzwerk-Tab der DevTools zeigt die vollständige Kette. Filtern Sie nach Dokumenttyp, um Weiterleitungsantworten von Subressourcen-Anfragen zu trennen.