Comment les sites Web doivent-ils gérer le nom d'hôte avec un point de fin?
J'ai lu cette question Comment les URL peuvent-elles avoir un point. À la fin, par exemple www.bla.de.? et me rendre compte que le nom de domaine complet doit contenir un . final pour le libellé racine du DNS arbre:
example.com. au lieu de example.com
Cependant, certains problèmes sont signalés dans cet article de blog :
Si vous ne tenez pas compte du fait que l'utilisateur peut entrer accidentellement le nom de domaine avec un point à la fin, ou suivre un lien reçu d'un "bon acheteur" et obtenir votre nom de domaine avec le point à la fin, il peut en résulter des conséquences inattendues:
1) Si le site Web utilise HTTPS, lors de la navigation vers le nom de domaine avec le point à la fin, le navigateur affichera l’avertissement sur une connexion non sécurisée.
2) L’authentification peut être rompue, car les cookies sont généralement configurés pour le nom de domaine sans point à la fin. Dans ce cas, l'utilisateur sera assez surpris de ne pas pouvoir se connecter. Il est intéressant de noter que si vous définissez un cookie pour un nom de domaine avec un point à la fin, ce cookie ne sera pas transmis au nom de domaine sans le point. à la fin et vice versa.
3) JavaScript sur la page peut être cassé.
4) Il peut y avoir des problèmes avec la mise en cache des pages de sites Web (par exemple,
https://www.cloudflare.com/ne supprime pas le cache des pages si le nom de domaine comporte un point à la fin, considérant qu'il s'agit d'un nom de domaine non valide).5) Si, dans les conditions de la configuration du serveur Web, vous vous fiez au nom de domaine particulier ($ http_Host dans Nginx,% {HTTP_Host} dans Apache) sans le point à la fin, vous pouvez être confronté à diverses situations inattendues: redirections inattendues, problèmes d'autorisation, etc.
6) Si le serveur Web n'est pas configuré pour accepter les demandes sur le nom de domaine avec le point de fin, tout utilisateur qui a accidentellement saisi un nom de domaine avec le point de fin verra quelque chose comme Requête incorrecte - Nom d'hôte non valide.
7) Il est possible que les moteurs de recherche trouvent que votre ressource contient un contenu dupliqué si quelqu'un publie accidentellement ou intentionnellement des liens vers vos pages Web avec un point à la fin du nom de domaine.
Je réalise aussi que http://webmasters.stackexchange.com./ fait un 400 Bad Request. Mais puisque le nom de domaine proprement dit doit contenir un . à la fin, ne devrions-nous pas émettre d'erreur 400 ou 301 pour les noms d'hôtes sans point de fin? Quelle est la bonne façon de traiter cette question de manière cohérente et cohérente?
Pour répondre partiellement à votre question, vous pouvez l'ajouter aux règles de transfert htaccess canoniques. Dans un sens HTTP basique, il recherche une période avant l'URI et l'insère dans le mécanisme de transmission anti-duplicata que vous utilisez. Voici un exemple incluant une sous-route commune "addon domain":
RewriteCond %{HTTP_Host} ^domain\.hostdomain\.com(|\.)$ [OR]
RewriteCond %{HTTP_Host} ^www\.domain\.hostdomain\.com(|\.)$ [OR]
RewriteCond %{HTTP_Host} ^domain\.com(|\.)$ [OR]
RewriteCond %{HTTP_Host} ^www.domain\.com\.$
RewriteRule ^(.*)$ "http\:\/\/www\.domain\.com\/$1" [R=301,L]
Ce que cela ferait serait de transférer tout ce qui suit à un domaine HTTP canonique:
- domain.hostdomain.com
- domain.hostdomain.com.
- www.domain.hostdomain.com
- www.domain.hostdomain.com.
- domain.com
- domain.com.
- www.domaine.com.
Tous à:
Il y a une réserve à cela cependant - comme indiqué dans la citation initiale du blog, SSL ne sera pas transféré correctement et affichera un avertissement de navigateur ou une erreur de requête incorrecte 400. dans la plupart des instances de serveur (en particulier avec HSTS). En effet, il voit le "SSL" hôte dans un cas d'utilisation post-TLD. Je ne suis pas sûr d'une solution de contournement pour traiter l'avertissement Host SSL, car il vient avant htaccess et ainsi de suite.
mon commentaire à https://core.trac.wordpress.org/ticket/35248#comment:9 :
ma réponse au texte par le premier lien ( https://web.archive.org/web/20160604095348/http://homepage.ntlworld.com/jonathan.deboynepollard/FGA /web-fully-qualified-domain-name.html ):
À l'origine, comme défini dans la RFC 1738 (§ 3.1), la partie "hôte" d'un URL (schéma Internet commun) était toujours et sans équivoque un nom de domaine complet et le mécanisme conventionnel permettant de distinguer les noms de domaine complets de ceux qui ne le sont pas. les noms de domaine qualifiés ne s'appliquaient pas. Que ce soit exemple.com. ou exemple.com, l'hôte était censé être identique.
- Je pense qu'il n'a pas raison, je pense que "example.com" n'était pas autorisé du tout dans les URL selon RFC 1738, il est cité dans le deuxième texte, et je le cite:
3.1. Syntaxe commune des schémas Internet //<utilisateur>:<password>@<Host>:<port>/<url-path> Host Nom de domaine complet d'un Hôte réseau
et "example.com" ne peut pas être utilisé dans les en-têtes http à ce moment-là, car la RFC 1738 date de 1994 et le champ Host n'apparaît qu'avec http 1.1 en 1997 (vous pouvez vérifier dans wikipedia).
ainsi, en effet, seul fqdn a été autorisé dans les URL. Je pense que c’était une erreur dans la RFC 1738, car de cette manière, la fonctionnalité "domaines relatifs" était rendue inutile. si elle ne le refusait pas, ils pourraient théoriquement être utilisés dans "une" balise hrefs dans des sites scriptés locaux ou une documentation html statique dans de grandes entreprises utilisant des domaines relatifs, si les navigateurs et les serveurs le prenaient en charge. mais même si la ref 1738 les désavouait, les gens n'y obéissaient pas: ils continuaient à utiliser les domaines de niveau supérieur sous une forme relative, c'est-à-dire sans point de fuite, de sorte que cette désapprobation par la ref 1738 n'était de toute façon pas un gros problème aux domaines relatifs: ils ont juste créé des domaines de premier niveau locaux tels que "localhost" (et les ont utilisés et utilisés également sans point de fin).
puis il dit:
Malheureusement, dans la pratique, les navigateurs Web ont toujours violé cette spécification et transmis la partie "Host" aux procédures de qualification de nom de leurs bibliothèques de client DNS lors du mappage du nom d'hôte sur un ensemble d'adresses IP. (Par exemple, ceux qui utilisaient la bibliothèque du client DNS BIND laisseraient l'ensemble d'options RES_DNSRCH et n'auraient pas ajouté le dernier point final s'il était manquant.)
- Je pense qu'il voulait dire que les hôtes sans point de fuite devraient être simplement rejetés comme une erreur et que seuls les domaines absolus (fqdn) devraient être passés au DNS. Je pense que les navigateurs ont probablement passé tous les domaines à DNS car les utilisateurs utilisaient leurs domaines de premier niveau personnalisés, tels que "localhost". et de toute façon, plus tard dans la RFC 2396 publiée en 1998, l’utilisation de domaines de premier niveau dans les URL sans points de fin était autorisée.
puis l'auteur (Jonathan de Boyne Pollard) cite la RFC 2396 et regrette que cela ait changé en fonction du comportement humain établi, c.-à-d. des positions de facto; tous les lieux, comme il était commandé par RFC 1738.
- mais que se passerait-il si les gens obéissaient à la RFC 1738? des URL telles que " http://example.com/test.html " et " http: // localhost/test. html "tous devaient être réécrits en tant que" http://example.com./test.html "et" - http://localhost./test.html ". Le navigateur devra marquer les hôtes sans points comme erreur ou rediriger en cliquant dessus pour en obtenir la forme complète/absolue. toutes les personnes ayant configuré des domaines de premier niveau locaux tels que "localhost" devraient configurer leurs serveurs pour accepter uniquement les demandes de domaines tels que "localhost". , ou acceptez et redirigez [toutes les URL à l'intérieur] "localhost" vers [les URL correspondantes dans] "localhost.". un texte comme "localhost" resterait utile uniquement lorsque vous le saisissez dans la barre d'adresse du navigateur, mais ce ne serait qu'un usage très inutile, et la fonctionnalité de domaine relatif n'est pas nécessaire pour cela, car les navigateurs recherchent des domaines lors de la frappe. leur utilisation dans les sources HTML deviendrait inutile car cela ferait que de tels liens ne fonctionneraient pas, ou cliquer sur tous les liens avec "localhost" aurait pour effet de déplacer l'utilisateur vers "localhost". et ce serait juste une redirection supplémentaire à chaque clic (sur de tels liens). Ainsi, la RFC 1738 rendrait la fonction de "domaine relatif" prévue totalement inutile. si une entreprise utilisait cette fonctionnalité et utilisait ses domaines relatifs sur ses sites locaux et que les URL des URL relatives aux domaines relatifs n'étaient pas redirigées par les navigateurs; leurs sites fonctionnaient donc normalement. S'ils obéissaient également à la norme 1736, ils configureraient leurs serveurs. pour n'accepter que fqdn, et ils devraient soit réécrire toutes leurs URL de ce type avec fqdn, soit utiliser une redirection supplémentaire à chaque clic sur ces URL. si ces entreprises préféraient avoir un domaine court du type "team101" au lieu de "team101.Microsoft.com". Dans leurs barres d'adresse et leurs sources HTML, ils devraient commencer à utiliser leurs domaines internes de premier niveau personnalisés, tels que "team101". c'est-à-dire comme "localhost". au lieu de sous-domaines tels que "team101.Microsoft.com". (qui pourrait être utilisé uniquement comme "team101" avant qu'ils ne décident d'obéir à la RFC 1738).
-
et j’ai découvert que le point de fuite, qui était si fortement soutenu par la RFC 1738, n’apparaissait vraiment qu’après le standart sans points de fuite! il est apparu avec RFC 1034 en 1987, il est cité dans le deuxième lien, et je le cite:
Puisqu'un nom de domaine complet se termine par l'étiquette racine, cela conduit à un formulaire imprimé Qui se termine par un point. Nous utilisons cette propriété pour distinguer entre: - une chaîne de caractères représentant un nom de domaine complet (Souvent appelé "absolu"). Par exemple, "poneria.ISI.EDU." - une chaîne de caractères qui représente les étiquettes de départ d'un nom de domaine Incomplet et devant être complétée par le logiciel local . en utilisant la connaissance du domaine local (souvent appelée "relative"). Par exemple, "poneria" utilisé dans le domaine ISI.EDU.
la RFC 1034 (de 1987) vient de déclarer tous les domaines utilisés, semble-t-il tous sans points de fuite, les déclare tous comme des domaines relatifs! mais ils fonctionnaient toujours comme avant, donc peu de gens étaient au courant et ont continué à penser qu’ils demandaient sans ambiguïté un véritable site "example.com" unique en utilisant "exemple.com" sans point de fin. Cela est donc devenu une atteinte supplémentaire à la sécurité dans certains cas: un administrateur de sous-domaine pouvait usurper l'identité de real real.com même s'il ne disposait pas du droit de créer un domaine local comme "localhost". La RFC 1034 n’était donc pas très bien conçue: il semble que ses auteurs ne s’attendaient pas à ce que ce soit {méconnu, créant ainsi une faille de sécurité}!
probablement rfc 1738 (1994) a finalement essayé de porter l'idée de distinction entre les domaines absolus et relatifs à un large public et de réparer cette faille de sécurité au bout de 6 ans, {mais en corrigeant la faille de sécurité en interdisant les domaines relatifs dans les URL, elle rendait les domaines relatifs inutiles , {mais je pense qu’ils n’ont probablement pas été largement utilisés, probablement seulement dans certaines grandes entreprises}}. alors, que serait-il [à gauche] du résultat de la résolution 1737, s’il était obéi? - 1) les domaines relatifs déclarés en 1987 deviendraient finalement inutiles, ainsi, le point de fuite, conçu pour indiquer le domaine absolu, deviendrait également finalement inutile et redondant "légalement", c'est-à-dire tel que défini par les rfcs! (mais peut-être ont-ils prévu plus tard d'autoriser à nouveau les domaines relatifs dans les URL après de nombreuses années, quand un large public (le grand public) commencera à connaître la possibilité de créer des domaines relatifs). 2) et si la RFC 1737 était obéie, elle remédierait également à la violation de la sécurité. - Mais même la RFC 1034 ne créerait pas la faille de sécurité si elle atteignait des masses et il était largement compris que l’utilisation du domaine relatif n’est pas sûre! - donc, la recette principale pour le réparer touchait un large public, et la publication d’un autre rfc n’était qu’un des nombreux moyens de le faire.
je pense maintenant que la caractéristique de domaine relatif n’a probablement pas été largement connue après la RFC 1034 (de 1987), car son utilisation était trop limitée: elle n’était utile que dans les réseaux locaux de certaines grandes entreprises ou fournisseurs, et elle n’avait aucune valeur pratique, Parce que les réseaux locaux pouvaient déjà créer n'importe quel domaine local, cette fonctionnalité était donc juste pour elle-même, il s'agissait en fait d'un texte inutile en RFC que tout le monde devrait connaître et utiliser sans aucun avantage supplémentaire! mais les gens ont créé la petite faille de sécurité en ignorant largement la RFC, tandis que les navigateurs ont commencé à y obéir.
j'ai vérifié la fonctionnalité de domaines relatifs hier, cela fonctionne. (ça va, parce que la RFC 2396 (de 1998) l'a ré-autorisée après que la RFC 1034 (de 1987) ait nié, et plus tard, la RFC 3986 (de 2005) les autorise toujours). J'ai ajouté le suffixe DNS dans Windows 10 - Panneau de configuration - ... - Propriétés du périphérique réseau - Propriétés ipv4 - Autres - Onglet DNS. quand j'ai ajouté "google.com" puis ouvert " http: // mail / " dans firefox, il a ouvert le serveur de Google, mais il n'a pas été configuré pour fonctionner avec " mail "dans l'en-tête http" Host ", donc j'ai quelque chose comme" 404 "page.
-
ma réponse au texte par le deuxième lien ( http://www.dns-sd.org/trailingdotsindomainnames.html ):
il cite également la règle dans la RFC 1738 et dit:
Malheureusement, les personnes implémentant des clients de navigateur Web semblaient ne pas comprendre ce que cela voulait dire. Lorsque vous accédez à un site Web, la plupart des navigateurs Web insèrent dans le champ "Hôte:" ce que l'utilisateur a saisi, et non ce que l'ordinateur a réellement utilisé, après application de la liste de recherche de l'utilisateur DNS pour constituer un nom complet à partir du nom de fichier. nom partiel. Par exemple, l'utilisateur peut se référer de trois manières différentes à l'hôte "www.example.com". ... Lors de l'envoi du paramètre "Host:" au serveur Web, le client du navigateur Web insère ce que l'utilisateur a saisi ("www.exemple.com.", "Www.exemple.com" ou "www") de ce que le client a fini par rechercher dans le DNS ("www.example.com." dans les trois cas). ...
- ce n'est pas très vrai (correct), car la RFC 1738 était très stricte à cet égard, et elle interdisait les domaines relatifs dans toutes les URL, même si elle se trouvait dans la barre d'adresse du navigateur, et l'URL elle-même est la méthode [recommandée] de création. toutes les références à des sites, même si les gens l'écrivent sur papier, il n'était donc pas permis aux utilisateurs de faire référence à ce site de cette manière-là, par RFC 1738, si ces utilisateurs pensaient qu'ils utilisaient une URL!
et il semble que l'auteur de ce texte (Stuart Cheshire) ne connaissait pas la RFC 2396, ce texte est donc obsolète.
-
et quelle est la situation aujourd'hui? La rfc 3986 ( https://tools.ietf.org/html/rfc3986#page-21 ) permet de se référer au domaine absolu sans point de fin: elle indique "Le domaine situé le plus à droite L’étiquette d’un nom de domaine pleinement qualifié dans le système DNS peut être suivie d’un "." "unique et doit être utilisée s’il est" nécessaire de distinguer le nom de domaine complet du domaine local ". Je pense qu'en raison de standarts de facto, il n'est presque jamais nécessaire, donc wordpress peut accepter le standart de facto et rediriger une adresse avec un point de fuite vers l'adresse qui ne le contient pas.
J'aime penser que le point de fuite est la "vraie" racine d'Internet et qu'il réside en Virginie, aux États-Unis. Si vous omettez le point, une racine est toujours impliquée. Pour les utilisateurs normaux, c'est la même racine, et c'est la situation dont je vais parler aujourd'hui.
De manière perverse, je trouve le point de fuite tout à fait pratique. Si je consulte le site Web de quelqu'un d'autre et que je veux recommencer à zéro, sans cache, sans cookies, etc., et que je suis trop paresseux pour le vider, je vais utiliser un autre navigateur ou ajouter le point. Si le site ne me redirige pas, j'ai des URL fraîches non mises en cache pour toutes les pages du site et d'autres ressources.
En tant que webmaster, je souhaite que toutes les personnes et les robots visionnant une page la consultent avec la même URL, et donc avec le même nom d'hôte. Si le nom d'hôte n'est pas celui que je veux qu'ils utilisent, je ferai une redirection 301 immédiate afin qu'ils voient l'URL correcte dans leur navigateur. Pour mes sites basés sur PHP, je traite le problème dans PHP et non dans le fichier .htaccess ou web.config, car il est plus portable et est plus facile à tester sur les serveurs de développement et de stockage intermédiaire. Je gère mes connexions de base de données en même temps, car elles varient également selon les serveurs de développement/intermédiaire/de production.
Voici une version simplifiée de mon code typique. Notez les redirections canoniques vers la fin.
$Host = $_SERVER['HTTP_Host'];
switch ( $Host ) {
case 'exampleweb.local': // my local dev machine
$MysqliParams = array(
'Host' => 'localhost',
'username' => 'root',
'passwd' => 'snoopy',
'dbname' => 'exampledb');
break;
case 'www.exampleweb.com': // the "live" site
$MysqliParams = array(
'Host' => 'superhost1.net',
'username' => 'examp302',
'passwd' => 'anything-but-snoopy',
'dbname' => 'examp302_db');
$GoogleAccount = 'UA-13243546-01; // only enable for live site
break;
case 'exampleweb.mystagingsite.net': // the client preview site
$MysqliParams = array(
'Host' => 'superhost1.net',
'username' => 'examp302',
'passwd' => 'anything-but-snoopy',
'dbname' => 'examp302_staging');
break;
case 'exampleweb.com': // canonical redirects
case 'exampleweb.com.':
case 'www.exampleweb.com.':
header('HTTP/1.1 301 Moved Permanently');
header("Location: http://www.exampleweb.com");
exit;
default:
die("invalid hostname $Host");
}