¿Cómo deben los sitios web manejar el nombre de host con punto final?

Leí esta pregunta ¿Cómo pueden las URL tener un punto? al final, por ejemplo, www.bla.de.? y tenga en cuenta que FQDN debe contener un seguimiento .de la etiqueta raíz del árbol DNS:

example.com. en lugar de example.com

Sin embargo, hay problemas como se señala en este artículo del blog :

Si no considera el hecho de que el usuario puede ingresar accidentalmente el nombre de dominio con un punto al final, o seguir un enlace recibido de un "entendido" y obtener su nombre de dominio con el punto al final, como Como resultado, puede tener consecuencias inesperadas:

1) Si el sitio web usa HTTPS, al navegar al nombre de dominio con el punto al final, el navegador mostrará la advertencia de conexión no confiable.

2) La autenticación puede romperse, ya que las cookies generalmente se establecen para el nombre de dominio sin un punto al final. El usuario en este caso se sorprenderá bastante de por qué no puede iniciar sesión. Cabe señalar que si configura una cookie para un nombre de dominio con un punto al final, esta cookie no se pasará al nombre de dominio sin el punto al final y viceversa.

3) JavaScript en la página puede estar roto.

4) Puede haber problemas con el almacenamiento en caché de las páginas del sitio web (por ejemplo, https://www.cloudflare.com/no borra el caché de las páginas si el nombre de dominio tiene un punto al final, considerándolo un nombre de dominio no válido).

5) Si en condiciones en la configuración del servidor web confía en el nombre de dominio particular ($ http_host en Nginx,% {HTTP_HOST} en Apache) sin el punto al final, puede enfrentar una variedad de situaciones inesperadas: redireccionamientos inesperados, básicos -problemas de autorización, etc.

6) Si el servidor web no está configurado para aceptar solicitudes en el nombre de dominio con el punto final, cualquier usuario que haya escrito accidentalmente un nombre de dominio con el punto final verá algo como Solicitud incorrecta: nombre de host no válido.

7) Es posible que los motores de búsqueda descubran que su recurso tiene un contenido duplicado, si alguien publica accidental o intencionalmente enlaces a sus páginas web con un punto al final del nombre de dominio.

También me doy cuenta de que http://webmasters.stackexchange.com./hace un 400 Bad Request. Pero dado que el nombre de dominio apropiado debe contener un .al final, ¿no deberíamos emitir un 400error o 301redirigir los nombres de host sin un punto final? ¿Cuál es la forma correcta de abordar este problema de manera coherente y consistente?

Para responder parcialmente a su pregunta, puede agregarla a las reglas de reenvío canónico htaccess. En un sentido básico de HTTP, busca un período antes del URI y lo convierte en cualquier mecanismo de reenvío anti-duplicado que use. Aquí hay un ejemplo que incluye una ruta de subutilización común de "dominio de complementos":

RewriteCond %{HTTP_HOST} ^domain\.hostdomain\.com(|\.)$ [OR]
RewriteCond %{HTTP_HOST} ^www\.domain\.hostdomain\.com(|\.)$ [OR]
RewriteCond %{HTTP_HOST} ^domain\.com(|\.)$ [OR]
RewriteCond %{HTTP_HOST} ^www.domain\.com\.$
RewriteRule ^(.*)$ "http\:\/\/www\.domain\.com\/$1" [R=301,L]

Lo que esto haría es reenviar todo lo siguiente a un dominio www www canónico:

• domain.hostdomain.com
• dominio.dominiohost.com.
• www.domain.hostdomain.com
• www.dominio.dominiohost.com.
• dominio.com
• dominio.com.
• www.dominio.com.

Todos adelante a:

• http://www.domain.com

Sin embargo , hay una advertencia al respecto : como se indica en la cita original del blog, SSL no se reenviará correctamente y generará una advertencia del navegador o 400 errores de solicitud incorrecta en la mayoría de las instancias del servidor (especialmente con HSTS). Esto se debe a que ve el SSL "host" en un caso de uso posterior al período de TLD. No estoy seguro de una solución alternativa para tratar con la advertencia SSL del host, ya que viene antes de htaccess y otras cosas.

Me gusta pensar que el punto final es la raíz "real" de Internet, y que vive en Virginia, EE. UU. Si omite el punto, siempre se implica alguna raíz. Para usuarios normales, es la misma raíz, y esa es la situación que discutiré hoy.

En mi forma perversa, el punto final me resulta bastante útil. Si estoy revisando el sitio web de otra persona y quiero comenzar de nuevo, sin almacenamiento en caché, sin cookies, etc., y soy demasiado vago para eliminarlos, usaré un navegador diferente o agregaré el punto. Si el sitio no me redirige, tengo URLs nuevas y sin caché para todas las páginas del sitio y otros recursos.

Como webmaster, quiero que todas las personas y robots que vean una página la vean con la misma URL y, por lo tanto, con el mismo nombre de host. Si el nombre de host no es el que quiero que usen, haré una redirección 301 inmediata para que vean la URL correcta en su navegador. Para mis sitios basados ​​en PHP, manejo el problema en PHP y no en el archivo .htaccess o web.config, ya que es más portátil y es más fácil de probar en servidores de desarrollo y almacenamiento provisional. Manejo las conexiones de mi base de datos al mismo tiempo, ya que también varían entre los servidores de desarrollo / preparación / producción.

Aquí hay una versión simplificada de mi código típico. Tenga en cuenta las redirecciones canónicas hacia el final.

    $Host = $_SERVER['HTTP_HOST'];
    switch ( $Host ) {
        case 'exampleweb.local':                    // my local dev machine
                $MysqliParams = array(
                        'host'      =>  'localhost',
                        'username'  =>  'root',
                        'passwd'    =>  'snoopy',
                        'dbname'    =>  'exampledb');
                break;
        case 'www.exampleweb.com':                  // the "live" site
                $MysqliParams = array(
                        'host'      =>  'superhost1.net',
                        'username'  =>  'examp302',
                        'passwd'    =>  'anything-but-snoopy',
                        'dbname'    =>  'examp302_db');
                $GoogleAccount = 'UA-13243546-01;   // only enable for live site
                break;
        case 'exampleweb.mystagingsite.net':        // the client preview site
                $MysqliParams = array(
                        'host'      =>  'superhost1.net',
                        'username'  =>  'examp302',
                        'passwd'    =>  'anything-but-snoopy',
                        'dbname'    =>  'examp302_staging');
                break;
        case 'exampleweb.com':                  // canonical redirects 
        case 'exampleweb.com.':
        case 'www.exampleweb.com.':
                header('HTTP/1.1 301 Moved Permanently');
                header("Location: http://www.exampleweb.com");
                exit;
        default:
                die("invalid hostname $Host");
    }   

mi comentario en https://core.trac.wordpress.org/ticket/35248#comment:9 :

mi respuesta al texto por el primer enlace ( https://web.archive.org/web/20160604095348/http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/web-fully-qualified-domain-name.html ):

Originalmente, como se define en RFC 1738 (§ 3.1), la porción "host" de una URL (Esquema Común de Internet) era siempre e inequívocamente un nombre de dominio totalmente calificado y el mecanismo convencional para distinguir nombres de dominio completamente calificados de los nombres de dominio calificados no se aplicaron. Si fue example.com. o example.com, el host estaba destinado a ser el mismo.

- Creo que no tiene razón, creo que "example.com" no estaba permitido en absoluto en las URL de acuerdo con rfc 1738, se cita en el segundo texto, y lo cito:

3.1. Sintaxis Común del Esquema de Internet
        // <usuario>: <contraseña> @ <host>: <puerto> / <ruta-url>
    anfitrión
        El nombre de dominio completo de un host de red.

y "example.com" no se pudo utilizar en los encabezados http en ese momento, porque el rfc 1738 es de 1994 y el campo host apareció solo con http 1.1 en 1997 (puede consultar en wikipedia).

así que, de hecho, solo se dejó fqdn permitido en las URL. creo que esto fue un error en rfc 1738, porque de esa manera hizo (intentó hacer) que la característica de "dominios relativos" fuera inútil. si no lo rechaza, teóricamente podrían usarse en hrefs de etiqueta "a" en sitios con script local o documentación html estática dentro de grandes compañías que usan dominios relativos, si los navegadores y servidores lo admitieran. pero incluso si el rfc 1738 los rechazó, la gente no lo obedeció: continuaron usando dominios de nivel superior en forma relativa, es decir, sin punto final, por lo que este rechazo por el rfc 1738 no fue un gran problema práctico de todos modos, y la gente tuvo y usó una alternativa a dominios relativos: simplemente crearon dominios locales de nivel superior como "localhost" (y los usaron y usaron también sin punto final).

entonces él dice:

Desafortunadamente, en la práctica, los navegadores web siempre han violado esa especificación y han pasado la parte de "host" a través de los procedimientos de calificación de nombres de sus bibliotecas de cliente DNS al asignar el nombre de host a un conjunto de direcciones IP. (Por ejemplo, aquellos que usaron la biblioteca del Cliente BIND DNS dejarían la opción RES_DNSRCH establecida y no agregarían el punto final final si faltara).

- Creo que quería decir que los hosts sin punto final deberían descartarse como un error, y solo los dominios absolutos (fqdn) deberían pasarse a dns. Creo que probablemente los navegadores pasaron todos los dominios a dns porque la gente usaba sus dominios locales de nivel superior personalizados como "localhost". y de todos modos, más tarde en el rfc 2396 publicado en 1998, se permitió el uso de dominios de nivel superior en URL sin puntos finales.

luego el autor (Jonathan de Boyne Pollard) cita el rfc 2396 y lamenta que haya cambiado de acuerdo con el comportamiento humano establecido, es decir, los estándares de facto, dice que sería mejor si los navegadores obedecieran el rfc 1738, y recomienda a todas las personas que usen solo fqdn, en todos los lugares, como fue ordenado por rfc 1738.

¿Pero qué pasaría si la gente obedeciera el rfc 1738? URL como "http://example.com/test.html "y"http: //localhost/test.html "todo tuvo que reescribirse como"http://example.com./test.html "y"http://localhost./test.html". el navegador tendría que marcar los hosts sin puntos como error, o redirigirlos al hacer clic en ellos en forma completa / absoluta. Todas las personas que configuraron dominios locales de nivel superior como" localhost "tendrían que configurar sus servidores para aceptar solo solicitudes para dominios como "localhost", o aceptar y redirigir [todas las URL dentro de "localhost" a [URL correspondientes en] "localhost". El texto como "localhost" sería útil solo cuando lo escriba en la barra de direcciones del navegador, pero eso sería solo un uso muy inútil, y la función de dominio relativa no es necesaria para eso, porque los navegadores buscan dominios al escribir. El uso de ellos en la fuente html se volvería inútil porque conduciría a que dichos enlaces no funcionen, o haciendo clic en todos los enlaces con "localhost" moverían al usuario a "localhost"."y sería solo una redirección adicional en cada clic (en dichos enlaces). Por lo tanto, rfc 1738 haría que la característica planificada de" dominio relativo "fuera completamente inútil. Si alguna compañía usara esa característica y usara sus dominios relativos en sus sitios locales, y sus urls con dominios relativos no fueron redirigidos a forma absoluta por los navegadores, por lo que sus sitios funcionaron normalmente, si también obedecían rfc 1736, configurarían sus servidores para aceptar solo fqdn, y tendrían que reescribir todas sus urls con fqdn, o trabaje con redireccionamiento adicional en cada clic en tales URL. Si a las compañías les gustara tener un dominio corto como "team101" en lugar de "team101.microsoft.com" en sus barras de direcciones y fuentes html, tendrían que comenzar a usar sus dominios internos personalizados de nivel superior como "team101", es decir, como "localhost. "en lugar de subdominios como" team101.microsoft.com "(que podría usarse como" team101 "antes de que decidieran obedecer el rfc 1738).

-

¡y descubrí que el punto final, que estaba tan fuertemente respaldado por rfc 1738, realmente apareció solo después del estándar sin puntos finales! apareció con rfc 1034 en 1987, se cita en el segundo enlace y lo cito:

Como un nombre de dominio completo termina con la etiqueta raíz, esto lleva a un
formulario impreso que termina en un punto. Usamos esta propiedad para distinguir entre:
- una cadena de caracteres que representa un nombre de dominio completo
 (a menudo llamado "absoluto"). Por ejemplo, "poneria.ISI.EDU".
- una cadena de caracteres que representa las etiquetas iniciales de un
 nombre de dominio que está incompleto y debe ser completado por
 software local que utiliza el conocimiento del dominio local (a menudo
 llamado "pariente"). Por ejemplo, "poneria" usado en el
 Dominio ISI.EDU.

¡rfc 1034 (de 1987) acaba de declarar todos los dominios que se usaron, parece que todos estaban sin puntos finales, los declaró a todos como dominios relativos! pero todavía funcionaban como antes, por lo que probablemente pocas personas lo supieron y continuaron pensando que están solicitando sin ambigüedad un sitio real "example.com" único cuando usan "example.com" sin el punto final. así que eso se ha convertido en una violación de seguridad adicional en algunos casos: el famoso ejemplo real.com podría ser engañado por un administrador de subdominio incluso si no se le otorgaron derechos para crear un dominio local como "localhost". por lo tanto, rfc 1034 tampoco se diseñó muy bien: ¡parece que sus autores no esperaban que tal vez sea {no ampliamente conocido, por lo que se crea una violación de seguridad}!

probablemente rfc 1738 (1994) trató finalmente de llevar la idea de distinción entre dominios absolutos y relativos a una audiencia amplia y también corregir esa violación de seguridad después de 6 años, {pero al arreglar la violación de seguridad al no permitir dominios relativos en las URL hizo inútiles los dominios relativos , {pero creo que probablemente no se usaron ampliamente, probablemente solo en algunas grandes empresas}}. entonces, ¿qué quedaría [resultado] de rfc 1737, si fuera obedecido? - 1) los dominios relativos declarados en 1987 se volverían finalmente inútiles, por lo tanto, el punto final, diseñado para mostrar el dominio absoluto, también se volvería finalmente inútil y redundante "legalmente", es decir, como lo definen los rfcs. (pero tal vez planearon volver a permitir dominios relativos en las URL después de muchos años, cuando una audiencia amplia (público en general) comience a conocer la posibilidad de dominios relativos). 2) y rfc 1737, si se obedeciera, también se solucionaría la violación de seguridad. ¡Pero incluso el rfc 1034 no crearía la violación de seguridad si alcanzara masas y se entendía ampliamente que usar un dominio relativo no es seguro! - Entonces, la receta principal para solucionarlo fue llegar a la gran audiencia, y publicar un rfc más fue solo una de las muchas maneras de hacerlo.

Creo que ahora, probablemente, la característica de dominio relativo no se ha vuelto ampliamente conocida después de la RFC 1034 (de 1987) porque era de uso demasiado limitado: solo en algunas redes locales de grandes compañías o proveedores, y era una característica sin valor práctico, debido a que las redes locales ya podían crear cualquier dominio local, por lo que esa característica era solo para sí misma, de hecho, ¡era solo un texto inútil en rfc que cualquiera debería saber y usar sin tener ningún beneficio adicional! pero la gente creó la pequeña brecha de seguridad al ignorar ampliamente el rfc, mientras que los navegadores comenzaron a obedecerlo.

Ayer revisé la característica de dominios relativos, funciona. (está bien, porque el rfc 2396 (de 1998) lo volvió a permitir después de que el rfc 1034 (de 1987) lo negara, y más tarde el rfc 3986 (de 2005) todavía lo permite). agregué el sufijo dns en windows 10 - panel de control - ... - propiedades del dispositivo de red - propiedades ipv4 - adicional - pestaña dns. cuando agregué "google.com" y abrí "http: // mail / "en firefox, abrió el servidor de google, pero no estaba configurado para funcionar solo con" mail "en el encabezado http" host ", así que obtuve algo como la página" 404 ".

-

mi respuesta al texto por el segundo enlace ( http://www.dns-sd.org/trailingdotsindomainnames.html ):

él también cita la regla en rfc 1738 y dice:

Desafortunadamente, las personas que implementaron clientes de navegador web parecían no entender lo que esto significaba. Cuando accede a un sitio web, el valor que la mayoría de los navegadores web ponen en el campo "Host:" es lo que escribió el usuario, no lo que la computadora realmente usó, después de aplicar la lista de búsqueda del usuario DNS para construir un nombre completamente calificado del nombre parcial Por ejemplo, aquí hay tres formas diferentes en que el usuario puede referirse al host "www.example.com". ... Al enviar el parámetro "Host:" al servidor web, el cliente del navegador web ingresa lo que el usuario escribió ("www.ejemplo.com", "www.ejemplo.com" o "www"). de lo que el cliente terminó buscando en DNS ("www.example.com" en los tres casos). ...

- esto no es muy cierto (correcto), porque el rfc 1738 era muy estricto a este respecto, y no permitía dominios relativos en todas las URL, incluso si está en la barra de direcciones del navegador, y la URL en sí es la forma [recomendada] de hacer cualquier referencia a los sitios, incluso si las personas lo escriben en papel, por lo que no se les permitió a los usuarios referirse a ese sitio de esas 3 maneras, por rfc 1738, ¡si esos usuarios pensarían que usaban URL!

y parece que el autor de este texto (Stuart Cheshire) no sabía sobre rfc 2396, por lo que este texto está desactualizado.

-

¿Y cuál es la situación hoy en día? rfc 3986 (https://tools.ietf.org/html/rfc3986#page-21 ) permite hacer referencia al dominio absoluto sin punto final: dice "La etiqueta de dominio más a la derecha de un nombre de dominio completo en DNS puede ir seguida de una sola". "" y que debe usarse si es "necesario distinguir entre el nombre de dominio completo y algún dominio local". Creo que debido a los estándares de facto casi nunca es necesario, por lo que WordPress puede aceptar el estándar de facto y redirigir desde la dirección con un punto final a la dirección sin él.