Por que colocar um ponto após o URL remove as informações de login?

Adicionar o ponto ao final do nome de domínio o torna um nome de domínio totalmente qualificado absoluto em vez de apenas um nome de domínio totalmente qualificado regular, e a maioria dos navegadores trata os nomes de domínio absolutos como sendo um domínio diferente do nome de domínio regular equivalente (I não sei por que eles fazem isso).

Um pouco de fundo:

O sistema de nomes de domínio é estritamente hierárquico, assim como um sistema de arquivos ou um diretório X.500/LDAP. Porém, ao contrário dos sistemas de arquivos ou do X.500, a hierarquia é listada da direita para a esquerda em vez da esquerda para a direita. Portanto, o componente mais à direita de um nome de domínio é o topo da hierarquia. Colocar um ponto à direita de um nome de domínio o torna absoluto, o que significa que está explicitamente enraizado no topo da hierarquia do DNS. Em essência, é o mesmo que usar um nome distinto completo em vez de um nome comum em uma pesquisa X.500 ou colocar um /no início de um caminho POSIX.

O uso de um FQDN absoluto tem algumas implicações específicas sobre como um sistema cliente procurará o registro DNS desse domínio:

• Isso faz com que alguns resolvedores ignorem quaisquer entradas definidas localmente (por exemplo, fará com que alguns resolvedores ignorem /etc/hostsem um sistema semelhante ao UNIX).
• Quando usado com o .localdomínio, forçará alguns sistemas a usar mDNS em vez do DNS tradicional para tentar resolver o nome.
• Isso faz com que todos os resolvedores ignorem qualquer domínio de pesquisa configurado ou domínios DNS locais ao pesquisar o nome.

Essa última parte é a parte importante e é a razão pela qual existe o conceito de um FQDN absoluto. A maioria dos sistemas pode ser configurada com o que chamamos de domínio de pesquisa. Quando eles forem resolver um determinado domínio, eles tentarão primeiro procurar em qualquer domínio de pesquisa configurado e resolverão apenas a partir do topo da hierarquia se não conseguirem encontrar o nome em nenhum domínio de pesquisa configurado (portanto, se você foo.exampleconfigurou como um domínio de pesquisa em seu sistema e tentasse acessar bar.exampleem um navegador, ele (normalmente, veja abaixo) tentaria ir bar.example.foo.exampleprimeiro e somente se não conseguisse encontrá-lo, tentaria bar.examplediretamente). Atualmente, a maioria dos resolvedores, mas não todos, ignora o domínio de pesquisa ao resolver um domínio que termina com um nome de domínio de nível superior conhecido ( .com,.net, etc), portanto, geralmente não é necessário que a maioria dos usuários use FQDNs absolutos e, portanto, a maioria das pessoas não os conhece.

Isso ocorre porque example.come example.com.são (às vezes!) considerados hosts diferentes, por dois motivos:

• Porque, na verdade, eles podem ter significados diferentes, dependendo da sua configuração de rede específica.
• Porque os RFCs padrão da Internet que definem a sintaxe dizem isso, dependendo de como você os interpreta.

Se o navegador os considerar hosts diferentes, ele não compartilhará o estado da sessão (por exemplo, cookies) entre eles, portanto, um "host" não saberá que o outro está conectado.

Parte disso é que o navegador pode não saber, dependendo de sua implementação, que os dois realmente resolvem para o mesmo nome. Especialmente se ele passou a resolução de DNS para um resolvedor remoto e espera apenas um endereço IP de volta (em vez de todo o registro expandido).

Resumo

• Os dois hosts podem ser diferentes no mundo real.
• Às vezes não está claro como os padrões os veem. Parece que muitos padrões de aplicativos não lidam explicitamente com a situação.
• Daqueles que descrevem a canonização e comparação de nomes de domínio, eles geralmente dividem o nome em "rótulos" individuais.
• Em seguida, depende se você considera a forma absoluta do nome de domínio como tendo um rótulo nulo adicional, conforme afirma o RFC original do DNS.
• Em um mundo ideal, todas essas comparações ocorreriam usando apenas nomes de domínio absolutos e nomes relativos não seriam usados ​​além da pesquisa original. Ou os navegadores podem considerar todos os nomes como absolutos e não permitir pesquisas relativas. Mas este não parece ser o caso atualmente e pode introduzir outros problemas.
  • Embora possa não ser ilegal para um navegador realizar a própria pesquisa de DNS (em vez de usar resolvedores de sistema operacional) e, portanto, descobrir o nome de domínio absoluto final, isso também não é exigido por nenhum padrão que eu possa encontrar.

diferenças práticas

A parte dos diferentes significados é, como Austin observou, uma consequência de como as pesquisas de DNS funcionam com os recursos de pesquisa. Seu rótulo típico sem raiz, por exemplo example.com, fará com que seu resolvedor de DNS típico tente primeiro qualquer pesquisa suficiente definida em seu sistema. Em um ambiente corporativo, este pode ser o domínio da sua empresa, por exemplo, se você mycompany.example.definiu como um sufixo de pesquisa, qualquer pesquisa por example.comtentará primeiro example.com.mycompany.example.. Isso é útil se você quiser procurar um servidor interno sem precisar digitar todo o domínio totalmente qualificado ("completo").

Mas e se você realmente quisesse o público example.com? Você pode usar o trailing ., no formato example.com., para informar ao resolvedor que você inseriu um nome absoluto ("completo") e não tentar nenhuma pesquisa relativa contra pesquisas suficientes.

Como os padrões da Internet veem a situação

Há alguns lugares que precisamos procurar como eles são padronizados e, infelizmente, as águas podem estar um pouco turvas. Normalmente, gosto de procurar primeiro o padrão mais relevante e voltar a partir daí, mas, como ele está tão disperso, pode ser mais fácil começar de baixo.

Nomes de domínio

O padrão da Internet RFC1034 descreve nomes de domínio na seção 3.1 e especifica a "sintaxe de nome preferencial" para nomes de domínio na seção 3.5 . Observação na seção 3.1:

Cada nó tem um rótulo, que é de zero a 63 octetos de comprimento. Nós irmãos podem não ter o mesmo rótulo, embora o mesmo rótulo possa ser usado para nós que não são irmãos. Um rótulo é reservado, e esse é o rótulo nulo (ou seja, comprimento zero) usado para a raiz.

[...]

Quando um usuário precisa digitar um nome de domínio, o comprimento de cada rótulo é omitido e os rótulos são separados por pontos ("."). Como um nome de domínio completo termina com o rótulo raiz, isso leva a um 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 cadeia de caracteres que representa os rótulos iniciais de um nome de domínio que está incompleto e deve ser completado pelo software local usando o conhecimento do domínio local (geralmente chamado de "relativo"). Por exemplo, "poneria" usado no domínio ISI.EDU.

Os nomes relativos são considerados relativos a uma origem bem conhecida ou a uma lista de domínios usados ​​como uma lista de pesquisa. Os nomes relativos aparecem principalmente na interface do usuário, onde sua interpretação varia de implementação para implementação, e em arquivos principais, onde são relativos a um único nome de domínio de origem. A interpretação mais comum usa a raiz "." como a origem única ou como um dos membros da lista de pesquisa, portanto, um nome relativo com vários rótulos geralmente é aquele em que o ponto final foi omitido para economizar digitação.

URIs

A partir daí, podemos ver como os nomes de domínio são usados ​​em URIs, Internet Standard RFC3986 . Na seção 3 , vemos a sintaxe do URI. A parte que nos interessa é a autoridade , que contém um host (seguido por uma :porta opcional). Isso é melhor definido na seção 3.2.2 , especificamente a parte que fala sobre um nome registrado :

Um nome registrado destinado a pesquisa no DNS usa a sintaxe definida na Seção 3.5 da [RFC1034] e na Seção 2.1 da [RFC1123]. Esse nome consiste em uma sequência de rótulos de domínio separados por ".", cada rótulo de domínio começando e terminando com um caractere alfanumérico e possivelmente também contendo caracteres "-". 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 deve ser se for necessário distinguir entre o nome de domínio completo e algum domínio local.

Isso nos traz de volta à pesquisa suficiente e à possibilidade de um "domínio local" corresponder a um resultado diferente do "domínio completo". Lembre-se que conceitualmente, de acordo com RFC1034, example.com.é equivalente a example.com.<root>, onde <root>é o rótulo nulo especial.

Há alguma discussão sobre normalização na seção 6, mas nada sobre o host, muito menos pontos finais.

O padrão proposto RFC 7230 , que define HTTP/1.1, observa que ele segue amplamente o RFC3986 para definições de URI na seção 2.7 .

TLS

É aqui que as coisas ficam confusas.

RFC2818 informativo descreve HTTP sobre TLS (HTTPS). Ele não diz nada explícito sobre correspondência de host, além de seguir as regras no RFC2459 (substituído pelo padrão proposto RFC5280 ). Isso se refere ao RFC1034 (aquele que definiu o DNS), mas não diz nada explícito sobre endereços absolutos ou pontos finais.

O padrão proposto RFC6125 é uma abordagem mais moderna dos usos do TLS. Ele fala mais sobre a correspondência de nomes de domínio, mas, novamente, não aborda explicitamente os pontos finais - embora diga que você deve corresponder apenas a "nomes de domínio totalmente qualificados" (esse é um conceito surpreendentemente mal definido). Ele diz que todos os rótulos devem corresponder - o que remonta ao RFC1034 e, se considerarmos que o rótulo nulo representa a raiz, example.comeles example.com.têm rótulos diferentes (o último tem 3, examplee com) <root>.

Há alguma discussão no bug Mozilla 134402 sobre as diferentes interpretações.

Biscoitos

Afastando-se um pouco do TLS, podemos examinar os cookies no padrão proposto RFC6265 . Lá, a seção 5.1.2 e a seção 5.1.3 falam sobre canonização e correspondência de nomes de host. Aqui, novamente, dividimos o nome do host em rótulos individuais para realizar a canonização (que essencialmente converte nomes de domínio Unicode em letras minúsculas ASCII/punycode). E, novamente, depende se você considera que o rótulo nulo que representa a raiz foi preservado por meio dessa etapa de canonização. Se você fizer isso, eles terão rótulos diferentes e, portanto, são hosts diferentes para fins de cookies.

A explicação dada por Mokubai está exatamente correta, e o problema está no navegador não identificar que se trata do mesmo domínio e por isso não enviar os cookies.

Mas a situação é ainda pior: o ponto no final apenas marca o domínio como totalmente qualificado (inequívoco), o que funciona muito bem com o DNS, pois a mensagem finalmente chega ao endereço correto ( superuser.com).

Eu até obtive do Fiddler esta caixa de diálogo para superuser.com.(com ponto):

Com alguns testes empíricos, aqui estão os cabeçalhos enviados com essas duas solicitações.

https://superuser.com(informações confidenciais riscadas)

https://superuser.com.(com ponto, nenhuma informação sensível precisa ser riscada)

Conclusão : O problema é que o navegador não ignora um ponto no final de um nome de domínio totalmente qualificado, como é bem possível pelo padrão DNS.

Observação adicional: Os desenvolvedores do navegador não foram os únicos a cair nessa armadilha. Eu tenho o complemento NoScript instalado para interromper todo o JavaScript, mas superuser.com(sem ponto) é permitido. Mas o NoScript ainda bloqueia superuser.com.(com ponto) como sendo um site desconhecido. Não tenho dúvidas de que o teste encontraria o mesmo comportamento em muitos outros produtos.

É estranho que os desenvolvedores de grandes atores no domínio da Web, como Google Chrome, Firefox e Fiddler da Microsoft, todos responsáveis ​​por muitos avanços nos padrões da Web, não tenham dado atenção a essa possibilidade.