Mise à jour du 27 juin 2014 :
La RFC 7231, Hypertext Transfer Protocol (HTTP / 1.1): Semantics and Content , a été publiée en tant que STANDARD PROPOSÉ. Depuis le journal des modifications :
La syntaxe du champ d'en-tête Location a été modifiée pour autoriser toutes les références URI, y compris les références relatives et les fragments, ainsi que quelques clarifications quant au moment où l'utilisation de fragments ne serait pas appropriée. (Section 7.1.2)
Les points importants de la section 7.1.2. Lieu :
Si la valeur d'emplacement fournie dans une réponse 3xx (Redirection) n'a pas de composant de fragment, un agent utilisateur DOIT traiter la redirection comme si la valeur hérite du composant de fragment de la référence URI utilisée pour générer la cible de la demande (c'est-à-dire que la redirection hérite le fragment de la référence d'origine, le cas échéant).
Par exemple, une requête GET générée pour la référence URI " http://www.example.org/~tim " peut entraîner une réponse 303 (See Other) contenant le champ d'en-tête:
Location: /People.html#tim
ce qui suggère que l'agent utilisateur redirige vers " http://www.example.org/People.html#tim "
De même, une requête GET générée pour la référence URI " http://www.example.org/index.html#larry " peut entraîner une réponse 301 (Moved Permanently) contenant le champ d'en-tête:
Location: http://www.example.net/index.html
ce qui suggère que l'agent utilisateur redirige vers " http://www.example.net/index.html#larry ", en conservant l'identifiant du fragment d'origine.
Cela devrait clairement répondre à vos questions.
Mettre à jour END
il s'agit d'un problème ouvert (non spécifié) avec la spécification HTTP actuelle . il est abordé dans 2 numéros du groupe de travail IETF httpbis :
# 6 autorise les fragments dans l'en- Location
tête. # 43 dit ceci:
Je viens de tester cela avec différents navigateurs.
- Firefox et Safari utilisent le fragment dans l'en-tête d'emplacement.
- Opera utilise le fragment de l'URI source, lorsqu'il est présent, sinon le fragment de l'emplacement de redirection
- IE (8) ignore le fragment dans l'URI de l'emplacement, donc utilisera le fragment de l'URI source, lorsqu'il est présent
Proposition:
"Remarque: le comportement lorsque les identifiants de fragment de l'URI d'origine et de la redirection doivent être combinés n'est pas défini; les agents utilisateurs actuels diffèrent en effet sur le fragment qui prime."
[...]
Il semble que IE8 n'utiliser le fragment idenfitier de (I saw comportement pourrait se limiter à localhost).Location
Ainsi, nous semblons avoir un comportement cohérent pour Safari / IE / Firefox / Chrome (juste testé), en ce que le fragment de l'en-tête Location est utilisé, quel que soit l'URI d'origine.
Je modifie donc ma proposition pour documenter cela comme un comportement attendu.
cela conduit à la réponse la plus compatible avec les navigateurs et la plus pérenne (car ce problème finira par être normalisé) à votre question:
R: les fragments des URL d'origine sont supprimés.
B: les fragments de l'en- Location
tête sont honorés.