Depuis environ 20 ans, il y a eu une discussion sur l'opportunité d'utiliser www dans le nom d'hôte canonique (CNAME) de votre site Web. Alors quoi utiliser ou non?
Bien que de nombreuses personnes utilisent les termes «nom de domaine» et «nom d'hôte» de manière interchangeable, il y a une différence entre eux, et ce n'est pas seulement une question de sémantique. Je vais simplifier un peu cette description pour me concentrer sur le point.
Pour vous, en tant qu'administrateur informatique, votre domaine sera votre réseau. Il est raisonnable de donner un nom au domaine. Le système DNS est adapté à cela, vous enregistrez donc un nom de domaine, par exemple
example.com . Maintenant, sous ce domaine, vous aurez vos propres hôtes. Chaque machine avec une connexion réseau est considérée comme un hôte. La machine de maintenance de documents WWW obtiendra naturellement le nom d'hôte
www dans votre domaine, donc son nom de domaine complet (FQDN) sera
www.example.com . Vous ferez de même pour les autres hôtes de votre réseau, que vous ayez un serveur Web ou non. Vous nettoyez donc votre réseau.
Pour accéder au serveur Web du domaine
example.com , vous devez vous rendre sur l'hôte nommé
www.example.com . Soit dit en passant, à l'époque où les dinosaures parcouraient le Web, les hôtes virtuels n'existaient pas. Chaque serveur Web ne desservait qu'un seul site Web (au moins une adresse IP). Le nom d'hôte n'avait pas d'importance s'il pointait vers la bonne adresse IP.
"Nom de domaine nu", c'est-à-dire un nom de domaine sans «www», comme
example.com , en termes de DNS, est appelé origine. Alors que le World Wide Web gagnait en popularité au milieu des années 1990, certains administrateurs ont commencé à spécifier la même adresse IP que l'hôte www comme origine. Cela permet aux visiteurs du site Web de saisir simplement
example.com dans le navigateur au lieu du nom d'hôte complet.
Puis vint le référencement
Étant donné que
example.com et
www.example.com peuvent pointer vers des adresses IP différentes et depuis janvier 1997 vers différents sites Web sur la même adresse IP, les spécialistes du référencement ont commencé à nous dire que nous devrions choisir un nom d'hôte canonique, et le reste doit pointer là (avec le code d'état HTTP 301).
Il était logique de choisir un nom. Mais lequel? Pour le référencement, cela n'a vraiment pas d'importance. L'essentiel est d'en avoir un. Mais outre le référencement, il y a d'autres problèmes. Continuez à lire.
Comment les gens comprennent-ils l'URL
Lorsque je travaillais dans une agence de marketing au début du siècle, je craignais que les gens ne comprennent pas qu'ils avaient l'adresse du World Wide Web devant nous si nous omettions la partie «www». Je veux dire, nous venons de commencer à sauter "http: //". De plus, pour des raisons historiques, j'ai personnellement choisi d'utiliser le nom d'hôte complet «correct», c'est-à-dire
www.example.com .
Aujourd'hui, je ne pense pas que ce soit important. Les gens comprendront qu'il s'agit d'une adresse Web, que www soit là ou non, quand en face d'eux se trouve un domaine de premier niveau bien connu. Étant donné qu'une version est toujours redirigée vers une autre, peu importe que votre nom d'hôte canonique soit
www.example.com , et vous n'utilisez
example.com pour les publicités imprimées que par souci de beauté. Dans le même temps, si vous avez l'un des milliers de nouveaux domaines de premier niveau tels que .beer, il est logique d'ajouter www pour les mêmes raisons que vous aviez dans le marketing au début du siècle.
Sans www c'est plus simple et plus beau
Je dois admettre que
example.com plus rapide à taper, plus facile à lire et ne fait que gagner de l’espace. Il est compréhensible que les gens aient commencé à abandonner www - et à spécifier simplement l'origine comme nom d'hôte canonique.
Alors pourquoi se disputent-ils toujours à ce sujet?
Pourquoi discutons-nous toujours de l'utilisation de «www» ou non? Laisser tout le monde utiliser ce qu'il veut, n'est-ce pas possible?
Bien sûr que vous le pouvez.
Mais si vous êtes un administrateur de site Web, vous voudrez probablement faire un choix éclairé et réfléchir à certaines choses à l'avance. Par exemple, les cookies.
Les cookies sont transmis aux sous-domaines
Les cookies définis au nom de l'hôte seront également définis pour tous les sous-domaines. Autrement dit, si le site sur
example.com définit un cookie, le navigateur enverra également ce fichier lors de la visite de
www.example.com . Ça sonne bien, c'est le même site, non? Mais les cookies iront également à
cdn.example.com ,
email.example.com ,
intranet.example.com ,
thirdpartyservice.example.com et ainsi de suite. Et de nombreux services tiers vous permettent d'utiliser votre domaine de cette façon.
Le cookie créé par l'hôte
www.example.com * ne sera * pas envoyé à un hôte "frère" comme le précédent. Votre navigateur comprend qu'il ne s'agit pas de «sous-services», mais de services complètement différents qui ne devraient pas accéder à vos cookies.
Les cookies inutiles nuisent aux performances
La façon dont HTTP et les cookies fonctionnent est qu'ils sont envoyés depuis le navigateur avec chaque demande au serveur Web. Cela signifie que si votre site définit des cookies pour l'origine (exemple.com), ce fichier doit également être envoyé pour chaque demande que vous faites, par exemple, à
email.example.com ou
intranet.example.com . Cela ralentit la connexion.
Les cookies peuvent être lus par des tiers
Donc, si le site Web est identique à l'origine (example.com) et utilise le système CMS, alors après autorisation, il émettra des cookies sur votre navigateur pour maintenir la session ouverte. Ensuite, lorsque vous visitez
someinternalservice.example.com , l'administrateur de ce service peut lire ce cookie, le copier et l'utiliser pour vous connecter au CMS d'entreprise pour
example.com en votre nom. Il en va de même pour le fournisseur de messagerie lors de la visite de
email.example.com ou du fournisseur CDN qui télécharge des ressources, telles que
static.example.com , etc.
Si vous vous inquiétez de la sécurité d'au moins quelque chose sur
example.com , assurez-vous d'inclure «www» avant. Même si cela ne vous convainc pas d'utiliser "www", je ne sais pas ce qu'il peut convaincre. Ni HTTPS ni 2FA ne seront utiles, car ce cookie est un jeton magique. Cependant, d'autres mesures de sécurité, telles que
les restrictions IP , peuvent aider.
Les cookies des sous-domaines peuvent être partagés si vous le souhaitez
Si vous avez un service sur un sous-domaine, par exemple,
sso.example.com , la RFC 6265 vous permet de définir des cookies pour l'origine et de le rendre commun avec
example.com ou
www.example.com . Ainsi, l'abandon du «domaine nu» comme nom d'hôte vous donne en fait plus de flexibilité.
Restriction DNS
En parlant de flexibilité, nous devons revenir à parler de DNS.
Il existe une limitation dans DNS: l'origine doit être un enregistrement A, c'est-à-dire pointer vers une adresse IP fixe.
Lorsque votre site devient volumineux et que vous le déplacez vers un hébergement ou souhaitez le diriger vers un pare-feu ou un service de protection DDoS, utilisez ensuite l'enregistrement CNAME pour diriger le nom d'hôte vers un autre nom d'hôte incohérent, que le fournisseur contrôle en fonction de votre trafic et de vos besoins.
Mais si le site est hébergé sur un domaine nu (example.com), vous ne pouvez pas le faire. Cependant, il n'y a aucun problème à spécifier le nom d'hôte avec «www» dans CNAME. Donc, si vous voulez une évolutivité, maintenant ou à l'avenir, vous devez définir le nom d'hôte à partir de 'www' dès le début.
Conclusion: choisissez www
C'est important que vous utilisiez www ou non. Je suis d'accord que les domaines nus semblent plus jolis, mais ce n'est qu'une question pratique pour la barre d'adresse du navigateur. Vous pouvez utiliser
www.example.com comme nom d'hôte canonique, et dans d'autres endroits, utilisez simplement le domaine nu. Les utilisateurs seront toujours redirigés si nécessaire.
Mais des arguments importants plaident en faveur de l'utilisation du nom d'hôte complet avec «www»: pour des performances, une sécurité et une flexibilité.
Alors, une fois pour toutes, mettez fin à la discussion: optez pour «www»!