Por qué su sitio web canonical name debe ser 'www' (o 'app' u otra cosa)
Un URL de un sitio web que comienza con 'www' evita que los datos de los visitantes (cookies) se envíen a destinos no deseados.
Lo sé, hay muchos artículos sobre este tema. Pero pensé que era útil escribir un post sobre esto porque no conocía todos los detalles.
Asumo que se puede acceder a su sitio web desde Internet usando una URL 'without-www' y una URL 'with-www'. Este artículo no trata sobre la selección de una URL de un sitio web con fines de marketing. Incluso si estás usando una URL " with-www " para tu sitio web, puedes comunicar la URL "without-www" a tu audiencia.
En cambio, este artículo trata sobre las implicaciones técnicas de usar un 'www' prefix o ningún prefix .
Definiciones
Nombre de dominio Un nombre de dominio es el nombre único que identifica a una entidad como un sitio web en Internet. Un nombre de dominio siempre tiene dos o más partes separadas por puntos.
Dirección web o URL La dirección web o URL es la ubicación de una entidad en Internet. Puede ser un archivo, una página web, un sitio web.
Ápicede dominio Un ápice de dominio es la raíz de un dominio. Por ejemplo, example.org es un ápice de dominio. Y www.example.org, mail.example.org son llamados subdominios de example.org. Un ápice de dominio también se llama base, desnudo o dominio desnudo.
Elnombre canónico A canonical name, también llamado registro CNAME , es un registro DNS que define un nombre de host de un ordenador o servidor. Se utiliza para añadir un prefix como 'www' a un dominio raíz.
Sistema de Nombres de Dominio (DNS) El Sistema de Nombres de Dominio, o DNS, es un sistema descentralizado para computadoras conectadas a Internet. A menudo se le llama la guía telefónica de Internet. Su función más importante es la traducción de una URL a una dirección IP. Esto es hecho por los servidores de nombre.
Servidor de nombres Los servidores de nombres forman parte del Sistema de Nombres de Dominio (DNS). Si alguien cambia los registros del DNS en un servidor de nombres, estos cambios se propagan a todos los servidores de nombres que forman parte del DNS. Realizan la traducción real de la URL a la dirección IP.
¿Qué sucede cuando se escribe una URL en el navegador
Antes de entrar en detalles, resumamos cómo se muestra una página web en su pantalla. La URL que escribes en tu navegador, se envía a un servidor de nombres. El servidor de nombres traduce esto en una dirección IP y la devuelve a su navegador. Su navegador se conecta a esta dirección IP y obtiene el recurso, a menudo una página web.
Los datos que se muestran en el navegador suelen ser seleccionados por tres o cuatro sistemas:
- El sistema de nombres de dominio (DNS)
- (opcional) Un servidor proxy
- El servidor web, por ejemplo Nginx, Apache
- La aplicación web
La traducción de la URL a la dirección IP se realiza mediante uno o más registros DNS.
El servidor opcional proxy es un servidor intermediario que separa los sitios web de Internet. Para mantenerlo simple asumiré que no hay un servidor proxy en nuestra conexión.
El servidor web puede ser configurado de varias maneras. Puede redirigir, o reescribir, un URL 'without-www' a un URL 'with-www', o viceversa. También puede redirigir, o reescribir, HTTP a HTTPS.
La aplicación web recibe la URL del servidor web, la procesa y devuelve al servidor web los datos del recurso solicitado, un archivo o una página web. Finalmente, el servidor web devuelve estos datos al navegador.
Redirección: a 'without-www', a 'with-www', o no hay redirección
Por supuesto, su sitio web debe ser accesible desde una URL y la mayoría de los sitios web soportan una URL 'without-www' y 'with-www'. ¿Pero qué hay de la redirección?
No hay redireccionamiento
Me gusta el caso de no redireccionamiento porque es WYSIWYG (What You See Is What You Get), lo que significa que cuando se carga la página, la URL del navegador comienza con lo que has escrito en el navegador. Es confuso si escribes un URL 'with-www' y cambia a 'without-www', o al revés. Nunca me gustó que una computadora cambiara automáticamente las cosas para mí...
Revisando algunos sitios web en internet encontré que sólo unos pocos sitios web mantenían la URL tal como la escribió el visitante en el navegador, 'with-www' se quedaba 'with-www', y 'Q 4_789_TNEMECALPER_4Q' se quedaba 'without-www'. No hay muchos, así que probablemente no es una buena idea, ¿por qué eligieron hacer esto de todos modos, debe haber una razón?
Desde una perspectiva de SEO (Search Engine Optimization) esta ciertamente no es la mejor solución. Su sitio web puede tener entradas en las bases de datos de los motores de búsqueda 'with-www' URLs y 'without-www' URLs.
Redirección a la URL ' without-www
En este caso, cuando escribes una URL "with-www ", la dirección web de tu navegador cambia a la URL "without-www". Algunos ejemplos de sitios web de "Q 4_789_TNEMECALPER_4Q":
- twitter.com
- github.com
- stackoverflow.com
Esto significa que algunos de los sitios más importantes se redirigen a una URL "without-www". Es más corta, se ve más moderna, más bonita, en el navegador. ¿Es esa la razón por la que han elegido hacerlo de esta manera?
Redirección a una URL " with-www
En este caso, cuando escribes una URL "without-www ", la dirección web de tu navegador cambia a la URL "with-www". Algunos ejemplos de sitios web de "Q 4_389_TNEMECALPER_4Q":
- www.nytimes.com
- www.python.org
- www.apple.com
Parece que la mayoría de los sitios más importantes se redirigen a una URL 'with-www'. Esto parece anticuado o ¿hay una muy buena razón para esto?
Esconder 'www' en el navegador
Recientemente, navegadores web populares como Chrome y Safari comenzaron a ocultar la parte 'www' de una URL. La explicación de Google es que "quieren hacer las URLs más fáciles de leer y entender, y eliminar las distracciones", ver enlaces abajo.
Pero espera, esto probablemente significa que los sitios principales no tienen intención de usar URLs "without-www" sino que se quedan con URLs "with-www". ¿Qué está pasando aquí?
Por qué la mayoría de los sitios web más importantes redirigen las URLs de ' without-www ' a las URLs de 'with-www'.
Por fin estamos llegando a alguna parte. La mayoría de los sitios web redirigen los URLs de "without-www " a los de "with-www" por una o más de las siguientes razones:
Cookies
Para los propietarios de sitios web la razón más importante es lo que sucede con cookies. Para una URL " with-www" se envía un cookie al subdominio 'www' solamente.
Para una URL " without-www" el cookie es compartido por todos los subdominios. Los datos de cookie se envían con cada solicitud y respuesta, tanto si un subdominio utiliza estos datos como si no.
¿Por qué es esto importante?
Si tienes un subdominio, estático.example.com, almacenando tus images, javascripts y stylesheets, el cookie siempre será enviado a ese dominio. Peor aún, si usas un CDN externo (Content Delivery Network) en una URL como static.yourdomain.com entonces puede ser imposible evitar que el cookie vaya allí.
También un cookie contiene datos de los visitantes de su sitio web, lo que significa que crea un problema de privacidad y una posible fuga de seguridad si no toma medidas para evitarlo.
Flexibilidad, disponibilidad
Hay otra razón y tiene que ver con la flexibilidad, la disponibilidad. Pero esto sólo se aplica si usted está usando el servicio DNS del proveedor donde usted hospeda su sitio web, vea los enlaces de abajo.
Configuración de los registros DNS y redireccionamiento del servidor web
Ahora sabemos que siempre deberíamos tener una URL "with-www" para nuestra página web, ¿cómo lo hacemos?
Para los registros DNS hay dos maneras:
Registro A y registro CNAME:
Type | Host | Data
-------+------------------+-------------
A | example.org | 192.0.1.2
CNAME | www.example.org | example.org
O, dos registros A:
Type | Host | Data
-------+------------------+-------------
A | example.org | 192.0.1.2
A | www.example.org | 192.0.1.2
También debemos decirle al servidor web que redirija los URLs de 'without-www' a los URLs de 'with-www'. Un ejemplo de redirección con Nginx es:
if ($http_host = "example.org") {
rewrite ^ $scheme://www.example.org$request_uri? permanent;
}
Resumen
El título de este artículo dice que su sitio web canonical name debe ser www (o aplicación o algo así). Esto se debe a que típicamente usas un registro CNAME , o registro de Nombre Canónico, para establecer el subdominio 'www' .
Usar una URL 'with-www' para su sitio web hace posible servir recursos estáticos de un dominio cookieless reduciendo las transferencias de datos. Usar una URL 'with-www ' para su sitio web también evita posibles problemas de privacidad y seguridad de los datos de su visitante (cookie).
Enlaces / créditos
Choosing between www and non-www URLs
https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Choosing_between_www_and_non-www_URLs
Domain IP address for www and non-www for Canonical URL
https://stackoverflow.com/questions/19566856/domain-ip-address-for-www-and-non-www-for-canonical-url
Issue 883038: Feedback: Eliding www/m subdomains
https://bugs.chromium.org/p/chromium/issues/detail?id=883038#c114
To WWW or not WWW
https://www.netlify.com/blog/2017/02/28/to-www-or-not-www/
Why a domain’s root can’t be a CNAME — and other tidbits about the DNS
https://www.freecodecamp.org/news/why-cant-a-domain-s-root-be-a-cname-8cbab38e5f5c/
Deje un comentario
Comente de forma anónima o inicie sesión para comentar.
Comentarios (2)
Deje una respuesta.
Responda de forma anónima o inicie sesión para responder.
Another brilliant and helpful post. Thanks! Why don't you include an About on your blog? Can't seem to locate it.
Recientes
- Cómo ocultar las claves primarias de la base de datos UUID de su aplicación web
- Don't Repeat Yourself (DRY) con Jinja2
- SQLAlchemy, PostgreSQL, número máximo de filas por user
- Mostrar los valores en filtros dinámicos SQLAlchemy
- Transferencia de datos segura con cifrado de Public Key y pyNaCl
- rqlite: una alternativa de alta disponibilidad y dist distribuida SQLite
Más vistos
- Usando Python's pyOpenSSL para verificar los certificados SSL descargados de un host
- Usando UUIDs en lugar de Integer Autoincrement Primary Keys con SQLAlchemy y MariaDb
- Conectarse a un servicio en un host Docker desde un contenedor Docker
- Usando PyInstaller y Cython para crear un ejecutable de Python
- SQLAlchemy: Uso de Cascade Deletes para eliminar objetos relacionados
- Flask RESTful API validación de parámetros de solicitud con esquemas Marshmallow