Pregunta ¿Cuál es el punto de tener "www" en una URL?


Aparte de por razones históricas, ¿hay razones para tener "www" en una URL?

¿Debo crear una redirección permanente desde www.xyz.com a xyz.com, o de xyz.com a www.xyz.com? ¿Cuál sugerirías y por qué?


223
2018-05-27 08:02


origen


Relacionado: stackoverflow.com/questions/1109356/… - Quintin Par
Por el contrario, ¿cuál es el punto en no. Para propósitos de cookies y subdominios en una presencia web exitosa, es útil separar varios procesos. - Fiasco Labs
Esta respuesta, aunque no directamente relacionado, parece relevante. - Skippy le Grand Gourou


Respuestas:


Una de las razones por las que necesitas www o algún otro subdominio tiene que ver con una peculiaridad de DNS y el registro CNAME.

Supongamos que, a los efectos de este ejemplo, está ejecutando un sitio grande y contrata el alojamiento a una red de distribución de contenido (CDN), como Akamai. Lo que normalmente hace es configurar el registro DNS para su sitio como un CNAME para algunos akamai.com dirección. Esto le da a la CDN la oportunidad de proporcionar una dirección IP cercana al navegador (en términos geográficos o de red). Si utiliza un registro A en su sitio, no podrá ofrecer esta flexibilidad.

La peculiaridad del DNS es que si tiene un registro CNAME para un nombre de host, no puede tener cualquier otro registros para ese mismo host. Sin embargo, su dominio de nivel superior example.com Por lo general, debe tener un registro de NS y SOA. Por lo tanto, no puede agregar un registro CNAME para example.com.

El uso de www.example.com te da la oportunidad de usar un CNAME para www que apunta a su CDN, mientras deja los registros requeridos de NS y SOA en example.com. los example.com el registro generalmente también tendrá un registro A para apuntar a un host que redireccionará a www.example.com utilizando una redirección HTTP.


193
2018-05-27 08:10



Puede proporcionar un registro CNAME "predeterminado" que apunte a la CDN, no tiene que usar "www". Esto permite que su servidor DNS tenga SOA, NS, CNAME, etc. RRs para el mismo nombre de dominio. - Chris S
¿Cómo es que nadie menciona la ALIAS (o ANAME registros) en este tipo de tema? ¿No logra los mismos resultados que el CNAME en nakeddomain (excepto por el problema de las cookies ...)? - Augustin Riedinger
@AugustinRiedinger: los registros ANAME no son un tipo estándar de RR de DNS. Son propiedad de proveedores de servicios específicos. - Greg Hewgill
¿Pero esto genera algún problema de compatibilidad o algo así? ¿Hay alguna razón por la que no debamos usarlos (además de no ser estándar sino de propietario)? - Augustin Riedinger
@AugustinRiedinger no es compatible con la mayoría de los DNS servidores. Pero si tu proveedor tiene un servidor DNS que soporta estas características, por lo que no debería dar problemas con los clientes. - Koen.


Nota: A partir de la ratificación e implementación (por todos los navegadores actuales, excepto posiblemente MSIE 11ver comentarios) de RFC 6265 en 2011, lo siguiente ya no es exacto, ya que las cookies no se establecen de forma predeterminada en los subdominios.

Históricamente, una buena razón técnica para hacer www.example.com canónica fue que las cookies de un dominio principal (es decir, example.com) fueron enviados a todos los subdominios.

Por lo tanto, si su sitio utiliza cookies, se enviarán a todos sus subdominios.

Ahora, esto a menudo tiene sentido, pero es positivamente perjudicial si solo desea descargar recursos estáticos ya que solo desperdicia ancho de banda. Considere todas las hojas de estilo e imágenes en su sitio web: por lo general, no hay razón para enviar cookies al servidor cuando solicita un recurso de imagen.

Por lo tanto, una buena solución es usar un subdominio para recursos estáticos, como static.example.com, para ahorrar ancho de banda al no enviar cookies. Todas las imágenes y otras descargas estáticas se pueden descargar desde allí. Si ahora usas www.example.com para el contenido dinámico, esto significa que las cookies solo deben enviarse a www.example.com, No a static.example.com.

Si acaso, example.com es su sitio principal, entonces las cookies serán enviadas a todos subdominios, incluyendo static.example.com.

Ahora esto no es relevante para la mayoría de los sitios, pero cambiar su URL canónica más adelante no es una buena idea, así que una vez que se conformó con example.com en lugar de www.*, básicamente estás atascado con eso.

Una alternativa es utilizar un todo diferente URL para recursos estáticos. Desbordamiento de pila para usos de ejemplo sstatic.net, YouTube usa ytimg.com etc.…


99
2018-05-27 08:15



Por cierto, realmente no me gusta www.x como la URL canónica, personalmente, probablemente usaría una URL diferente para los recursos estáticos si tuviera que diseñar un sitio grande. - Konrad Rudolph
@RobinWinslow Pero poniendo a Cookes en domain=example.com establecerá la cookie en el dominio apex y en subdominios, y una forma de evitar esto es no usar el dominio apex para HTTP. Aunque, de acuerdo, otra forma sería simplemente no especificar domain al configurar la cookie. Me pregunto si esto ha cambiado desde que escribí mi respuesta (que es anterior a la RFC 6265!) pero no puedo molestarme en buscarlo ahora. - Konrad Rudolph
Parece que el comportamiento que describo ha sido el caso desde al menos 2011 cuando se escribió RFC 6265 (más como un resumen del comportamiento actual del navegador que como una declaración de cómo deberían funcionar). Por ahora, podemos asumir que todos los navegadores lo seguirán. Ver stackoverflow.com/questions/1062963/… y bayou.io/draft/cookie.domain.html. Teniendo en cuenta esto, creo que su respuesta ha sido engañosa durante al menos 7 años, aunque podría tener Ha sido preciso en algunos casos en el momento de la escritura. ¿Podría por favor actualizarlo para aclarar este hecho? - Robin Winslow
@RobinWinslow Sí, lo haré. - Konrad Rudolph
@KonradRudolph en realidad, de acuerdo con mxsasha.eu/blog/2014/03/04/definitive-guide-to-cookie-domains, el comportamiento indeseable que describió puede haber existido en IE11 en el momento en que se escribió la publicación, y aún puede ser, lo que sigue siendo la versión más reciente de Internet Explorer. Eso sería bastante significativo y vale la pena mencionarlo, pero sería bueno revisarlo primero. No puedo verificar fácilmente, ya que estoy en Ubuntu, pero si pudieras, sería maravilloso. - Robin Winslow


www es un subdominio que se usa generalmente para el servidor web en un dominio junto con otros para otros propósitos, como mail Hoy en día, el paradigma del subdominio es innecesario; Si se conecta a un sitio web en un navegador, obtendrá el sitio web, o el envío de correo al servidor utilizará su servicio de correo.

Utilizando www o no es una cuestión de preferencia personal. Los puntos de vista opuestos se pueden encontrar en http://no-www.org/ y http://www.yes-www.org/ - Sin embargo, creo que www Es innecesario y solo añade más cruft a la URI.

La mayoría de los servidores envían el mismo sitio de cualquier manera, pero no redirigen. Para propósitos de SEO, elija uno, luego haga que el otro redirija a él. Por ejemplo, algún código PHP para hacer esto:

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

Sin embargo, algunas razones que promueven el uso de un www El subdominio hecho por otros respondedores también es excelente, como no enviar cookies a servidores estáticos (crédito Konrad Rudolph).


10
2018-05-27 08:11



Parece no-www.org ha vuelto a una página aparcada para la venta donde yes-www.org todavía va fuerte Supongo que eso lo resuelve. Todo el mundo usa "www" de ahora en adelante. - hacksalot


Si va a tener subdominios para otros fines (blog, por ejemplo), es posible que desee diferenciar los sitios y tener una www prefijo para el sitio regular. Aparte de eso, lo único importante es elegir uno de los dos y mantenerlo (por razones de SEO).


7
2018-05-27 08:06



No puedo encontrar referencias en este momento, pero también podría tener efectos en la misma política de origen. - Kobi
Sí lo hará, por desgracia. No puedes AJAX para www.example.comdesde example.com o viceversa sin algo como JSONP. - Delan Azabani


Es bastante histórico. Érase una vez que solíamos tener www.example.com, ftp.example.com, images.example.com, uk.example.com, etc. que parecía algo lógico y ofrecía un método sencillo para repartir la carga entre servidores

En estos días solo iría a example.com para el sitio principal y redirigiría la versión www a eso.

los Las herramientas para webmasters de Google te permiten especificar tu dominio preferido, así que asegúrate de usar esos también.

Ver también:
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





Yo haría lo primero. los www la convención proviene de los primeros días de HTTP, donde www.cmu.edu y cmu.edu eran muy diferentes máquinas.


6
2018-05-27 08:08



en los "primeros días" rara vez verías un registro A para un dominio, tal vez tendría un registro MX, pero rara vez tenías un host allí. - Joe H.


Aquí hay otra perspectiva menor.

Al no tener www, hay un pequeño inconveniente cuando se trata de medios basados ​​en texto, ya sean impresos o en línea, y es que se le reconozca como una dirección web. En la impresión, generalmente es bastante obvio que example.com es una dirección web, y puede agregar toques de estilo para resaltar eso. Pero el texto sin formato en línea? No tan fácil. Lo más probable es que si envía un mensaje de texto simple, ya sea correo electrónico, tweet, publicación de Facebook, SMS o lo que sea, reconocerá una URL que comienza con http: // o www. pero no reconocerá uno sin ninguno de los dos. Por lo tanto, para que la URL se convierta en un enlace en el que se pueda hacer clic, debe ingresar www. o http: // en el frente, y de los dos, www. es más corto, menos torpe de mirar y más fácil de leer.


1
2017-11-24 18:22



http://example.com/ está completamente calificado mientras que www.example.com no es. Prefiero el enfoque totalmente calificado porque es siempre reconocible como una URL independientemente de si es https://example.uk/ o https://blog.example.eu/ o lo que sea. Es consistente con la especificación del protocolo de un sitio seguro como HTTPS; www.example.com es solo un dominio y no dice nada sobre qué protocolo se debe usar para acceder a él. - James Haigh