Question Quel est l’intérêt d’avoir «www» dans une URL?


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

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


223
2018-05-27 08:02


origine


En relation: stackoverflow.com/questions/1109356/… - Quintin Par
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:


Une des raisons pour lesquelles vous avez besoin www ou un autre sous-domaine a à voir avec 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 pour certains utilisateurs. akamai.com adresse. 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 pas avoir tout autre enregistrements pour ce même hôte. Cependant, votre domaine de premier niveau example.com doit 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.com vous donne la possibilité d'utiliser un CNAME pour www qui pointe vers votre CDN, tout en laissant les enregistrements NS et SOA requis sur example.com. le example.com enregistrement aura généralement aussi un enregistrement A pour désigner un hôte qui redirigera vers www.example.com en utilisant une redirection HTTP.


193
2018-05-27 08:10



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
Comment se fait-il que personne ne mentionne le ALIAS (ou ANAME enregistrements) dans ce genre de sujet? Ne donne-t-il pas les mêmes résultats que le CNAME sur le domaine nu (sauf pour le problème des cookies ...)? - Augustin Riedinger
@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
@AugustinRiedinger n'est pas supporté par la plupart des DNS les serveurs. Mais si votre fournisseur possède un serveur DNS qui prend en charge ces fonctionnalités, ce qui ne devrait poser aucun problème avec les clients. - Koen.


Note: Au moment de la ratification et de la mise en œuvre (par tous les navigateurs actuels, sauf éventuellement MSIE 11, voir commentaires) de RFC 6265 En 2011, les informations suivantes ne sont plus exactes, car les cookies ne sont jamais définis par défaut pour tous les sous-domaines.

Historiquement, une bonne raison technique à faire www.example.com canonique était que les cookies d’un domaine principal (c.-à-d. example.com) ont été 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 c’est vraiment dangereux si vous ne voulez télécharger que 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 lors de la demande d’une ressource image.

Une bonne solution consiste donc à utiliser un sous-domaine pour les ressources statiques, telles que 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.com pour le contenu dynamique, cela signifie que les cookies ne doivent être envoyés à www.example.com, ne pas static.example.com.

Si, toutefois, example.com est votre site principal, alors les cookies seront envoyés à tout sous-domaines, y compris static.example.com.

Maintenant, cela n’est pas pertinent pour la plupart des sites, mais changer votre URL canonique plus tard n’est pas une bonne idée. example.com au lieu de www.*, vous êtes fondamentalement coincé avec elle.

Une alternative est d'utiliser un tout différent URL pour les ressources statiques. Stack Overflow par exemple utilise sstatic.net, YouTube utilise ytimg.com etc. …


99
2018-05-27 08:15



Au fait, je n’aime vraiment pas www.x En tant qu'URL canonique, personnellement, j'utiliserais probablement une URL différente pour les ressources statiques si je devais concevoir un grand site. - Konrad Rudolph
@RobinWinslow Mais le réglage de la cuisson est activé domain=example.com va définir le cookie sur le domaine apex et sur les sous-domainesPour éviter cela, vous pouvez ne pas utiliser le domaine apex pour HTTP. Bien que convenu, une autre solution serait simplement de ne pas spécifier domain lors de la mise en place du cookie. Je me demande si cela a changé depuis que j’ai écrit ma réponse (qui est antérieure à la RFC 6265!) mais je ne peux pas être dérangé pour le regarder maintenant. - Konrad Rudolph
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). À ce jour, nous pouvons supposer que tous les navigateurs le suivront. Voir stackoverflow.com/questions/1062963/… et bayou.io/draft/cookie.domain.html. Compte tenu de cela, je pense que votre réponse est trompeuse depuis au moins sept ans, même si Pourrais avoir été précis dans certains cas au moment de la rédaction. Pourriez-vous le mettre à jour pour clarifier ce fait? - Robin Winslow
@RobinWinslow Oui, fera l'affaire. - Konrad Rudolph
@ KonradRudolph effectivement, selon mxsasha.eu/blog/2014/03/04/definitive-guide-to-cookie-domains, le comportement indésirable que vous avez décrit a peut-être existé dans IE11 au moment de la rédaction de cet article et peut-être même - ce qui reste la version la plus récente d’Internet Explorer. Ce serait très important et mérite d'être mentionné, mais il serait bon de vérifier d'abord. Je ne peux pas vérifier facilement, car je suis sur Ubuntu, mais si vous pouviez le faire, ce serait merveilleux. - Robin Winslow


www est un sous-domaine généralement utilisé pour le serveur Web sur un domaine avec d’autres à des fins telles que mail etc. De nos jours, le paradigme des sous-domaines 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.

En utilisant www ou non est une question de préférence personnelle. Des points de vue opposés peuvent être trouvés à http://no-www.org/ et http://www.yes-www.org/ - Cependant, je crois que www est inutile et ajoute simplement plus de détails à l'URI.

La plupart des serveurs envoient le même site de toute façon, mais ne redirigez pas. Pour des raisons de référencement, choisissez-en un, puis demandez à l'autre de le rediriger. 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 www Les sous-domaines créés par d’autres répondeurs sont également intéressants, tels que l’envoi de cookies aux serveurs statiques (crédit). Konrad Rudolph).


10
2018-05-27 08:11



Ressemble à no-www.org est retourné à une page parquée à vendre où oui-www.org va toujours fort. Je suppose que ça règle le problème. Tout le monde utilise "www" à partir de maintenant. - hacksalot


Si vous allez avoir des sous-domaines à d’autres fins (blog par exemple), vous pouvez différencier les sites et disposer d’une www préfixe pour le site régulier. 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).


7
2018-05-27 08:06



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 ça va, malheureusement. Vous ne pouvez pas AJAX à www.example.comde example.com ou vice versa sans quelque chose comme JSONP. - Delan Azabani


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 fournissait une méthode simple pour répartir la charge entre les serveurs.

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

le Les outils Google Webmaster vous permettent de spécifier votre domaine préféré., assurez-vous de les utiliser aussi.

Voir également:
https://stackoverflow.com/questions/1109356/www-or-not-www-what-to-choose-as-primary-site-name
https://stackoverflow.com/questions/1884157/to-www-or-not-to-www


7
2018-05-27 08:11





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


6
2018-05-27 08:08



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.


Voici une autre perspective mineure.

En l'absence de www, il existe un inconvénient mineur en ce qui concerne les supports textuels, imprimés ou en ligne, qui sont reconnus 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. Les chances sont que si vous envoyez un message en texte brut - email, tweet, publication Facebook, 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.


1
2017-11-24 18:22



http://example.com/ est pleinement qualifié alors que www.example.com n'est pas. Je préfère l’approche pleinement qualifiée car c’est toujours reconnaissable comme une URL, que ce soit https://example.uk/ ou https://blog.example.eu/ ou peu importe. Cela est compatible avec la spécification du protocole d'un site sécurisé en tant que HTTPS; www.example.com est juste un domaine et ne dit rien sur le protocole à utiliser pour y accéder. - James Haigh