Como os sites devem lidar com o nome do host com ponto à direita?

Eu li esta pergunta Como os URLs podem ter um ponto. no final, por exemplo, www.bla.de.? e perceba que o FQDN deve conter um final .para o rótulo raiz da árvore DNS:

example.com. ao invés de example.com

No entanto, existem problemas como apontado neste artigo do blog :

Se você não considerar o fato de que o usuário pode digitar acidentalmente o nome de domínio com um ponto no final ou seguir um link recebido de algum "bem-intencionado" e entrar no seu nome de domínio com o ponto no final, como o Como resultado, pode levar a consequências inesperadas:

1) Se o site usa HTTPS, ao navegar para o nome de domínio com o ponto no final, o navegador exibirá o aviso em uma conexão não confiável.

2) A autenticação pode ser interrompida, pois os cookies geralmente são definidos para o nome de domínio sem um ponto no final. O usuário, nesse caso, ficará surpreso por não conseguir fazer login. Vale ressaltar que, se você definir um cookie para um nome de domínio com um ponto no final, esse cookie não será passado para o nome do domínio sem o ponto no final e vice-versa.

3) O JavaScript na página pode estar quebrado.

4) Pode haver problemas com o cache das páginas do site (por exemplo, https://www.cloudflare.com/não limpa o cache das páginas se o nome do domínio tiver um ponto no final, considerando-o um nome de domínio inválido).

5) Se, nas condições da configuração do servidor da Web, você confiar no nome de domínio específico ($ http_host no Nginx,% {HTTP_HOST} no Apache) sem o ponto no final, poderá enfrentar uma variedade de situações inesperadas: redirecionamentos inesperados, básico problemas de autorização, etc.

6) Se o servidor da web não estiver configurado para aceitar solicitações no nome de domínio com o ponto final, qualquer usuário que digitar acidentalmente um nome de domínio com o ponto final verá algo como Solicitação inválida - Nome de host inválido.

7) É possível que os mecanismos de pesquisa descubram que seu recurso possui um conteúdo duplicado, se alguém postar links acidental ou intencionalmente para suas páginas da web com um ponto no final do nome do domínio.

Eu também percebo que http://webmasters.stackexchange.com./faz a 400 Bad Request. Mas como o nome de domínio apropriado deve conter um .no final, não deveríamos emitir um 400erro ou 301redirecionar para nomes de host sem um ponto à direita? Qual é a maneira correta de lidar com esse problema de maneira coerente e consistente?

Para responder parcialmente à sua pergunta, você pode adicioná-la às regras do encaminhador canônico htaccess. No sentido HTTP básico, ele procura um período antes do URI e o trabalha em qualquer mecanismo de encaminhamento anti-duplicado usado. Aqui está um exemplo, incluindo uma rota sub util comum "addon domain":

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]

O que isso faria é encaminhar todos os itens a seguir para um domínio HTTP www canônico:

• domain.hostdomain.com
• domain.hostdomain.com.
• www.domínio.hostdomínio.com
• www.domain.hostdomain.com.
• domain.com
• domain.com.
• www.domain.com.

Todos encaminham para:

• http://www.domain.com

No entanto, existe uma ressalva - conforme indicado na citação original do blog, o SSL não encaminhará corretamente e exibirá um aviso do navegador ou 400 erros de solicitação incorreta na maioria das instâncias do servidor (especialmente com o HSTS). Isso ocorre porque ele vê o SSL "host" em um caso de uso pós-período de TLD. Não tenho certeza de uma solução alternativa para lidar com o aviso SSL do host, pois ele vem antes do htaccess e outras coisas.

Eu gosto de pensar no ponto final como a raiz "real" da Internet e que ele mora na Virgínia, EUA. Se você deixar de fora o ponto, alguma raiz estará sempre implícita. Para usuários normais, é a mesma raiz e é essa a situação que discutirei hoje.

Na minha maneira perversa, acho o ponto à direita bastante útil. Se eu estiver consultando o site de outra pessoa e quiser começar de novo, sem cache, sem cookies, etc., e estiver com preguiça de liberá-los, utilizarei outro navegador ou adicionarei o ponto. Se o site não me redirecionar, tenho URLs não armazenados em cache totalmente atualizados para todas as páginas do site e outros recursos.

Como webmaster, desejo que todas as pessoas e robôs que visualizam uma página a visualizem com o mesmo URL e, portanto, com o mesmo nome de host. Se o nome do host não for o que eu quero que eles usem, farei um redirecionamento 301 imediato para que eles vejam o URL correto no navegador. Para meus sites baseados em PHP, eu lido com o problema no PHP e não no arquivo .htaccess ou web.config, pois é mais portátil e mais fácil de testar em servidores de desenvolvimento e armazenamento temporário. Lido com minhas conexões com o banco de dados ao mesmo tempo, pois elas também variam entre os servidores de desenvolvimento / preparo / produção.

Aqui está uma versão simplificada do meu código típico. Observe os redirecionamentos canônicos no 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");
    }   

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.