Quel est l'intérêt d'avoir "www" dans une URL?


238

Hormis pour des raisons historiques, existe-t-il une raison d'avoir «www» dans une URL?

Devrais-je créer une redirection permanente de www.xyz.comvers xyz.comou de xyz.comvers www.xyz.com? Lequel suggérez-vous et pourquoi?



Inversement, à quoi sert-il pas? Pour les cookies et les sous-domaines d'une présence Web réussie, il est utile de séparer plusieurs processus.
Fiasco Labs

Cette réponse , bien que non directement liée, semble pertinente.
Skippy le Grand Gourou

Réponses:


202

L'une des raisons pour lesquelles vous avez besoin de wwwou d'un autre sous-domaine est liée à une bizarrerie de DNS et à l'enregistrement CNAME.

Supposons, aux fins de cet exemple, que vous exécutez un grand site et que vous sous-traitez l'hébergement à un CDN (réseau de distribution de contenu) tel qu'Akamai. En général, vous configurez l’enregistrement DNS de votre site en tant que CNAME à une akamai.comadresse. Cela permet au CDN de fournir une adresse IP proche du navigateur (en termes géographiques ou de réseau). Si vous utilisiez un enregistrement A sur votre site, vous ne pourriez pas offrir cette flexibilité.

Le hasard du DNS est que si vous avez un enregistrement CNAME pour un nom d’hôte, vous ne pouvez avoir aucun autre enregistrement pour ce même hôte. Cependant, votre domaine de premier niveau example.comdoit généralement avoir un enregistrement NS et SOA. Par conséquent, vous ne pouvez pas également ajouter un enregistrement CNAME pour example.com.

L'utilisation de www.example.comvous permet d'utiliser un CNAME wwwqui pointe vers votre CDN tout en laissant les enregistrements NS et SOA requis example.com. L' example.comenregistrement aura généralement aussi un enregistrement A pour désigner un hôte sur lequel www.example.comune redirection HTTP sera redirigée.


3
Vous pouvez fournir un enregistrement CNAME "par défaut" pointant vers le CDN, vous n'êtes pas obligé d'utiliser "www". Cela permet à votre serveur DNS d’avoir des RR SOA, NS, CNAME, etc. pour le même nom de domaine.
Chris S

1
Comment se fait-il que personne ne mentionne le ALIAS(ou les ANAMEdisques) dans ce genre de sujet? Ne donne-t-il pas les mêmes résultats que le CNAME sur le domaine nu (sauf en ce qui concerne le problème des cookies ...)?
Augustin Riedinger

3
@AugustinRiedinger: les enregistrements ANAME ne sont pas un type de RR DNS standard. Ils sont la propriété de fournisseurs de services spécifiques.
Greg Hewgill

Mais cela génère-t-il un problème de compatibilité? Y a-t-il une raison pour laquelle nous ne devrions pas les utiliser (en plus de ne pas être standard mais exclusif)?
Augustin Riedinger

2
@AugustinRiedinger n'est pas pris en charge sur la plupart des serveurs DNS . Mais si votre fournisseur a un serveur DNS qui prend en charge ces fonctionnalités, cela ne devrait poser aucun problème avec les clients.
Koen.

104

Remarque: à compter de la ratification et de la mise en œuvre (par tous les navigateurs actuels, à l'exception éventuellement de MSIE 11 , voir les commentaires) de la RFC 6265 en 2011, les informations suivantes ne sont plus exactes, car les cookies ne sont jamais définis par défaut sur plusieurs sous-domaines.

Historiquement , une bonne raison technique de rendre www.example.comcanonique était que les cookies d'un domaine principal (c'est-à-dire example.com) étaient envoyés à tous les sous-domaines.

Donc, si votre site utilisait des cookies, ils seraient envoyés à tous ses sous-domaines.

Cela a du sens, mais cela a un effet négatif si vous souhaitez uniquement télécharger des ressources statiques, car cela ne fait que gaspiller de la bande passante. Prenez en compte toutes les feuilles de style et les images de votre site Web: en règle générale, il n’ya aucune raison d’envoyer des cookies au serveur lorsque vous demandez une ressource image.

Une bonne solution consiste donc à utiliser un sous-domaine pour les ressources statiques, par exemple static.example.com, pour économiser la bande passante en n'envoyant pas de cookies. Toutes les images et autres téléchargements statiques peuvent être téléchargés à partir de là. Si vous utilisez maintenant www.example.comle contenu dynamique, cela signifie que les cookies ne doivent être envoyés qu'à www.example.com, pas à static.example.com.

Si, toutefois, example.comest votre site principal, des cookies seront envoyés à tous les sous-domaines, y compris static.example.com.

À présent, cela n’est pas pertinent pour la plupart des sites, mais changer votre URL canonique plus tard n’est pas une bonne idée. Une fois que vous avez choisi votre example.complace www.*, vous vous en tenez à cela.

Une alternative consiste à utiliser une URL totalement différente pour les ressources statiques. Stack Overflow, par exemple utilise sstatic.net, utilise YouTube, ytimg.cometc.…


11
En passant, je n'aime vraiment pas www.xl'URL canonique. Personnellement, j'utiliserais probablement une URL différente pour les ressources statiques si je devais concevoir un grand site.
Konrad Rudolph

1
@RobinWinslow Mais la définition de cookie activera le domain=example.comcookie sur le domaine apex et sur les sous - domaines . Pour éviter cela, évitez d'utiliser le domaine apex pour HTTP. Bien que convenu, une autre solution serait simplement de ne pas spécifier domainlors de l’installation du cookie. Je me demande si cela a changé depuis que j'ai écrit ma réponse (ce qui est antérieur à la RFC 6265 en question !), Mais je ne me dérangerai pas de la regarder maintenant.
Konrad Rudolph

2
Il semble que le comportement que je décris ait été le cas depuis au moins 2011, année de la rédaction de la RFC 6265 (davantage comme un résumé du comportement actuel du navigateur que comme un énoncé de son fonctionnement). À présent, nous pouvons supposer que tous les navigateurs le suivront. Voir stackoverflow.com/questions/1062963/… et bayou.io/draft/cookie.domain.html . Cela dit, je pense que votre réponse est trompeuse depuis au moins sept ans, même si elle aurait pu être exacte dans certains cas au moment de la rédaction. Pourriez-vous le mettre à jour pour clarifier ce fait?
Robin Winslow

2
@RobinWinslow Oui, fera l'affaire.
Konrad Rudolph


12

wwwest un sous-domaine généralement utilisé pour le serveur Web sur un domaine avec d'autres à des fins telles que, mailetc. Aujourd'hui, le paradigme de sous-domaine est inutile; Si vous vous connectez à un site Web dans un navigateur, vous obtiendrez le site Web, ou l'envoi de courrier au serveur utilisera son service de messagerie.

Utiliser wwwou non est une question de préférence personnelle. Les points de vue opposés peuvent être trouvés sur http://no-www.org/ et http://www.yes-www.org/ - cependant, je pense que cela wwwest inutile et ajoute simplement plus cruellement à l'URI.

La plupart des serveurs envoient le même site de toute façon, mais ne redirigez pas. Pour les besoins du référencement, choisissez l’un puis faites rediriger l’autre. Par exemple, un code PHP pour faire ceci:

if (preg_match('/www/', $_SERVER['SERVER_NAME'])) {
  header("Location: http://azabani.com{$_SERVER['REQUEST_URI']}");
  exit;
}

Cependant, certaines raisons encourageant l'utilisation d'un wwwsous - domaine par d'autres répondeurs sont également utiles , telles que le fait de ne pas envoyer de cookies à des serveurs statiques (crédit Konrad Rudolph ).


2
On dirait que non-www.org est revenu à une page parquée à vendre où yes-www.org est toujours en plein essor . Je suppose que ça règle le problème. Tout le monde utilise "www" à partir de maintenant.
Nunya

9

C'est assez historique. Il était une fois, auparavant, www.example.com, ftp.example.com, images.example.com, uk.example.com, etc., ce qui semblait être une chose logique à faire et une méthode simple pour répartir la charge entre les serveurs.

Ces jours-ci, je voudrais simplement aller à example.com pour le site principal et rediriger la version www vers celui-ci.

Les outils Google Webmaster vous permettent de spécifier votre domaine préféré . Assurez-vous de les utiliser également.

Voir aussi:
https://stackoverflow.com/questions/1109356/www-or-not-www-what-to-choose-as-primary-site-name
https://stackoverflow.com/questions/1884157/to- www ou pas à www


8

Si vous allez avoir des sous-domaines à d'autres fins (blog par exemple), vous souhaiterez peut-être différencier les sites et avoir un wwwpréfixe pour le site standard. Autre que cela, la seule chose importante est de choisir l'un des deux et s'y tenir (pour des raisons de référencement).


1
Je ne trouve pas de référence pour le moment, mais cela pourrait également avoir des effets sur la même politique d'origine.
Kobi

Oui, malheureusement. Vous ne pouvez pas AJAX à www.example.compartir de example.comou vice versa sans quelque chose comme JSONP.
Delan Azabani

7

Je ferais le premier. La wwwconvention vient des débuts de HTTP, où www.cmu.edu et cmu.edu étaient très probablement des machines différentes.


10
Dans les "premiers jours", il était rare de voir un enregistrement A pour un domaine. Peut-être aurait-il un enregistrement MX, mais vous y auriez rarement un hôte.
Joe H.

2

Voici une autre perspective mineure.

En l'absence de www, il existe un inconvénient mineur en ce qui concerne les supports textuels, qu'ils soient imprimés ou en ligne, et c'est de les faire reconnaître comme une adresse Web. En version imprimée, il est généralement assez évident que example.com est une adresse Web, et vous pouvez ajouter des touches de style pour la mettre en valeur. Mais un texte en ligne? Pas si facile. Il est probable que si vous envoyez un message en texte brut - qu’il s’agisse d’un courrier électronique, d’un tweet, d’une publication Facebook, d’un SMS ou autre chose -, il reconnaîtra une URL commençant par http: // ou www. mais ne reconnaîtra personne sans l’un ou l’autre. Donc, pour que l'URL devienne un lien cliquable, vous devez soit mettre www. ou http: // sur le devant, et des deux, www. est plus courte, moins encombrante à regarder et plus facile à lire.


2
http://example.com/est pleinement qualifié alors que www.example.comnon. Je préfère l'approche pleinement qualifiée car elle est toujours reconnaissable en tant qu'URL, que ce https://example.uk/soit https://blog.example.eu/ou non. Cela est compatible avec la spécification du protocole d'un site sécurisé en tant que HTTPS; www.example.comest juste un domaine et ne dit rien sur le protocole à utiliser pour y accéder.
James Haigh
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.