Personne n'a mentionné le fait que Firefox (et je pense que IE, peut-être d'autres) ajoute automatiquement le www. et .com si vous tapez, par exemple, "stackoverflow" dans la barre d'adresse et appuyez sur Ctrl-Entrée. Une petite raison de plus pour au moins gérer le www, même si vous le redirigez vers le domaine nu.
bstpierre le
@bstpierre - je l'utilise constamment, drôle comme je ne le vois pas beaucoup mentionné
Brady Moritz
2
@bstpierre, sur Firefox lorsque j'appuie sur <enter> dans la barre de navigation, il n'ajoute pas "www." il semble donc que Firefox préfère supposer que vous vouliez vraiment dire ce que vous avez tapé plutôt que de déduire des anachronismes confus. Par conséquent, je ne vois pas en quoi votre commentaire est pertinent.
biais
1
@bias: Avez-vous essayé la fonctionnalité? D'après votre commentaire, cela ne semble pas être le cas. Cela permet d'économiser quelques frappes - vous n'avez pas besoin de taper le ".com". Comme l'a mentionné boomhauer, c'est quelque chose que les gens utilisent fréquemment, et c'est intégré aux navigateurs, c'est donc une raison pour gérer "www.", Même si vous le redirigez simplement. Ie dans votre navigateur, tapez Ctrl-T (pour un nouvel onglet), "stackoverflow", Ctrl-Entrée, vous allez naviguer vers "www.stackoverflow.com", et vous serez alors redirigé vers "stackoverflow.com". (De même, Ctrl-Shift-Enter va à .org et Shift-Enter va à .net, au moins dans FF3.)
bstpierre
1
@bstpierre J'utilise vimperator, donc je n'interagis pas avec la barre de navigation mais quand je le fais, j'appuie simplement sur <Entrée>. De plus, je pense que la plupart des utilisateurs appuient sur <Entrée> par opposition à des séquences d'accords plus complexes lors de l'utilisation de Firefox. Je crains vraiment que le changement de DNS basé sur des idiosyncrasies arbitraires soit une idée horrible et nuise à l'utilisateur.
En raison de la règle du point avec les cookies, si vous ne disposez pas du 'www.' alors vous ne pouvez pas définir des cookies à deux points ou des cookies inter-sous-domaines à la * .example.com. Il y a deux impacts pertinents.
Tout d'abord, cela signifie que tout utilisateur auquel vous attribuez des cookies renverra ces cookies avec des demandes correspondant au domaine. Ainsi, même si vous avez un sous-domaine, images.example.com, le cookie example.com sera toujours envoyé avec les demandes à ce domaine. Cela crée une surcharge qui n'existerait pas si vous aviez fait de www.example.com le nom faisant autorité. Bien sûr, vous pouvez utiliser un CDN, mais cela dépend de vos ressources.
De plus, vous n'avez pas la possibilité de définir un cookie inter-sous-domaine. Cela semble évident, mais cela signifie que permettre aux utilisateurs authentifiés de se déplacer entre vos sous-domaines est plus un défi technique.
Alors posez-vous quelques questions. Dois-je définir des cookies? Est-ce que je me soucie des dépenses de bande passante potentiellement inutiles? Les utilisateurs authentifiés traverseront-ils des sous-domaines? Si vous êtes vraiment préoccupé par l'inconvénient de l'utilisateur, vous pouvez toujours configurer votre serveur pour qu'il s'occupe automatiquement de la chose www / no www.
Juste après avoir posé cette question, je suis tombé sur la page no-www qui dit:
... En résumé, l'utilisation du sous-domaine www est redondante et prend du temps à communiquer. L'Internet, les médias et la société sont tous mieux sans cela.
Prenez-le d'un domaine, utilisez à la fois le www.domainname.com et le domainname.com normal sinon vous jetez simplement votre trafic vers le moteur de recherche des navigateurs (erreur DNS)
En fait, il est étonnant de voir combien de domaines, en particulier parmi les 100 meilleurs, résolvent correctement pour www.domainname.com mais pas domainname.com
Il y a BEAUCOUP de raisons d'utiliser le sous-domaine www!
Lors de l'écriture d'une URL, il est plus facile d'écrire et de taper "www.stackoverflow.com", plutôt que " http://stackoverflow.com ". La plupart des éditeurs de texte, des clients de messagerie, des traitements de texte et des contrôles WYSIWYG reconnaissent automatiquement les deux éléments ci-dessus et créent des hyperliens. Taper simplement "stackoverflow.com" ne donnera pas de lien hypertexte, après tout ce n'est qu'un nom de domaine. Qui a dit qu'il y avait un service Web là-bas? Qui a dit que la référence à ce domaine était une référence à son service Web?
Que préférez-vous écrire / taper / dire .. "www." (4 caractères) ou "http: //" (7 caractères) ??
"www." est une manière abrégée établie de communiquer sans ambiguïté le fait que le sujet est une adresse Web et non une URL pour un autre service réseau.
Lorsque vous communiquez verbalement une adresse Web, il devrait être clair d'après le contexte qu'il s'agit d'une adresse Web, donc dire "www" est redondant. Les serveurs doivent être configurés pour renvoyer les réponses HTTP 301 (déplacé définitivement) transmettant toutes les demandes pour @ .stackoverflow.com (la racine du domaine) vers le sous-domaine www.
D'après mon expérience, les gens qui pensent que WWW devrait être omis ont tendance à être des gens qui ne comprennent pas la différence entre le Web et Internet et utilisent les termes de manière interchangeable, comme s'ils étaient synonymes. Le Web n'est que l'un des nombreux services réseau.
Si vous voulez vous débarrasser de www, pourquoi ne pas changer votre serveur HTTP pour utiliser également un port différent, le port TCP 80 est tellement hier .. Changeons cela en port 1234, YAY maintenant les gens doivent dire et taper " http: //stackoverflow.com:1234 "(huitch tee tee pee deux points slash slash pile débordement point com deux-points un deux trois quatre) mais au moins nous n'avons pas à dire" www "hein?
Vous pouvez toujours utiliser www.example.com(pour "www." Étant plus court que "http: //"), mais ensuite rediriger vers "example.com". Vous devriez écouter les deux, mais ce que vous utilisez comme canonique n'a pas vraiment d'importance (à part les problèmes de cookies / sous-domaines mentionnés par jdangel)
blueyed
39
Ces arguments sont ridicules. Dire www.ne garantit pas que quelqu'un y accédera via HTTP sur le port 80, vous supposez simplement qu'il le fera. De même, si vous dites à quelqu'un "stackoverflow.com", il y accédera de la même manière. HTTP est un protocole standard du W3C, les navigateurs ajouteront le http://parce qu'ils ont besoin d' un protocole et supposent simplement HTTP s'il manque. http://www.n'est pas plus court que http://. Les cookies sont la seule raison valable à utiliser www., et même dans ce cas, ce n'est que si vous êtes trop bon marché pour obtenir un CDN ou un deuxième domaine.
Tim
5
Quoi? C'est un mauvais raisonnement. "www." est une perte de temps pour tout le monde. Si votre programme de messagerie ne change pas les domaines normaux en hyperliens (1) créez les hyperliens manuellement ou (2) obtenez un nouveau client de messagerie.
AriX
13
En fait, en disant "www." peut ne comporter que 4 caractères, mais il est de 10 syllabes - plus long que les 7 syllabes de "http: //". Plus d'ironie syllabique: dire le www "raccourci" est 3 fois plus long que simplement dire "World Wide Web"
BritishDeveloper
2
Utilisation de "www." au début d'un lien ne le rend pas absolu, il sera relatif (voir jsfiddle.net/FQTSE ). Et vous dites "www." est plus court que "http: //", et c'est vrai, mais dans la plupart des cas, vous pouvez simplement utiliser "//", qui est encore plus court et rend l'URL absolue.
Oriol
10
Il n'y a pas d'énorme avantage à l'inclure ou non et aucune stratégie objectivement la meilleure. «No-www.org» est une charge idiote de vieux dogmes essayant de se présenter comme un fait définitif.
Si le scénario «grande organisation qui a de nombreux services différents et ne veut pas avoir à dédier le nom de domaine nu à être un serveur Web» ne s'applique pas à vous (et en réalité c'est rarement le cas), l'adresse que vous choisissez est une question largement culturelle. Les gens dont vous avez l'habitude de voir un simple domaine «example.org» écrit sur du matériel publicitaire, le reconnaîtraient-ils immédiatement comme une adresse Web sans le «www» ou «http: //» supplémentaire? Au Japon, par exemple, vous obtiendrez des looks amusants en choisissant la version non www.
Quoi que vous choisissiez, soyez cohérent. Rendez les versions www et non-www accessibles, mais rendez l' une d'elles définitive, créez toujours un lien vers cette version et effectuez la redirection vers l'autre (en permanence, code d'état 301). Le fait que les deux noms d'hôte répondent directement est mauvais pour le référencement, et servir tout ancien nom d'hôte qui se résout sur votre serveur vous laisse ouvert aux attaques de reliure DNS.
Les gens utilisent le DNS pour beaucoup de choses, pas seulement pour le Web. Ils peuvent avoir besoin du nom DNS principal pour un autre service qui est plus important pour eux.
2) Serveurs DNS mal configurés
Si quelqu'un recherche www sur votre serveur DNS, votre serveur DNS devra le résoudre.
3) Serveurs Web mal configurés
Un serveur Web peut héberger de nombreux sites Web différents. Il distingue le site que vous souhaitez via l'en-tête Host. Vous devez spécifier les noms d'hôte que vous souhaitez utiliser pour votre site Web.
4) Optimisation du site Web
Il est préférable de ne pas gérer les deux, mais d'en transmettre un avec un code d'état http déplacé de manière permanente. De cette façon, les 2 adresses ne seront pas en concurrence pour les rangs des liens entrants.
5) Cookies
Pour éviter les problèmes avec les cookies non renvoyés par le navigateur. Cela peut également être résolu avec le code d'état http déplacé de manière permanente.
6) Mise en cache du navigateur côté client
Les navigateurs Web peuvent ne pas mettre en cache une image si vous faites une demande à www et à une autre sans. Cela peut également être résolu avec le code d'état http déplacé de manière permanente.
Comme le souligne jdangel, www est une bonne pratique dans certaines situations de cookies, mais je pense qu'il y a une autre raison d'utiliser www.
N'est-il pas de notre responsabilité de prendre soin et de protéger nos utilisateurs? Comme la plupart des gens attendent www, vous leur offrirez une expérience moins que parfaite en ne programmant pas pour cela.
Pour moi, il me semble un peu arrogant de ne pas configurer une entrée DNS simplement parce qu'en théorie, ce n'est pas nécessaire. Il n'y a pas de surcharge pour transporter l'entrée DNS et via des redirections, etc., ils peuvent être redirigés vers une adresse non www.
Sérieusement, ne perdez pas de trafic précieux en laissant votre visiteur potentiel avec une erreur inutile "site non trouvé".
De plus, dans un réseau Windows uniquement, vous pourrez peut-être configurer un serveur DNS Windows pour éviter le problème suivant, mais je ne pense pas que vous puissiez le faire dans un environnement mixte Mac et Windows. Si un mac effectue une requête DNS sur un DNS Windows mydomain.com renverra tous les serveurs de noms disponibles et non le serveur Web. Donc, si dans votre navigateur vous tapez mydomain.com, votre navigateur interrogera un serveur de noms et non un serveur Web, dans ce cas, vous avez besoin d'un sous-domaine (par exemple www.mondomaine.com) pour pointer vers le serveur Web spécifique.
Outre l'optimisation de la charge concernant les cookies, il existe également une raison liée au DNS pour l'utilisation du wwwsous - domaine. Vous ne pouvez pas utiliser CNAME pour le domaine nu. Sur yes-www.org yes-www.org il est dit:
Lors de l'utilisation d'un fournisseur tel que Heroku ou Akamai pour héberger votre site Web, le fournisseur souhaite être en mesure de mettre à jour les enregistrements DNS au cas où il aurait besoin de rediriger le trafic d'un serveur défaillant vers un serveur sain. Ceci est configuré à l'aide d'enregistrements DNS CNAME et le domaine nu ne peut pas avoir d'enregistrement CNAME. Ce n'est un problème que si votre site devient suffisamment grand pour nécessiter un hébergement hautement redondant avec un tel service.
Réponses:
Il y a une tonne de bonnes raisons de l'inclure, dont la meilleure est ici: Meilleures pratiques de performance Yahoo
En raison de la règle du point avec les cookies, si vous ne disposez pas du 'www.' alors vous ne pouvez pas définir des cookies à deux points ou des cookies inter-sous-domaines à la * .example.com. Il y a deux impacts pertinents.
Tout d'abord, cela signifie que tout utilisateur auquel vous attribuez des cookies renverra ces cookies avec des demandes correspondant au domaine. Ainsi, même si vous avez un sous-domaine, images.example.com, le cookie example.com sera toujours envoyé avec les demandes à ce domaine. Cela crée une surcharge qui n'existerait pas si vous aviez fait de www.example.com le nom faisant autorité. Bien sûr, vous pouvez utiliser un CDN, mais cela dépend de vos ressources.
De plus, vous n'avez pas la possibilité de définir un cookie inter-sous-domaine. Cela semble évident, mais cela signifie que permettre aux utilisateurs authentifiés de se déplacer entre vos sous-domaines est plus un défi technique.
Alors posez-vous quelques questions. Dois-je définir des cookies? Est-ce que je me soucie des dépenses de bande passante potentiellement inutiles? Les utilisateurs authentifiés traverseront-ils des sous-domaines? Si vous êtes vraiment préoccupé par l'inconvénient de l'utilisateur, vous pouvez toujours configurer votre serveur pour qu'il s'occupe automatiquement de la chose www / no www.
Voir dropwww et yes-www .
la source
Juste après avoir posé cette question, je suis tombé sur la page no-www qui dit:
la source
www.autant que possible.Prenez-le d'un domaine, utilisez à la fois le www.domainname.com et le domainname.com normal sinon vous jetez simplement votre trafic vers le moteur de recherche des navigateurs (erreur DNS)
En fait, il est étonnant de voir combien de domaines, en particulier parmi les 100 meilleurs, résolvent correctement pour www.domainname.com mais pas domainname.com
la source
Il y a BEAUCOUP de raisons d'utiliser le sous-domaine www!
Lors de l'écriture d'une URL, il est plus facile d'écrire et de taper "www.stackoverflow.com", plutôt que " http://stackoverflow.com ". La plupart des éditeurs de texte, des clients de messagerie, des traitements de texte et des contrôles WYSIWYG reconnaissent automatiquement les deux éléments ci-dessus et créent des hyperliens. Taper simplement "stackoverflow.com" ne donnera pas de lien hypertexte, après tout ce n'est qu'un nom de domaine. Qui a dit qu'il y avait un service Web là-bas? Qui a dit que la référence à ce domaine était une référence à son service Web?
Que préférez-vous écrire / taper / dire .. "www." (4 caractères) ou "http: //" (7 caractères) ??
"www." est une manière abrégée établie de communiquer sans ambiguïté le fait que le sujet est une adresse Web et non une URL pour un autre service réseau.
Lorsque vous communiquez verbalement une adresse Web, il devrait être clair d'après le contexte qu'il s'agit d'une adresse Web, donc dire "www" est redondant. Les serveurs doivent être configurés pour renvoyer les réponses HTTP 301 (déplacé définitivement) transmettant toutes les demandes pour @ .stackoverflow.com (la racine du domaine) vers le sous-domaine www.
D'après mon expérience, les gens qui pensent que WWW devrait être omis ont tendance à être des gens qui ne comprennent pas la différence entre le Web et Internet et utilisent les termes de manière interchangeable, comme s'ils étaient synonymes. Le Web n'est que l'un des nombreux services réseau.
Si vous voulez vous débarrasser de www, pourquoi ne pas changer votre serveur HTTP pour utiliser également un port différent, le port TCP 80 est tellement hier .. Changeons cela en port 1234, YAY maintenant les gens doivent dire et taper " http: //stackoverflow.com:1234 "(huitch tee tee pee deux points slash slash pile débordement point com deux-points un deux trois quatre) mais au moins nous n'avons pas à dire" www "hein?
la source
www.example.com(pour "www." Étant plus court que "http: //"), mais ensuite rediriger vers "example.com". Vous devriez écouter les deux, mais ce que vous utilisez comme canonique n'a pas vraiment d'importance (à part les problèmes de cookies / sous-domaines mentionnés par jdangel)www.ne garantit pas que quelqu'un y accédera via HTTP sur le port 80, vous supposez simplement qu'il le fera. De même, si vous dites à quelqu'un "stackoverflow.com", il y accédera de la même manière. HTTP est un protocole standard du W3C, les navigateurs ajouteront lehttp://parce qu'ils ont besoin d' un protocole et supposent simplement HTTP s'il manque.http://www.n'est pas plus court quehttp://. Les cookies sont la seule raison valable à utiliserwww., et même dans ce cas, ce n'est que si vous êtes trop bon marché pour obtenir un CDN ou un deuxième domaine.Il n'y a pas d'énorme avantage à l'inclure ou non et aucune stratégie objectivement la meilleure. «No-www.org» est une charge idiote de vieux dogmes essayant de se présenter comme un fait définitif.
Si le scénario «grande organisation qui a de nombreux services différents et ne veut pas avoir à dédier le nom de domaine nu à être un serveur Web» ne s'applique pas à vous (et en réalité c'est rarement le cas), l'adresse que vous choisissez est une question largement culturelle. Les gens dont vous avez l'habitude de voir un simple domaine «example.org» écrit sur du matériel publicitaire, le reconnaîtraient-ils immédiatement comme une adresse Web sans le «www» ou «http: //» supplémentaire? Au Japon, par exemple, vous obtiendrez des looks amusants en choisissant la version non www.
Quoi que vous choisissiez, soyez cohérent. Rendez les versions www et non-www accessibles, mais rendez l' une d'elles définitive, créez toujours un lien vers cette version et effectuez la redirection vers l'autre (en permanence, code d'état 301). Le fait que les deux noms d'hôte répondent directement est mauvais pour le référencement, et servir tout ancien nom d'hôte qui se résout sur votre serveur vous laisse ouvert aux attaques de reliure DNS.
la source
Il y a plusieurs raisons, en voici quelques-unes:
1) La personne l'a voulu ainsi exprès
Les gens utilisent le DNS pour beaucoup de choses, pas seulement pour le Web. Ils peuvent avoir besoin du nom DNS principal pour un autre service qui est plus important pour eux.
2) Serveurs DNS mal configurés
Si quelqu'un recherche www sur votre serveur DNS, votre serveur DNS devra le résoudre.
3) Serveurs Web mal configurés
Un serveur Web peut héberger de nombreux sites Web différents. Il distingue le site que vous souhaitez via l'en-tête Host. Vous devez spécifier les noms d'hôte que vous souhaitez utiliser pour votre site Web.
4) Optimisation du site Web
Il est préférable de ne pas gérer les deux, mais d'en transmettre un avec un code d'état http déplacé de manière permanente. De cette façon, les 2 adresses ne seront pas en concurrence pour les rangs des liens entrants.
5) Cookies
Pour éviter les problèmes avec les cookies non renvoyés par le navigateur. Cela peut également être résolu avec le code d'état http déplacé de manière permanente.
6) Mise en cache du navigateur côté client
Les navigateurs Web peuvent ne pas mettre en cache une image si vous faites une demande à www et à une autre sans. Cela peut également être résolu avec le code d'état http déplacé de manière permanente.
la source
Comme le souligne jdangel, www est une bonne pratique dans certaines situations de cookies, mais je pense qu'il y a une autre raison d'utiliser www.
N'est-il pas de notre responsabilité de prendre soin et de protéger nos utilisateurs? Comme la plupart des gens attendent www, vous leur offrirez une expérience moins que parfaite en ne programmant pas pour cela.
Pour moi, il me semble un peu arrogant de ne pas configurer une entrée DNS simplement parce qu'en théorie, ce n'est pas nécessaire. Il n'y a pas de surcharge pour transporter l'entrée DNS et via des redirections, etc., ils peuvent être redirigés vers une adresse non www.
Sérieusement, ne perdez pas de trafic précieux en laissant votre visiteur potentiel avec une erreur inutile "site non trouvé".
De plus, dans un réseau Windows uniquement, vous pourrez peut-être configurer un serveur DNS Windows pour éviter le problème suivant, mais je ne pense pas que vous puissiez le faire dans un environnement mixte Mac et Windows. Si un mac effectue une requête DNS sur un DNS Windows mydomain.com renverra tous les serveurs de noms disponibles et non le serveur Web. Donc, si dans votre navigateur vous tapez mydomain.com, votre navigateur interrogera un serveur de noms et non un serveur Web, dans ce cas, vous avez besoin d'un sous-domaine (par exemple www.mondomaine.com) pour pointer vers le serveur Web spécifique.
la source
Outre l'optimisation de la charge concernant les cookies, il existe également une raison liée au DNS pour l'utilisation du
wwwsous - domaine. Vous ne pouvez pas utiliser CNAME pour le domaine nu. Sur yes-www.org yes-www.org il est dit:la source