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.