Was sind die Konsequenzen für die Verwendung von relativen Positionsköpfen?

17

Gemäß der Spezifikation erfordern in einer Umleitung verwendete Standort-Header einen Servernamen

HTTP/1.1 301 Moved Permanently
...
Location: http://example.com/foo/baz/bar

Im Jahr 2012 erkennen die meisten Webbrowser jedoch einen relativen Pfad und leiten Sie unter Verwendung des ursprünglichen Servernamens an den neuen Speicherort weiter

HTTP/1.1 301 Moved Permanently
...
Location: /foo/baz/bar

Hat die Verwendung der relativen URLs in den Location-Headern negative / überraschende Folgen? Mein besonderes Anliegen ist, wie Google / Suchmaschinen dies interpretieren, aber wenn es noch etwas gibt, über das ich nicht nachdenke, würde ich es gerne hören.

— Alan Storm
quelle

Könnten Sie das genaue Bit angeben, von dem Sie diese Anforderung erhalten? Keine Herausforderung, ich sehe es einfach nicht sofort und habe keine Lust, einen ganzen RFC zu lesen, um es zu finden. Außerdem zitieren Sie die HTTP 1.0-Spezifikation, verwenden jedoch in Ihren Beispielen HTTP 1.1- Header. (Dies kann den erlaubten Inhalt ändern oder nicht.)

— '23.

Der Abschnitt 10.11. tools.ietf.org/html/rfc1945#page-44 Meines Wissens enthält die 1.1-Spezifikation auch nichts, was dies "behebt".

— Alan Storm

15

Gemäß der aktuellen Version des HTTP / 1.1-Standards RFC 2616 muss der Wert des LocationHeaders ein absoluter URI sein .

In dem von der HTTPbis-Arbeitsgruppe ausgearbeiteten Standardentwurf , der schließlich RFC 2616 ersetzen soll, wurde dies jedoch geändert, um auch relative URIs zuzulassen, anscheinend aus folgenden Gründen :

"Die Definition des Location-Headers [in RFC 2616] unterscheidet sich in verschiedener Weise davon, wie mindestens Webbrowser damit umgehen müssen, um mit Inhalten im Web zusammenzuarbeiten."

In der Praxis versteht und akzeptiert AFAIK so gut wie alle gängigen Browser und Suchmaschinen HTTP-Weiterleitungen zu relativen URLs. Doch bis der HTTPbis-Entwurf eines Tages zum offiziellen Standard wird und weithin angenommen wird, wird es immer neue oder undurchsichtige Benutzeragenten geben, die den aktuellen Standard auf den Buchstaben genau implementieren und nur absolute URLs akzeptieren. Daher ist es im Moment sicherer , nur absolute URLs in LocationKopfzeilen zu verwenden, wie es das Gesetz von Postel vorsieht :

"Sei konservativ in dem, was du sendest, liberal in dem, was du akzeptierst."

— Ilmari Karonen
quelle

3

RFC 2616 wurde von 7231 veraltet, wodurch relative URLs in Standort-Headern zulässig sind. Benutzerprogramme, die den Standard für den Brief implementieren, akzeptieren daher jetzt relative URLs

— ZoFreX

6

Abschnitt 14.30 des HTTP 1.1-RFC http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30 unterscheidet sich nicht wesentlich. Ich weiß nicht, dass Sie dafür tatsächliche praktische Einschränkungen sehen werden.

Das einzige Mal, dass ich auch nur eine Warnung zu diesem Problem gesehen habe, warnte ich beim Testen in Lynx, dass der Standort nicht absolut ist, und dass "Standortwert nicht absolut" angezeigt wird zum neuen Standort. Ich habe gerade Lynx 2.8.7 getestet und es scheint, dass dies nicht mehr funktioniert, obwohl dies möglicherweise ein Konfigurationsproblem ist.

Jetzt sagst du:

Mein besonderes Anliegen ist, wie Google / Suchmaschinen dies interpretieren, aber wenn es noch etwas gibt, über das ich nicht nachdenke, würde ich es gerne hören.

Ich glaube, dass dies einen Test rechtfertigt. Ich würde eine URL einrichten, sie in die XML- Sitemap Ihrer Website einfügen und diese URL als Weiterleitung verwenden, wie Sie sie beschreiben. Ich denke, die Sache, die zu tun ist, es mit Google Webmaster Tools zu überprüfen und zu sehen, ob es negative Konsequenzen gibt.

— artlung
quelle