Quelles sont les conséquences de l'utilisation des en-têtes d'emplacement relatifs?

17

Selon la spécification , les en-têtes d'emplacement utilisés dans une redirection nécessitent un nom de serveur

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

Cependant, en 2012, la plupart des navigateurs Web reconnaîtront un chemin relatif et vous redirigeront vers le nouvel emplacement en utilisant le nom de serveur d'origine

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

Y a-t-il des conséquences négatives / surprenantes à l'utilisation des URL relatives dans les en-têtes d'emplacement? Ma préoccupation particulière est de savoir comment Google / les moteurs de recherche interpréteront cela, mais s'il y a autre chose auquel je ne pense pas, j'aimerais l'entendre.

— Alan Storm
source

Pourriez-vous citer le morceau exact duquel vous obtenez cette exigence? Pas difficile, je ne le vois pas immédiatement et je n'ai pas envie de lire un RFC entier pour le trouver. En outre, vous citez la spécification HTTP 1.0 mais utilisez des en- têtes HTTP 1.1 dans vos exemples. (Ce qui peut ou non changer le contenu autorisé.)

— Su '23

La section 10.11. tools.ietf.org/html/rfc1945#page-44 Il n'y a rien, à ma connaissance, dans la spécification 1.1 qui "corrige" cela.

— Alan Storm

15

Selon la version actuelle de la norme HTTP / 1.1, RFC 2616, la valeur de l'en- Locationtête doit être un URI absolu .

Cependant, dans le projet de norme préparé par le groupe de travail HTTPbis pour remplacer éventuellement la RFC 2616, cela a été modifié pour autoriser également les URI relatifs, apparemment parce que :

«La définition de l'en-tête Location [dans la RFC 2616] diffère de diverses manières quant à la façon dont au moins les navigateurs Web doivent les traiter pour interagir avec le contenu sur le Web»

Dans la pratique, AFAIK à peu près tous les principaux navigateurs et moteurs de recherche comprennent et acceptent les redirections HTTP vers des URL relatives. Cependant, jusqu'à ce que le projet HTTPbis devienne un jour la norme officielle et soit largement adopté, il y aura toujours des agents utilisateurs nouveaux ou obscurs qui implémenteront la norme actuelle à la lettre et n'accepteront que des URL absolues. Ainsi, la chose sûre à faire, pour l'instant, est de n'utiliser que des URL absolues dans les en- Locationtêtes, comme le suggère la loi de Postel :

"Soyez conservateur dans ce que vous envoyez, libéral dans ce que vous acceptez."

— Ilmari Karonen
source

3

La RFC 2616 est désormais obsolète par 7231, ce qui autorise les URL relatives dans les en-têtes d'emplacement. Les agents utilisateurs mettant en œuvre la norme à la lettre accepteront donc les URL relatives maintenant

— ZoFreX

6

La section 14.30 de la RFC HTTP 1.1 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30 n'est pas significativement différente. Je ne sais pas si vous allez voir de réelles limitations pratiques pour cela.

La seule fois où j'ai vu même un avertissement à propos de ce problème, c'est quand j'avais l'habitude de tester dans Lynx et que l'emplacement n'était pas absolu, il vous avertirait "La valeur de l'emplacement n'est pas absolue" - mais si je me souviens bien, cela vous laisserait quand même partir au nouvel emplacement. Je viens de tester Lynx 2.8.7 et il semble qu'il ne le fasse plus, bien que cela puisse être un problème de configuration.

Maintenant, vous dites:

Ma préoccupation particulière est de savoir comment Google / les moteurs de recherche interpréteront cela, mais s'il y a autre chose auquel je ne pense pas, j'aimerais l'entendre.

Je pense que cela mérite un test. Je mettrais en place une URL, la mettrais dans le plan du site xml de votre site et que cette URL soit une redirection comme vous le décrivez. Je pense que la chose à faire est de le vérifier à l'aide des outils Google pour les webmasters et de voir s'il y a des conséquences négatives.

— artlung
source