web-dev-qa-db-fra.com

Fragment d'URL et redirections 302

Il est bien connu que le fragment d'URL (la partie après le #) n'est pas envoyé au serveur.

Je me demande cependant comment fonctionnent les fragments lors d'une redirection de serveur (via l'état HTTP 302 et Location: en-tête) est impliqué.

Ma question est vraiment double:

  1. Si l'URL d'origine avait un fragment (/original.php#foo) et une redirection est effectuée vers /new.php, la partie fragmentée de l'URL d'origine est-elle simplement perdue? Ou est-il parfois appliqué à la nouvelle URL?
    La nouvelle URL sera-t-elle jamais /new.php#foo dans ce cas?

  2. Quelle que soit l'URL d'origine, si le serveur redirige vers une nouvelle URL avec un fragment (/new.php#foo), le fragment sera-t-il "honoré"? Ou le serveur n'a-t-il vraiment aucun intérêt à interférer avec le fragment - et le navigateur l'ignorera-t-il donc simplement en allant à /new.php ??

redirectfragment-identifierhttp-redirect
129
levik

Mise à jour 2014-juin-27 :

RFC 7231, Hypertext Transfer Protocol (HTTP/1.1): sémantique et conten , a été publié en tant que NORME PROPOSÉE. Depuis le Changelog :

La syntaxe du champ d'en-tête Location a été modifiée pour autoriser toutes les références d'URI, y compris les références relatives et les fragments, ainsi que certaines précisions sur le moment où l'utilisation des fragments ne serait pas appropriée. (Section 7.1.2)

Les points importants de Section 7.1.2. Emplacement :

Si la valeur d'emplacement fournie dans une réponse 3xx (redirection) n'a pas de composant fragment, un agent utilisateur DOIT traiter la redirection comme si la valeur hérite du composant 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 demande GET générée pour la référence URI " http://www.example.org/~tim " peut entraîner une réponse 303 (Voir autre) 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 (déplacée en permanence) 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 de fragment d'origine.

Cela devrait clairement répondre à vos questions.

Mettre à jour FIN

il s'agit d'un problème ouvert (non spécifié) avec spécification HTTP actuelle . il est abordé dans 2 numéros du groupe de travail IETF httpbis :

# 6 autorise les fragments dans l'en-tête Location. # 43 dit ceci:

Je viens de tester cela avec différents navigateurs.

  • Firefox et Safari utilisent le fragment dans l'en-tête de l'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, utilise donc 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 la redirection doivent être combinés n'est pas défini; les agents utilisateurs actuels diffèrent en effet sur le fragment qui a la priorité."

[...]

Il semble que IE8 le fait utilise le fragment idenfitier de Location (le comportement que j'ai vu peut être limité à localhost).

Ainsi, nous semblons avoir un comportement cohérent pour Safari/IE/Firefox/Chrome (juste testé), dans la mesure où le fragment de l'en-tête Location est utilisé, quel que soit l'URI d'origine.

Je change donc ma proposition pour documenter ça comme comportement attendu.

cela conduit à la réponse la plus compatible avec le navigateur et la plus future (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-tête Location sont honorés.

127
ax.

Safari 5 et IE9 et versions ultérieures suppriment le fragment de l'URI d'origine si une redirection HTTP/3xx se produit. Si l'en-tête Location de la réponse spécifie un fragment, il est utilisé.

IE10 +, Chrome 11+, Firefox 4+ et Opera "rattachera" tous le fragment de l'URI d'origine après avoir suivi une redirection 3xx).

Page de test: http://www.webdbg.com/test/redir/fragment/ .

Voir plus de discussion sur ce problème à http://blogs.msdn.com/b/ieinternals/archive/2011/05/17/url-fragments-and-redirects-anchor-hash-missing.aspx =

40
EricLaw

Juste pour vous faire savoir, ici vous pouvez trouver les spécifications appropriées. en w3c définissant comment tout doit se comporter: http://www.w3.org/TR/cuap#uri - clause 4.1 - voir ci-dessous:

Lorsqu'une ressource (URI1) a été déplacée, une redirection HTTP peut indiquer son nouvel emplacement (URI2).

Si URI1 a un identificateur de fragment #frag, alors la nouvelle cible que l'agent utilisateur devrait essayer d'atteindre serait URI2 # frag. Si URI2 possède déjà un identifiant de fragment, alors #frag ne doit pas être ajouté et la nouvelle cible est URI2.

Incorrect: la plupart des agents utilisateurs actuels implémentent des redirections HTTP mais n'ajoutent pas l'identifiant de fragment au nouvel URI, ce qui confond généralement l'utilisateur car ils se retrouvent avec la mauvaise ressource.

Les références:

Les redirections HTTP sont décrites dans la section 10.3 de la spécification HTTP/1.1 [RFC2616]. Le comportement requis est décrit en détail dans "Gestion des identificateurs de fragments dans les URL redirigées" [RURL]. Le terme "Persistent Uniform Resource Locator (PURL)" désigne une URL (un cas spécial d'URI) qui pointe vers une autre via une redirection HTTP. Pour plus d'informations, reportez-vous à "Persistent Uniform Resource Locators" [PURL]. Exemple:

Supposons qu'un utilisateur demande la ressource à http://www.w3.org/TR/WD-Ruby/#changes et que le serveur redirige l'agent utilisateur vers http: // www .w3.org/TR/Ruby / . Avant de récupérer ce dernier URI, le navigateur doit y ajouter l'identifiant de fragment #changes: http://www.w3.org/TR/Ruby/#changes .

9
Marcin