Update 27.06.2014 :
RFC 7231, Hypertext Transfer Protocol (HTTP / 1.1): Semantik und Inhalt , wurde als VORGESCHLAGENER STANDARD veröffentlicht. Aus dem Changelog :
Die Syntax des Felds "Standort-Header" wurde geändert, um alle URI-Referenzen, einschließlich relativer Referenzen und Fragmente, sowie einige Klarstellungen zuzulassen, wann die Verwendung von Fragmenten nicht angemessen wäre. (Abschnitt 7.1.2)
Die wichtigen Punkte aus Abschnitt 7.1.2. Ort :
Wenn der in einer 3xx-Antwort (Umleitung) angegebene Standortwert keine Fragmentkomponente enthält, MUSS ein Benutzeragent die Umleitung so verarbeiten, als ob der Wert die Fragmentkomponente der URI-Referenz erbt, die zum Generieren des Anforderungsziels verwendet wird (dh die Umleitung erbt das Fragment der Originalreferenz, falls vorhanden).
Beispielsweise kann eine für die URI-Referenz " http://www.example.org/~tim " generierte GET-Anforderung zu einer 303-Antwort (siehe Andere) führen, die das Header-Feld enthält:
Location: /People.html#tim
Dies deutet darauf hin, dass der Benutzeragent zu " http://www.example.org/People.html#tim " umleitet.
Ebenso kann eine GET-Anforderung, die für die URI-Referenz " http://www.example.org/index.html#larry " generiert wurde, zu einer 301-Antwort (dauerhaft verschoben) führen, die das Header-Feld enthält:
Location: http://www.example.net/index.html
Dies legt nahe, dass der Benutzeragent zu " http://www.example.net/index.html#larry " umleitet , wobei die ursprüngliche Fragmentkennung beibehalten wird.
Dies sollte Ihre Fragen klar beantworten.
Update END
Dies ist ein offenes (nicht angegebenes) Problem mit der aktuellen HTTP-Spezifikation . Es wird in zwei Ausgaben der IETF-Arbeitsgruppe httpbis behandelt :
# 6 erlaubt Fragmente im LocationHeader. # 43 sagt dies:
Ich habe dies gerade mit verschiedenen Browsern getestet.
- Firefox und Safari verwenden das Fragment im Speicherort-Header.
- Opera verwendet das Fragment aus dem Quell-URI, sofern vorhanden, andernfalls das Fragment aus dem Umleitungsspeicherort
- IE (8) ignoriert das Fragment in der Standort-URI und verwendet daher das Fragment aus der Quell-URI, falls vorhanden
Vorschlag:
"Hinweis: Das Verhalten, wenn Fragment-IDs aus dem ursprünglichen URI und der Umleitung kombiniert werden müssen, ist undefiniert. Die aktuellen Benutzeragenten unterscheiden sich tatsächlich darin, welches Fragment Vorrang hat."
[...]
Es scheint , dass IE8 hat das Fragment idenfitier aus verwenden Location(das Verhalten , das ich sehe könnte auf localhost beschränkt sein).
Daher scheinen wir für Safari / IE / Firefox / Chrome (gerade getestet) ein konsistentes Verhalten zu haben, da das Fragment aus dem Location-Header verwendet wird, unabhängig von der ursprünglichen URI.
Ich ändere daher meinen Vorschlag, um das erwartete Verhalten zu dokumentieren .
Dies führt zu der am besten kompatiblen und zukunftssicheren Antwort auf Ihre Frage (da dieses Problem möglicherweise standardisiert wird):
A: Fragmente von Original-URLs werden verworfen.
B: Fragmente aus dem LocationHeader werden berücksichtigt.