为什么在URL后面加点会删除登录信息？

#1 楼

在域名的末尾添加点使其成为绝对完全限定域名，而不仅仅是常规完全限定域名，并且大多数浏览器将绝对域名视为与等效常规域名不同的域（I我不确定为什么要这么做）。


有一点背景知识：

域名系统严格地是分层的，就像文件系统一样，或者X.500 / LDAP目录。但是与文件系统或X.500不同，层次结构是从右到左而不是从左到右列出的。因此，域名的最右边部分是层次结构的顶部。在域名的最右边放置一个点使其成为绝对名称，这意味着它明确地植根于DNS层次结构的顶部。从本质上讲，这与在X.500查找中使用完整专有名称而不是通用名称，或在POSIX路径的开头放置/相同。

使用绝对FQDN具有一个客户端系统如何查找该域的DNS记录的一些具体含义：


它导致某些解析程序跳过任何本地定义的条目（例如，它将导致某些解析程序执行以下操作：在类似UNIX的系统上忽略/etc/hosts。）
当与.local域一起使用时，它将迫使某些系统使用mDNS而不是传统DNS来尝试解析名称。
这将导致所有解析器忽略查找名称时，任何已配置的搜索域或本地DNS域。

最后一部分是重要部分，并且是绝对FQDN概念存在的原因。大多数系统都可以配置搜索域。当他们去解析给定的域时，他们将首先尝试在任何配置的搜索域下查找，并且仅当它们在任何已配置的搜索域中都找不到名称时才从层次结构的顶部进行解析（因此，如果您配置了foo.example作为系统上的搜索域并尝试在浏览器中转到bar.example，它将（通常，请参见下文）首先尝试转到bar.example.foo.example，并且只有在找不到时，才可以直接尝试bar.example）。如今，大多数（但不是全部）解析器在解析以已知顶级域名（.com，.net等）结尾的域时会忽略搜索域，因此大多数用户通常不需要使用绝对FQDN，因此大多数人不了解它们。

#2 楼

这是因为example.com和example.com.有时被视为不同的主机，原因有两个：


因为它们实际上可以具有不同的含义，具体取决于您的特定网络配置。
因为定义语法的Internet标准RFC会这样说，具体取决于您如何解释它们。

如果浏览器认为它们是不同的主机，它将不会在它们之间共享会话状态（例如cookie），因此“主机”将不知道您是否登录了另一个主机。

部分原因是浏览器可能不知道这取决于其实现，而这实际上取决于两者的名称。尤其是如果它已将DNS解析传递给远程解析器，并且只希望返回IP地址（而不是整个扩展记录）。


摘要


在现实世界中，这两个主机实际上可以不同。
有时不清楚标准如何看待它们。似乎许多应用程序标准都没有明确处理这种情况。
在描述域名规范化和比较的标准中，通常将名称分为单独的“标签”。
然后，它取决于是否使用域名。您会认为域名的绝对形式有一个附加的空标签，如原始DNS RFC所述。
在理想情况下，所有这些比较都将仅使用绝对域名进行，而相对名称则不会使用过去的原始查询。或者浏览器可以将所有名称都视为绝对名称，并禁止相对查找。但这似乎不是当前情况，并且可能带来其他问题。


虽然浏览器本身执行DNS查找（而不是使用OS解析器）可能不是非法的），因此找出最终的绝对域名，这也是我所能找到的任何标准所不需要的。




实际差异

正如奥斯丁所指出的，不同的含义部分是DNS查找如何与搜索足够一起工作的结果。您的典型无根标签，例如example.com，将使您的典型DNS解析器首先尝试在系统上定义的任何搜索条件。在公司环境中，这可能是您的公司域，例如如果您将mycompany.example.定义为搜索后缀，则对example.com的任何查找都将首先尝试example.com.mycompany.example.。如果您要查找内部服务器而不必键入整个完全限定（“ complete”）域，这将非常有用。

但是如果您实际上想要公共example.com，该怎么办？可以使用.形式的结尾example.com.，以告知解析程序您输入了绝对（“完整”）名称，而不必尝试对搜索进行任何相对查找。


Internet标准如何看待这种情况

我们需要在一些地方寻找这些标准的标准化方式，不幸的是，水域可能会有些混乱。我通常想先寻找最相关的标准，然后再从那里找回来，但是由于它是如此分散，因此从底部开始可能更容易。

域名

Internet标准RFC1034在3.1节中描述了域名，并在3.5节中指定了域名的“首选名称语法”。在第3.1节中的注释：


每个节点都有一个标签，标签的长度为0到63个八位位组。 Brother
节点可能没有相同的标签，尽管非Brother节点可以使用相同的标签。保留了一个标签，即
用于根的空标签（即长度为零）。

[...]

当用户需要输入域名，每个标签的长度被省略，标签之间用点号（..）分隔。由于完整的
域名以根标签结尾，因此会形成打印形式，
以点结尾。我们使用此属性来区分：


代表完整域名的字符串
（通常称为“绝对”）。例如，“ poneria.ISI.EDU。”
代表不完整的域名的开始标签的字符串，应由本地软件使用以下知识来完成此域名：本地域（通常称为“相对”）。例如，在
ISI.EDU域中使用的“ poneria”。

相对名称是相对于众所周知的来源获取的，还是相对于
用作域名的列表搜索列表。相对名称主要出现在用户界面上，在不同的实现中，其解释也有所不同；在主文件中，相对名称是相对于单个原始域名的。最常见的解释
使用根“”。作为搜索列表的单一来源或成员之一，因此多标签相对名称通常是这样的名称，其中
省略了后缀点以保存输入。


URIs

从那里我们可以了解如何在URI（互联网标准RFC3986）中使用域名。在第3节中，我们将看到URI语法。我们感兴趣的部分是授权，它包含一个主机（后面是一个可选的:端口）。这将在3.2.2节中进一步定义，特别是有关注册名称的部分：


用于DNS中查找的注册名称使用在[RFC1034]的第3.5节和[RFC1123]的第2.1节。
该名称由一系列域标签组成，这些域标签由“。”分隔，
每个域标签以字母数字字符开头和结尾
，也可能包含“-”字符。 DNS中完全限定域名的最右边的域
标签后可以跟
单“。”并且应该在必要时区分完整的域名和某些本地域。


这使我们回到搜索足够的地方，并且有了“本地域”的可能性匹配与“完整域”不同的结果。请记住，从概念上讲，根据RFC1034，example.com.等同于example.com.<root>，其中<root>是特殊的空标签。

在第6节中对规范化进行了一些讨论，但关于主机的内容没有讨论，更不用说尾随点了。

提议的标准RFC 7230（定义HTTP / 1.1）注意到，它在很大程度上遵循2.7节中关于URI定义的RFC3986。

TLS

此令人困惑的地方。

信息性RFC2818描述了TLS上的HTTP（HTTPS）。除了遵循RFC2459（由提议的标准RFC5280取代）中的规则外，它没有对主机匹配进行任何明确说明。这指的是RFC1034（定义DNS的那个），但没有明确说明绝对地址或尾随点。

提议的标准RFC6125是对TLS的更现代的使用。它讨论了更多有关域名匹配的问题，但同样也没有明确地指出尾随点-但是，它确实说您只应该匹配“完全合格的域名”（这是一个定义不明确的概念）。它确实说所有标签都必须匹配-追溯到RFC1034，如果我们认为null标签代表根，则example.com和example.com.确实具有不同的标签（后者具有3，example，com和<root>）。 />
Mozilla错误134402中有一些关于不同解释的讨论。

Cookies

稍微远离TLS，我们可以看一下建议标准RFC6265中的cookie。在那里，第5.1.2节和第5.1.3节讨论了主机名的规范化和匹配。在这里，我们再次将主机名拆分为各个标签以执行规范化（这实际上将Unicode域名转换为小写的ASCII / punycode）。并且，再次取决于是否考虑通过该规范化步骤保留表示根的null标签。如果这样做，则它们具有不同的标签，因此对于cookie而言，它们是不同的主机。

#3 楼

Mokubai给出的解释是完全正确的，问题出在
浏览器无法识别出这是同一个域，因此没有
发送cookie。

但是这种情况更糟糕的是：末尾的点仅将域标记为完全合格（明确），与DNS配合得很好，因为消息最终到达正确的地址（superuser.com）。

我什至从Fiddler得到了superuser.com.的对话框（带点）：



经过一些实证测试，这是发送的标头这两个请求。

https://superuser.com（删除了敏感信息）



https://superuser.com.（带点，不需要删除敏感信息）



结论：问题在于浏览器没有忽略
完全限定域名末尾的点，这很可能是DNS标准。

进一步说明：浏览器开发人员不是唯一落入这个陷阱的人。我安装了NoScript附加组件来停止所有JavaScript，但是允许通过
superuser.com（无点）。但是NoScript仍然阻止superuser.com.（带有点）作为未知网站。
我毫不怀疑测试会在许多其他产品中发现相同的行为。

这很奇怪来自Web领域主要参与者的开发人员，例如Google Chrome，Firefox和Microsoft的Fiddler，
，都对Web标准的许多进步负有责任，却没有注意到这种可能性。