À part pour des raisons historiques, y a-t-il une raison d'avoir "www" dans une URL ?
Dois-je créer une redirection permanente de www.xyz.com a xyz.com ou de xyz.com a www.xyz.com ? Lequel suggérez-vous et pourquoi ?
L'une des raisons pour lesquelles vous avez besoin www ou un autre sous-domaine est lié à une bizarrerie du DNS et de l'enregistrement CNAME.
Supposons, pour les besoins de cet exemple, que vous exploitiez un gros site et que vous confiez l'hébergement à un CDN (Content Distribution Network) tel qu'Akamai. Ce que vous faites généralement, c'est de configurer l'enregistrement DNS de votre site en tant que CNAME vers un certain akamai.com adresse. Cela donne au CDN la possibilité de fournir une adresse IP qui est proche du navigateur (en termes géographiques ou de réseau). Si vous utilisiez un enregistrement A sur votre site, vous ne seriez pas en mesure d'offrir cette flexibilité.
La bizarrerie du DNS est que si vous avez un enregistrement CNAME pour un nom d'hôte, vous ne pouvez pas avoir un enregistrement CNAME pour un nom de domaine. tout autre pour ce même hôte. Cependant, votre domaine de premier niveau example.com doit généralement disposer d'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 site example.com aura généralement aussi un enregistrement A pour pointer vers un hôte qui redirigera vers l'adresse suivante www.example.com en utilisant une redirection HTTP.
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.
Comment se fait-il que personne ne mentionne le ALIAS (ou ANAME ) dans ce genre de sujet ? N'obtient-il pas les mêmes résultats que le CNAME sur nakeddomain (à l'exception du problème des cookies...) ?
@AugustinRiedinger : Les enregistrements ANAME ne sont pas un type de RR DNS standard. Ils sont la propriété de fournisseurs de services spécifiques.
Note : A compter de la ratification et de la mise en œuvre (par tous les navigateurs actuels, sauf le éventuellement MSIE 11 (voir commentaires) de RFC 6265 en 2011, ce qui suit n'est plus exact, car les cookies ne sont jamais définis par défaut sur les sous-domaines.
Historiquement une bonne raison technique pour faire www.example.com canonique était que les cookies d'un domaine principal (c'est-à-dire example.com ) ont été envoyés à tous les sous-domaines.
Ainsi, si votre site utilise des cookies, ils seront envoyés à tous ses sous-domaines.
Cela a souvent du sens, mais c'est tout à fait dommageable si vous ne voulez télécharger que des ressources statiques, car cela ne fait que gaspiller de la bande passante. Considérez toutes les feuilles de style et les images de votre site Web : en général, il n'y a 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, par exemple static.example.com pour économiser de 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, ce qui signifie que les cookies doivent seulement être envoyés à www.example.com et non à static.example.com .
Si, toutefois, example.com est votre site principal, alors les cookies seront envoyés à tous sous-domaines, y compris static.example.com .
Ce 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 coincé avec elle.
Une alternative est d'utiliser un tout autre URL pour les ressources statiques. Stack Overflow, par exemple, utilise sstatic.net YouTube utilise ytimg.com etc.
D'ailleurs, je n'aime vraiment pas www.x comme URL canonique. Personnellement, j'utiliserais probablement une URL différente pour les ressources statiques si je devais concevoir un grand site.
Aide avec le CDN et la configuration de media.example.com, et autres, pour utiliser les sous-domaines appropriés. Le truc des cookies provoque un verdissement extrême des branchies et des ballonnements quand il se manifeste.
Cette réponse est totalement fausse sur tous les points importants. Ni l'un ni l'autre Les cookies créés sur le serveur ou avec JavaScript sur le domaine principal (exemple.com) sont partagés avec les sous-domaines (www.example.com) par défaut, et vice-versa. Cependant, tant le domaine principal que les sous-domaines peut choisir pour créer des cookies avec domain=.example.com dans ce cas, ils seront partagés avec le domaine et les sous-domaines apex. Par conséquent, les cookies font absolument aucune différence à la question de savoir s'il faut utiliser www ou non.
www est un sous-domaine généralement utilisé pour le serveur web d'un domaine ainsi que d'autres à d'autres fins telles que mail etc. De nos jours, le paradigme du 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 courrier.
Utilisation de www ou non est une question de préférence personnelle. Des points de vue opposés peuvent être trouvés sur http://no-www.org/ y http://www.yes-www.org/ - cependant, je crois que www n'est pas nécessaire et ne fait qu'ajouter des éléments inutiles à l'URI.
La plupart des serveurs envoient le même site dans les deux sens, mais ne font pas de redirection. Pour des raisons de référencement, choisissez-en un, puis faites en sorte que l'autre redirige vers lui. Par exemple, un code PHP pour faire cela :
if (preg_match('/www/', $_SERVER['SERVER_NAME'])) {
header("Location: http://azabani.com{$_SERVER['REQUEST_URI']}");
exit;
}Cependant, certaines raisons favorisant l'utilisation d'un www Le fait de ne pas envoyer de cookies à des serveurs statiques (crédit Konrad Rudolph ).
On dirait que no-www.org est revenu à une page de parking à vendre où oui-www.org est toujours aussi forte. Je suppose que c'est réglé. Tout le monde utilise "www" à partir de maintenant.
Si vous avez l'intention d'avoir des sous-domaines à d'autres fins (blog par exemple), vous pouvez vouloir différencier les sites et avoir un www préfixe pour le site ordinaire. En dehors de cela, la seule chose importante est de choisir l'un des deux et de s'y tenir (pour des raisons de référencement).
C'est assez historique. Il fut un temps où nous avions www.example.com, ftp.exemple.com, images.exemple.com, uk.exemple.com, etc., ce qui semblait logique et constituait une méthode simple pour répartir la charge entre les serveurs.
Aujourd'hui, je choisirais simplement exemple.com pour le site principal et je redirigerais la version www vers celui-ci.
El Les outils pour webmasters de Google vous permettent de spécifier votre domaine préféré. alors assurez-vous de les utiliser aussi.
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-or-not-to-www
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
2 votes
En rapport : stackoverflow.com/questions/1109356/
0 votes
À l'inverse, à quoi bon ne pas le faire. Pour les cookies et les sous-domaines d'une présence réussie sur le Web, il est utile de séparer plusieurs processus.
0 votes
Cette réponse Bien qu'elle ne soit pas directement liée, cette question semble pertinente.