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

238

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

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

http url redirect

— Quintin Par
fuente

2

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 está directamente relacionada, parece relevante.

— Skippy le Grand Gourou

202

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

Para los fines de este ejemplo, suponga que está ejecutando un sitio grande y contrata alojamiento para una red CDN (Content Distribution Network) como Akamai. Lo que normalmente hace es configurar el registro DNS para su sitio como CNAME en alguna akamai.comdirección. Esto le da a la CDN la oportunidad de proporcionar una dirección IP que esté cerca del navegador (en términos geográficos o de red). Si utilizó un registro A en su sitio, entonces no podría ofrecer esta flexibilidad.

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

El uso de www.example.comle da la oportunidad de usar un CNAME para wwwesos puntos en su CDN, mientras deja los registros NS y SOA necesarios example.com. El example.comregistro generalmente también tendrá un registro A para apuntar a un host que redirigirá al www.example.comuso de un redireccionamiento HTTP.

— Greg Hewgill
fuente

3

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. RR para el mismo nombre de dominio.

— Chris S

1

¿Cómo es que nadie menciona el ALIAS(o los ANAMEregistros) en este tipo de tema? ¿No logra los mismos resultados que el CNAME en el dominio desnudo (excepto por el problema de las cookies ...)?

— Augustin Riedinger

3

@AugustinRiedinger: los registros ANAME no son un tipo de RR DNS estándar. 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 patentado)?

— Augustin Riedinger

2

@AugustinRiedinger no es compatible con la mayoría de los servidores DNS . Pero si su proveedor tiene un servidor DNS que admita estas características, eso no debería generar ningún problema con los clientes.

— Koen

104

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

Históricamente , una buena razón técnica para hacer www.example.comcanónico es que las cookies de un dominio principal (es decir example.com) se enviaron a todos los subdominios.

Entonces, 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 utilizar un subdominio para recursos estáticos, como por ejemplo 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 usa www.example.comel contenido dinámico, esto significa que las cookies solo deben enviarse a www.example.com, no a static.example.com.

Sin embargo, si example.comes su sitio principal, se enviarán cookies a todos los subdominios, incluidos static.example.com.

Ahora, esto no es relevante para la mayoría de los sitios, pero cambiar tu URL canónica más adelante no es una buena idea, así que una vez que te conformaste con él en example.comlugar de hacerlo www.*, básicamente estás atascado con él.

Una alternativa es utilizar una URL completamente diferente para los recursos estáticos. Desbordamiento de pila, por ejemplo sstatic.net, usos , usos de YouTube, ytimg.cometc.

— Konrad Rudolph
fuente

11

Por cierto, realmente no me gusta www.xcomo la URL canónica, así que personalmente probablemente usaría una URL diferente para recursos estáticos si tuviera que diseñar un sitio grande.

— Konrad Rudolph

1

@RobinWinslow Pero al activar cookes domain=example.comse establecerá la cookie en el dominio de apex y en los subdominios , y una forma de evitar esto es no usar el dominio de apex para HTTP. Sin embargo, de acuerdo, otra forma sería simplemente no especificar domainal configurar la cookie. Me pregunto si esto ha cambiado desde que escribí mi respuesta (¡que es anterior al RFC 6265 relevante !), Pero no me molesto en buscarlo ahora.

— Konrad Rudolph

2

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 suponer que todos los navegadores lo seguirán. Consulte stackoverflow.com/questions/1062963/… y bayou.io/draft/cookie.domain.html . Dado esto, creo que su respuesta ha sido engañosa durante al menos 7 años, aunque podría haber sido precisa en algunos casos al momento de escribir. ¿Podría actualizarlo para aclarar este hecho?

— Robin Winslow

2

@RobinWinslow Sí, lo haré.

— Konrad Rudolph

2

Más evidencia de que IE11 hace lo malo: developer.microsoft.com/en-us/microsoft-edge/platform/issues/…

— Robin Winslow

12

wwwes un subdominio que generalmente se usa para el servidor web en un dominio junto con otros para otros fines, como mailetc. 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 enviando correo al servidor usará su servicio de correo.

Usar wwwo 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 eso wwwes innecesario y solo agrega más información al URI.

La mayoría de los servidores envían el mismo sitio de cualquier manera, pero no redirigen. Para fines de SEO, elija uno, luego obtenga el otro para redirigirlo. Por ejemplo, algunos códigos 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 wwwsubdominio hecho por otros respondedores también son excelentes, como no enviar cookies a servidores estáticos (crédito Konrad Rudolph ).

— Delan Azabani
fuente

2

Parece que no-www.org ha vuelto a una página estacionada en venta donde yes-www.org todavía se está fortaleciendo. Supongo que eso lo resuelve. Todos usan "www" de ahora en adelante.

— nunya

9

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

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

Las herramientas para webmasters de Google le permiten especificar su dominio preferido , así que asegúrese de usarlas 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-o-no-a-www

— Comunidad
fuente

8

Si va a tener subdominios para otros fines (blog, por ejemplo), es posible que desee diferenciar los sitios y tener un wwwprefijo para el sitio normal. Aparte de eso, lo único importante es elegir uno de los dos y atenerse a él (por razones de SEO).

— Oded
fuente

1

No puedo encontrar referencias en este momento, pero también podría tener efectos en la misma política de origen.

— Kobi

Sí, por desgracia. No puede AJAX www.example.comdesde example.como viceversa sin algo como JSONP.

— Delan Azabani

7

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

— msw
fuente

10

en los 'primeros días' rara vez se veía un registro A para un dominio; tal vez tendría un registro MX, pero rara vez se tenía un host allí.

— Joe H.

2

Aquí hay otra perspectiva menor.

Al no tener www, hay una desventaja menor cuando se trata de medios basados en texto, ya sea impresos o en línea, y eso es conseguir que se 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 texto simple en línea? No tan fácil. Lo más probable es que si envía un mensaje de texto sin formato, 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 esos. Entonces, para convertir la URL en un enlace en el que se pueda hacer clic, debe poner www. o http: // en el frente, y de los dos, www. es más corto, menos torpe de ver y más fácil de leer.

— Rayo
fuente

2

http://example.com/está totalmente calificado mientras www.example.comque no lo está. Prefiero el enfoque totalmente calificado porque siempre es reconocible como una URL, independientemente de si es https://example.uk/o no https://blog.example.eu/. Es consistente con especificar el protocolo de un sitio seguro como HTTPS; www.example.comes solo un dominio y no dice nada sobre qué protocolo se debe usar para acceder a él.

— James Haigh