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 réalisez que le nom de domaine complet doit contenir une fin .pour l'étiquette racine de l'arborescence DNS:

example.com. au lieu de example.com

Cependant, il y a des problèmes comme indiqué dans cet article de blog :

Si vous ne considérez pas le fait que l'utilisateur peut accidentellement entrer le nom de domaine avec un point à la fin, ou suivre un lien reçu de la part d'un "bien intentionné" et obtenir votre nom de domaine avec le point à la fin, comme le cela peut entraîner 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 la connexion non approuvée.

2) L'authentification peut être rompue, car les cookies sont généralement définis pour le nom de domaine sans point à la fin. L'utilisateur dans ce cas sera très surpris de ne pas pouvoir se connecter. Il est à 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 rompu.

4) Il peut y avoir des problèmes avec la mise en cache des pages du site Web (par exemple, https://www.cloudflare.com/n'efface pas le cache des pages si le nom de domaine a un point à la fin le considérant comme un nom de domaine non valide).

5) Si, dans les conditions de la configuration du serveur Web, vous comptez sur le nom de domaine particulier ($ http_host dans Nginx,% {HTTP_HOST} dans Apache) sans le point à la fin, vous pouvez faire face à une variété de situations inattendues: redirections inattendues, basiques -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 tapé un nom de domaine avec le point de fin verra quelque chose comme Bad Request - Invalid Hostname.

7) Il est possible que les moteurs de recherche trouvent que votre ressource a un contenu en double, si quelqu'un publie accidentellement ou intentionnellement des liens vers vos pages Web avec un point à la fin du nom de domaine.

Je me rends également compte que cela http://webmasters.stackexchange.com./fait un 400 Bad Request. Mais puisque le nom de domaine proprement dit devrait contenir un .à la fin, ne devrions-nous pas émettre une 400erreur ou 301rediriger 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 du transitaire canonique htaccess. Dans un sens HTTP de base, il recherche une période avant l'URI et l'intègre dans le mécanisme de transfert anti-doublon que vous utilisez. Voici un exemple comprenant une route de sous-utilisation commune de "domaine complémentaire":

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, c'est de transmettre tous les éléments suivants à un domaine www HTTP canonique:

• domain.hostdomain.com
• domain.hostdomain.com.
• www.domain.hostdomain.com
• www.domain.hostdomain.com.
• domain.com
• domain.com.
• www.domain.com.

Tous à transmettre à:

• http://www.domain.com

Il y a cependant une mise en garde - comme indiqué dans la citation du blog d'origine, SSL ne sera pas transmis correctement et affichera un avertissement de navigateur ou une erreur de 400 requêtes incorrectes 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 gérer l'avertissement SSL de l'hôte car il précède htaccess et d'autres choses.

J'aime à penser que le point de fuite est la "vraie" racine d'Internet et qu'il vit en Virginie, aux États-Unis. Si vous omettez le point, alors une racine est toujours implicite. Pour les utilisateurs normaux, c'est la même racine, et c'est la situation dont je vais parler aujourd'hui.

À ma manière perverse, je trouve en fait le point de fuite assez pratique. Si je vérifie le site Web de quelqu'un d'autre et que je veux recommencer à zéro, sans mise en cache, sans cookies, etc., et que je suis trop paresseux pour les éliminer, j'utiliserai un autre navigateur ou j'ajouterai le point. Si le site ne me redirige pas, j'ai de toutes nouvelles URL non mises en cache pour toutes les pages du site et d'autres ressources.

En tant que webmaster, je veux que toutes les personnes et tous les robots qui consultent 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 gère le problème en PHP et non dans le fichier .htaccess ou web.config, car il est plus portable et plus facile à tester sur les serveurs de développement et de transfert. Je gère mes connexions à la base de données en même temps, car elles varient également entre les serveurs de développement / transfert / 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");
    }   

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'une URL (Common Internet Scheme) était toujours et sans équivoque un nom de domaine pleinement qualifié et le mécanisme conventionnel pour distinguer les noms de domaine pleinement qualifiés des noms de domaine non entièrement les noms de domaine qualifiés ne s'appliquent pas. Que ce soit example.com. ou example.com, l'hôte était censé être le même.

- 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 du schéma Internet commun
        // <utilisateur>: <mot de passe> @ <hôte>: <port> / <url-path>
    hôte
        Le nom de domaine complet d'un hôte réseau

et "example.com" ne pouvait pas être utilisé dans les en-têtes http à ce moment-là, car rfc 1738 est de 1994 et le champ hôte n'est apparu qu'avec http 1.1 en 1997 (vous pouvez vérifier dans wikipedia).

donc, en effet, seul fqdn était autorisé dans les URL. je pense que c'était une erreur dans rfc 1738, car de cette façon, cela rendait (essayait de faire) la fonction "domaines relatifs" inutile. s'il ne le refusait pas, ils pourraient théoriquement être utilisés dans des hrefs de balises "a" dans des sites scriptés locaux ou dans de la documentation html statique au sein de grandes entreprises qui utilisaient des domaines relatifs, si les navigateurs et les serveurs le supportaient. mais même si rfc 1738 les a interdits, les gens n'y ont pas obéi: ils ont continué à utiliser des domaines de premier niveau sous une forme relative, c'est-à-dire sans point de fuite, donc ce refus par rfc 1738 n'était pas un gros problème pratique de toute façon, et les gens avaient et utilisé une alternative aux domaines relatifs: ils ont juste créé des domaines locaux de premier niveau comme "localhost" (et les ont également utilisés et utilisés sans point de fuite).

puis il dit:

Malheureusement, dans la pratique, les navigateurs Web ont toujours violé cette spécification et transmis la partie «hôte» aux procédures de qualification de nom de leurs bibliothèques client DNS lors du mappage du nom d'hôte à un ensemble d'adresses IP. (Par exemple, ceux qui ont utilisé la bibliothèque client BIND DNS quitteraient le jeu d'options RES_DNSRCH et n'ajouteraient pas le dernier point de fin s'il était manquant.)

- Je pense qu'il voulait dire que les hôtes sans point de fuite devraient être simplement supprimés comme erreur, et seuls les domaines absolus (fqdn) devraient être passés au DNS. Je pense que les navigateurs ont probablement transmis tous les domaines au DNS parce que les gens utilisaient leurs domaines locaux de premier niveau personnalisés comme "localhost". et de toute façon, plus tard dans rfc 2396 publié en 1998, l'utilisation de domaines de premier niveau dans les URL sans points de fin a été autorisée.

puis l'auteur (Jonathan de Boyne Pollard) cite le rfc 2396 et regrette qu'il ait changé selon le comportement humain établi, c'est-à-dire les normes de facto, dit qu'il serait préférable que les navigateurs obéissent au rfc 1738, et recommande à tous de n'utiliser que le fqdn, dans tous les endroits, comme il était commandé par rfc 1738.

- mais que se passerait-il si les gens obéissaient au rfc 1738? des URL comme "http://example.com/test.html "et"http: //localhost/test.html "tout devait être réécrit en"http://example.com./test.html "et"http://localhost./test.html". Le navigateur devrait soit marquer les hôtes sans points comme des erreurs, soit les rediriger en cliquant dessus vers leur forme complète / absolue. Toutes les personnes qui ont configuré des domaines locaux de premier niveau comme" localhost "devraient configurer leurs serveurs pour accepter uniquement les demandes pour des domaines comme "localhost.", ou accepter et rediriger [toutes les URL à l'intérieur] "localhost" vers [les URL correspondantes dans] "localhost.". Un texte comme "localhost" ne restera utile que lorsque vous le taperez dans la barre d'adresse du navigateur, mais cela ne serait qu'une utilisation très inutile, et la fonction de domaine relatif n'est pas nécessaire pour cela, car les navigateurs recherchent des domaines lors de la frappe. leur utilisation dans la source html deviendrait inutile car cela conduirait à ce que ces liens ne fonctionnent pas, ou en cliquant sur tous les liens avec "localhost" déplaceraient l'utilisateur vers "localhost."et ce serait juste une redirection supplémentaire à chaque clic (sur de tels liens). Par conséquent, rfc 1738 rendrait la fonctionnalité de" domaine relatif "prévue totalement inutile. Si une entreprise utilisait cette fonctionnalité et utilisait leurs domaines relatifs dans leurs sites locaux, et leurs URL avec des domaines relatifs n'étaient pas redirigées vers la forme absolue par les navigateurs, donc leurs sites fonctionnaient normalement, s'ils obéissaient également au rfc 1736, ils configureraient leurs serveurs pour n'accepter que fqdn, et ils devraient soit réécrire toutes ces URL avec fqdn, ou travaillez avec une redirection supplémentaire à chaque clic sur de telles URL. Si ces entreprises aimaient avoir un domaine court comme "team101" au lieu de "team101.microsoft.com." dans leurs barres d'adresse et leurs sources html, elles devraient commencer à utiliser leurs domaines de premier niveau internes personnalisés tels que "team101", c'est-à-dire comme "localhost. "au lieu de sous-domaines comme" team101.microsoft.com. "(qui pourrait être utilisé comme" team101 "avant de décider d'obéir au rfc 1738).

-

et j'ai découvert que le point de fuite, qui était si fortement soutenu par rfc 1738, n'est vraiment apparu 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
forme imprimée qui se termine par un point. Nous utilisons cette propriété pour distinguer:
- une chaîne de caractères qui représente 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 qui doit être complété par
 logiciel local utilisant la connaissance du domaine local (souvent
 appelé "relatif"). Par exemple, la "poneria" utilisée dans le
 Domaine ISI.EDU.

rfc 1034 (de 1987) vient de déclarer tous les domaines qui ont été utilisés, semble-t-il qu'ils étaient tous sans points de fin, les a tous déclarés devenir des domaines relatifs! mais ils fonctionnaient toujours comme auparavant, donc probablement peu de gens le savaient et continuaient de penser qu'ils demandaient sans ambiguïté un véritable site "example.com" unique lorsqu'ils utilisent "example.com" sans point de fuite. ce qui est devenu une faille de sécurité supplémentaire dans certains cas: le célèbre exemple.com réel pourrait être usurpé par un administrateur de sous-domaine même s'il n'avait pas le droit de créer un domaine local comme "localhost". donc, le rfc 1034 n'a pas non plus été très bien conçu: il semble que ses auteurs ne s'attendaient pas à ce qu'il soit {peu connu, créant ainsi une faille de sécurité}!

probablement rfc 1738 (1994) a finalement essayé de transmettre l'idée de distinction entre domaines absolus et relatifs à un large public et également de corriger cette violation de sécurité après 6 ans, {mais en corrigeant la violation de sécurité en interdisant les domaines relatifs dans les URL, il a rendu les domaines relatifs inutiles , {mais je pense qu'ils n'ont probablement pas été largement utilisés, probablement uniquement dans certaines grandes entreprises}}. alors, que serait-il [laissé] à la suite de rfc 1737, s'il était obéi? - 1) les domaines relatifs déclarés en 1987 deviendraient finalement inutiles, donc, le point de fuite, conçu pour montrer le domaine absolu, deviendrait aussi 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 de ré-autoriser les domaines relatifs dans les URL après de nombreuses années, lorsqu'un large public (grand public) commence à connaître la possibilité de domaines relatifs). 2) et rfc 1737, si elle était respectée, elle corrigerait également la faille de sécurité. - mais même rfc 1034 ne créerait pas de faille de sécurité s'il atteignait des masses et il était largement admis que l'utilisation d'un domaine relatif n'était pas sûre! - donc, la recette principale pour le corriger atteignait un large public, et publier un rfc supplémentaire n'était qu'une des nombreuses façons de le faire.

Je pense maintenant que probablement la caractéristique relative du domaine n'est pas devenue largement connue après RFC 1034 (de 1987) parce qu'elle était d'une utilité trop limitée: seulement dans certaines grandes entreprises ou réseaux locaux de fournisseurs, et c'était une caractéristique sans valeur pratique, parce que les réseaux locaux pouvaient déjà créer n'importe quel domaine local, donc cette fonctionnalité était juste pour elle-même, c'était en fait juste un texte inutile dans rfc que n'importe qui devrait connaître et utiliser sans avoir d'avantage supplémentaire! mais les gens ont créé la petite brèche de sécurité en ignorant largement le rfc, tandis que les navigateurs ont commencé à lui obéir.

J'ai vérifié la fonctionnalité relative des domaines hier, cela fonctionne. (c'est ok, car le rfc 2396 (de 1998) l'a ré-autorisé après le rfc 1034 (de 1987) refusé, et plus tard le rfc 3986 (de 2005) le permet 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 - Supplémentaire - onglet DNS. quand j'ai ajouté "google.com" puis ouvert "http: // mail / "dans firefox, il a ouvert le serveur de google, mais il n'était pas configuré pour fonctionner avec simplement" mail "dans l'en-tête http" host ", donc j'ai obtenu 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 rfc 1738 et dit:

Malheureusement, les personnes implémentant des clients de navigateur Web ne semblaient pas comprendre ce que cela signifiait. Lorsque vous accédez à un site Web, la valeur que la plupart des navigateurs Web mettent dans le champ "Hôte:" est ce que l'utilisateur a tapé, et non ce que l'ordinateur a fini par utiliser, après avoir appliqué la liste de recherche de l'utilisateur DNS pour créer un nom complet à partir du nom partiel. Par exemple, voici trois façons différentes dont l'utilisateur peut se référer à l'hôte "www.example.com". ... Lors de l'envoi du paramètre "Host:" au serveur Web, le client du navigateur Web saisit ce que l'utilisateur a tapé ("www.example.com.", "Www.example.com" ou "www") à la place de ce que le client a fini par rechercher dans DNS ("www.example.com." dans les trois cas). ...

- ce n'est pas très vrai (correct), car rfc 1738 était très strict à cet égard, et il interdisait les domaines relatifs dans toutes les URL, même s'il se trouve dans la barre d'adresse du navigateur, et l'url elle-même est la façon [recommandée] de faire toute référence à des sites, même si les gens l'écrivent sur papier, il n'était donc pas permis aux utilisateurs de se référer à ce site de cette manière, par rfc 1738, si ces utilisateurs pensaient par eux qu'ils utilisaient l'URL!

et semble que l'auteur de ce texte (Stuart Cheshire) ne connaissait pas le rfc 2396, donc ce texte est obsolète.

-

et quelle est la situation de nos jours? rfc 3986 (https://tools.ietf.org/html/rfc3986#page-21 ) permet de faire référence à un domaine absolu sans point de fuite: il est indiqué "L'étiquette de domaine la plus à droite d'un nom de domaine pleinement qualifié dans DNS peut être suivie d'un seul". "" et qu'il devrait être utilisé s'il est "nécessaire de faire la distinction entre le nom de domaine complet et un domaine local". Je pense qu'en raison des standarts de facto, il n'est presque jamais nécessaire, donc wordpress peut accepter le standart de facto et rediriger de l'adresse avec un point à la fin vers l'adresse sans lui.