meu comentário em https://core.trac.wordpress.org/ticket/35248#comment:9 :
minha resposta ao texto pelo primeiro link ( https://web.archive.org/web/20160604095348/http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/web-fully-qualified-do-dominio-name.html ):
Originalmente, conforme definido na RFC 1738 (§ 3.1), a parte "host" de uma URL (Esquema comum da Internet) era sempre e inequivocamente um nome de domínio totalmente qualificado e o mecanismo convencional para distinguir nomes de domínio totalmente qualificados de não totalmente nomes de domínio qualificados não se aplicavam. Se foi exemplo.com. ou example.com, o host foi projetado para ser o mesmo.
- acho que ele não está certo, acho que "example.com" não era permitido em urls de acordo com a rfc 1738, é citado no segundo texto e cito:
3.1 Sintaxe comum do esquema da Internet
// <usuário>: <senha> @ <host>: <port> / <url-path>
hospedeiro
O nome de domínio completo de um host de rede
e "example.com" não pôde ser usado nos cabeçalhos http naquele momento, porque o rfc 1738 é de 1994 e o campo host apareceu apenas com o http 1.1 em 1997 (você pode verificar na wikipedia).
portanto, apenas fqdn foi permitido em URLs. eu acho que isso foi um erro na rfc 1738, porque dessa forma ele fez (tentou fazer) os "domínios relativos" recurso inútil. se não o proibisse, eles teoricamente poderiam ser usados em hrefs de tags "a" em sites com script local ou documentação estática de html em grandes empresas que usavam domínios relativos, se navegadores e servidores o suportassem. mas mesmo que o rfc 1738 não os permitisse, as pessoas não o obedeciam: continuavam a usar domínios de nível superior em forma relativa, ou seja, sem ponto à direita, portanto, a proibição pelo rfc 1738 não era um grande problema prático, e as pessoas usaram e usaram uma alternativa para domínios relativos: eles criaram domínios locais de nível superior, como "localhost" (e os usaram e os usaram também sem pontos à direita).
então ele diz:
Infelizmente, na prática, os navegadores da Web sempre violaram essa especificação e passaram a parte "host" pelos procedimentos de qualificação de nome de suas bibliotecas de clientes DNS ao mapear o nome do host para um conjunto de endereços IP. (Por exemplo, aqueles que usavam a biblioteca BIND DNS Client deixariam a opção RES_DNSRCH definida e não acrescentariam o ponto final final, caso estivesse ausente.)
- Eu acho que ele quis dizer que hosts sem ponto à direita devem ser descartados como erro, e apenas domínios absolutos (fqdn) devem ser passados para o DNS. Eu acho que provavelmente os navegadores passaram todos os domínios para o DNS porque as pessoas usavam seus domínios locais de nível superior personalizados, como "localhost". de qualquer forma, mais tarde, na rfc 2396 publicada em 1998, foi permitido o uso de domínios de nível superior em URLs sem pontos à direita.
então o autor (Jonathan de Boyne Pollard) cita a rfc 2396 e lamenta que isso tenha mudado de acordo com o comportamento humano estabelecido, isto é, padrões de fato, diz que seria melhor se os navegadores obedecessem à rfc 1738 e recomenda a todas as pessoas que usem apenas o fqdn, em todos os lugares, como foi ordenado pela rfc 1738.
- mas o que aconteceria se as pessoas obedecessem à rfc 1738? URLs como "http://example.com/test.html "e"http: //localhost/test.html "todos tiveram que ser reescritos como"http://example.com./test.html "e"http://localhost./test.html". o navegador teria que marcar hosts sem pontos como erro ou redirecionar ao clicar neles para a forma completa / absoluta deles. todas as pessoas que configuraram domínios locais de nível superior como" localhost "teriam que configurar seus servidores para aceitar apenas solicitações para domínios como "localhost." ou aceite e redirecione [todos os URLs dentro] "localhost" para [URLs correspondentes em] "localhost". o texto como "localhost" permaneceria útil apenas ao digitá-lo na barra de endereços do navegador, mas isso seria apenas uso muito inútil, e o recurso de domínio relativo não é necessário para isso, porque os navegadores pesquisam domínios ao digitar. o uso deles na fonte html se tornaria inútil, pois levaria a que esses links não funcionassem ou clique em todos os links com "localhost" moveriam o usuário para "localhost."e seria apenas um redirecionamento extra a cada clique (nesses links). Assim, o rfc 1738 tornaria o recurso" domínio relativo "planejado totalmente inútil. Se alguma empresa usasse esse recurso e usasse seus domínios relativos em seus sites locais, e seus URLs com domínios relativos não foram redirecionados para a forma absoluta pelos navegadores; portanto, seus sites funcionavam normalmente; se eles também obedecessem à rfc 1736, eles configurariam seus servidores para aceitar apenas fqdn e teriam que reescrever todos esses URLs com fqdn ou trabalhe com redirecionamento extra a cada clique em tais URLs. Se essas empresas gostassem de ter um domínio curto como "team101" em vez de "team101.microsoft.com." em suas barras de endereço e fontes html, teriam que começar a usar seus domínios internos de nível superior personalizados, como "team101" ou seja, "localhost. "em vez de subdomínios como" team101.microsoft.com. "(que poderia ser usado apenas como" team101 "antes de decidirem obedecer à rfc 1738).
-
e descobri que o ponto final, que foi tão fortemente apoiado pela rfc 1738, realmente apareceu apenas após o padrão sem pontos finais! apareceu com a rfc 1034 em 1987, é citado no segundo link e cito:
Como um nome de domínio completo termina com o rótulo raiz, isso leva a uma
formulário impresso que termina em um ponto. Usamos essa propriedade para distinguir entre:
- uma cadeia de caracteres que representa um nome de domínio completo
(geralmente chamado de "absoluto"). Por exemplo, "poneria.ISI.EDU".
- uma sequência de caracteres que representa os rótulos iniciais de um
nome de domínio incompleto e deve ser preenchido por
software local usando o conhecimento do domínio local (geralmente
chamado "relativo"). Por exemplo, "poneria" usado no
Domínio ISI.EDU.
O rfc 1034 (de 1987) acabou de declarar todos os domínios usados, parece que todos estavam sem pontos à direita, declarou todos como domínios relativos! mas eles ainda funcionavam como antes, então provavelmente poucas pessoas sabiam disso e continuavam pensando que estavam solicitando inequivocamente um site real "example.com" único e exclusivo quando usavam "example.com" sem ponto final. de modo que isso se tornou uma brecha de segurança adicional em alguns casos: o famoso example.com real poderia ser falsificado por um administrador de subdomínio, mesmo que ele não tivesse direitos para criar um domínio local como "localhost". portanto, o rfc 1034 também não foi projetado muito bem: parece que seus autores não esperavam que talvez {não fosse amplamente conhecido, criando uma violação de segurança}!
provavelmente a rfc 1738 (1994) tentou finalmente trazer a idéia de distinção entre domínios absolutos e relativos para um grande público e também consertar essa violação de segurança após 6 anos {mas corrigindo a violação de segurança proibindo domínios relativos em URLs, tornou inúteis domínios relativos , {mas acho que provavelmente não foram amplamente utilizados, provavelmente apenas em algumas grandes empresas}}. então, o que seria [deixado] em resultado da rfc 1737, se fosse obedecido? - 1) os domínios relativos declarados em 1987 se tornariam finalmente inúteis; assim, o ponto final, projetado para mostrar domínio absoluto, também se tornaria finalmente inútil e redundante "legalmente", ou seja, conforme definido pelos rfcs! (mas talvez eles tenham planejado posteriormente permitir novamente domínios relativos em URLs depois de muitos anos, quando um grande público (público em geral) começa a saber sobre a possibilidade de domínios relativos). 2) e rfc 1737, se fosse obedecido, também corrigia a violação de segurança. - mas mesmo o rfc 1034 não criaria a violação de segurança se atingisse massas e foi amplamente entendido que o uso de domínio relativo não é seguro! - então, a receita principal para consertá-lo estava atingindo o grande público, e publicar mais uma rfc era apenas uma das muitas maneiras de fazê-lo.
acho que agora provavelmente o recurso de domínio relativo não se tornou amplamente conhecido após a rfc 1034 (de 1987) porque era de uso muito limitado: somente em algumas grandes empresas ou redes locais de provedores, e era um recurso sem valor prático, porque as redes locais já podiam criar qualquer domínio local, de modo que esse recurso era apenas para si, era de fato apenas um texto inútil em rfc que qualquer pessoa deveria conhecer e usar sem ter nenhum benefício adicional! mas as pessoas criaram a pequena falha de segurança ignorando amplamente o rfc, enquanto os navegadores começaram a obedecê-lo.
Eu verifiquei o recurso de domínios relativos ontem, ele funciona. (tudo bem, porque a rfc 2396 (de 1998) a permitiu novamente depois que a rfc 1034 (de 1987) foi negada e, posteriormente, a rfc 3986 (de 2005) ainda permite). Eu adicionei o sufixo DNS no Windows 10 - painel de controle - ... - propriedades do dispositivo de rede - propriedades do IPv4 - adicional - guia DNS. quando adicionei "google.com" e abri "http: // mail / "no firefox, ele abriu o servidor do google, mas não estava configurado para funcionar apenas com" mail "no cabeçalho http" host ", por isso recebi algo como a página" 404 ".
-
minha resposta ao texto pelo segundo link ( http://www.dns-sd.org/trailingdotsindomainnames.html ):
ele também cita a regra na rfc 1738 e diz:
Infelizmente, as pessoas que implementavam clientes de navegadores da Web pareciam não entender o que isso significava. Quando você acessa um site, o valor que a maioria dos navegadores coloca no campo "Host:" é o que o usuário digitou, não o que o computador realmente acabou usando, após aplicar a lista de pesquisa do usuário DNS para formar um nome completo a partir do nome parcial. Por exemplo, aqui estão três maneiras diferentes pelas quais o usuário pode consultar o host "www.example.com". ... Ao enviar o parâmetro "Host:" para o servidor da Web, o cliente do navegador coloca o que o usuário digitou ("www.example.com.", "Www.example.com" ou "www") do que o cliente acabou pesquisando no DNS ("www.example.com." nos três casos). ...
- isso não é muito verdadeiro (correto), porque o rfc 1738 era muito rigoroso nesse sentido, e não permitia domínios relativos em todos os URLs, mesmo que esteja na barra de endereços do navegador, e o próprio URL é a maneira [recomendada] de fazer quaisquer referências a sites, mesmo que as pessoas o escrevam em papel, portanto, não era permitido que os usuários se referissem a esse site dessa maneira, pela rfc 1738, se esses usuários pensassem que usavam URL!
e parece que o autor deste texto (Stuart Cheshire) não sabia sobre a rfc 2396, portanto esse texto está desatualizado.
-
e qual é a situação hoje em dia? rfc 3986 (https://tools.ietf.org/html/rfc3986#page-21 ) permite fazer referência ao domínio absoluto sem ponto final: diz "O rótulo de domínio mais à direita de um nome de domínio totalmente qualificado no DNS pode ser seguido por um único". "" e que deve ser usado se for "necessário distinguir entre o nome completo do domínio e algum domínio local". Eu acho que, devido aos padrões de fato, quase nunca é necessário, então o wordpress pode aceitar o padrão de fato e redirecionar do endereço com ponto à direita para o endereço sem ele.