Comment rediriger de https: //[email protected]/x, pour simplement https://example.com/x (htaccess)?
J'ai un problème étrange où, pour une raison quelconque, les moteurs de recherche voient que j'ai des URL en double, comme https://[email protected]/x et https://example.com/x
J'aimerais que le premier (c'est-à-dire avec hi@) 301 soit redirigé vers la deuxième URL (c'est-à-dire sans hi@), via .htaccess.
J'ai essayé du code comme ci-dessous mais cela ne fonctionne pas (les autres règles de redirection que j'ai dans ce fichier .htaccess fonctionnent cependant). Des idées?
<IfModule mod_rewrite.c>
<IfModule mod_negotiation.c>
Options -MultiViews
</IfModule>
RewriteEngine On
RewriteCond %{HTTP_Host} ^www\.(.*)$ [NC]
RewriteRule ^(.*)$ http://%1/$1 [R=301,L]
# Redirect Trailing Slashes If Not A Folder...
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)/$ /$1 [L,R=301]
RewriteCond %{HTTP_Host} hi@example\.com$ [NC]
RewriteRule ^(.*)$ https://example.com/$1 [L,R=301]
</IfModule>
Comme @Stephen l'a suggéré dans les commentaires, hi est la partie du nom d'utilisateur lorsque le username:password est spécifié dans le cadre de l'URL (Voir RFC 1738 ) dans l'authentification HTTP de base.
Si tel est le cas, il ne devrait pas être repris par les moteurs de recherche
Cela dépend si d’autres sites ont (de manière malveillante) lié à l’URL dans ce format.
hi@ n'est pas envoyé dans l'en-tête de la requête Host:, vous ne pouvez donc pas le faire correspondre à la variable de serveur HTTP_Host dans Apache .htaccess. Les agents utilisateurs conformes vont supprimer cela de l'URL et créer un en-tête Authorization: codé en base64 avec ces informations avant de faire la demande.
Si vous n'utilisez pas l'authentification HTTP, vous pouvez potentiellement rediriger/bloquer toute demande contenant quelque chose dans l'en-tête de la demande Authorization HTTP. Par exemple, vous pouvez essayer ce qui suit en haut de votre fichier .htaccess (pas à la fin):
RewriteCond %{HTTP:Authorization} !^$
RewriteRule (.*) https://example.com/$1 [R=301,L]
Bien que cela soit un peu risqué, cela dépend du fait que l'agent utilisateur n'envoie pas à nouveau l'en-tête Authorization dans la deuxième demande afin d'éviter une boucle de redirection. Bien que cela ne devrait pas poser de problème pour les "vrais utilisateurs" dans ce cas, ils ne devraient de toute façon pas être "connectés". L'URL moins les informations d'identification de connexion devrait apparaître sur Googlebot (bien que cela risque de provoquer une boucle de redirection et de ne pas voir votre contenu réel, mais vous évitera le problème du contenu en double). Si vous utilisiez réellement l'authentification HTTP sur votre site, cela entraînerait certainement une boucle de redirection si l'utilisateur s'était "connecté".
Vous pouvez également servir un 410 Gone à la place pour de telles demandes (de toute façon, je ne pense pas que vous obtiendrez beaucoup de valeur de référencement pour ces URL):
RewriteCond %{HTTP:Authorization} !^$
RewriteRule ^ - [G]
UPDATE: Comme @StephenOstermiller l'a suggéré dans les commentaires, la réponse techniquement correcte consiste probablement à renvoyer un 401 Unauthorized à la place. Cela présente l’avantage supplémentaire de déconnecter l’utilisateur (s’ils étaient réellement connectés), de sorte que l’en-tête Authorization ne sera pas envoyé dans les requêtes suivantes. Et Google ne devrait pas renvoyer de réponse 4xx dans les SERP. Par exemple, semblable à ci-dessus:
RewriteCond %{HTTP:Authorization} !^$
RewriteRule ^ - [R=401]
Il est à noter qu'il est peu probable que cela affecte les vrais utilisateurs qui suivent ces liens, car il semble que les navigateurs modernes ont tendance à effacer entièrement ces informations avant de faire la demande (pour des raisons de sécurité). Il est supprimé de l'URL visible et aucun en-tête Authorization n'est envoyé. Cela semble avoir été retiré de IE il y a longtemps apparemment. Et semble également être le cas dans mes tests sur Chrome 64 (et Opera). Le rapport de bogue de Chrome sauvegarde ceci et suggère que cette fonctionnalité a été supprimée. Le rapport de bogue est fermé avec le statut "WontFix".
La question ServerFault suivante suscite de nombreuses discussions dans les commentaires sur le point de savoir si ce format d'URL "fonctionne" (étrangement, certains utilisateurs affirment que cela fonctionne dans Chrome - bien que ces commentaires soient peut-être obsolètes):
UPDATE: Notez que RFC 3986 (qui met à jour RFC 1738 - lié ci-dessus) rend obsolète le utilisation de "nom d'utilisateur: mot de passe" dans l'URL
L'utilisation du format "utilisateur: mot de passe" dans le champ userinfo est obsolète.