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

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

一点背景：

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

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

• 它会导致某些解析器跳过任何本地定义的条目（例如，它会导致某些解析器/etc/hosts在类 UNIX 系统上忽略）。
• 当与.local域一起使用时，它会强制某些系统使用 mDNS 而不是传统的 DNS 来尝试解析名称。
• 它会导致所有解析器在查找名称时忽略任何已配置的搜索域或本地 DNS 域。

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

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

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

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

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

概括

• 在现实世界中，这两个主机实际上可以不同。
• 有时不清楚标准如何看待它们。似乎许多应用程序标准没有明确处理这种情况。
• 在描述域名规范化和比较的那些中，他们通常将名称拆分为单独的“标签”。
• 然后它取决于您是否认为域名的绝对形式具有额外的空标签，如原始 DNS RFC 所述。
• 在理想情况下，所有这些比较都将仅使用绝对域名进行，并且不会使用经过原始查找的相对名称。或者浏览器可以将所有名称作为绝对名称并禁止相对查找。但目前情况似乎并非如此，并且可能会引入其他问题。
  • 虽然浏览器自己执行 DNS 查找（而不是使用操作系统解析器）并因此计算出最终的绝对域名可能不是非法的，但这也不是我能找到的任何标准所要求的。

实际差异

正如 Austin 指出的那样，不同的含义部分是 DNS 查找如何与搜索功能一起工作的结果。您典型的非根标签，例如example.com，将导致您的典型 DNS 解析器首先尝试在您的系统上定义的任何搜索结果。在企业环境中，这可能是您的公司域，例如，如果您已将mycompany.example.其定义为搜索后缀，那么任何查找example.com都将首先尝试example.com.mycompany.example.。如果您想查找内部服务器而不必键入整个完全限定（“完整”）域，这将很有用。

但如果你真的想要公众example.com呢？.您可以在表单中使用尾随的 ,example.com.来告诉解析器您输入了绝对（“完整”）名称，并且不要尝试对搜索结果进行任何相对查找。

互联网标准如何看待这种情况

有几个地方我们需要寻找这些是如何标准化的，不幸的是水域可能有点混乱。我通常喜欢先寻找最相关的标准，然后从那里返回，但由于它太分散了，从底部开始可能更容易。

网站域名

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

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

[...]

当用户需要键入域名时，省略每个标签的长度，并用点（“.”）分隔标签。由于完整的域名以根标签结尾，这导致打印形式以点结尾。我们使用此属性来区分：

• 代表完整域名的字符串（通常称为“绝对”）。例如，“poneria.ISI.EDU”。

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

相对名称要么相对于众所周知的来源，要么相对于用作搜索列表的域列表。相对名称主要出现在用户界面上，它们的解释因实现而异，在主文件中，它们与单一来源域名相关。最常见的解释是使用词根“.”。作为单一来源或作为搜索列表的成员之一，因此多标签相对名称通常是省略尾随点以节省键入的名称。

URIs

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

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

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

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

定义 HTTP/1.1 的拟议标准RFC 7230指出，它在很大程度上遵循 RFC3986 中第 2.7 节中的 URI 定义。

TLS

这就是事情变得混乱的地方。

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

拟议标准RFC6125是对 TLS 使用的更现代的诠释。它更多地讨论了域名匹配，但同样没有明确解决尾随点——尽管它确实说你应该只匹配“完全限定的域名”（这是一个令人惊讶的定义不佳的概念）。它确实说所有标签都必须匹配——这可以追溯到 RFC1034，如果我们认为空标签代表根example.com，那么example.com.确实有不同的标签（后者有 3 example、com和<root>）。

在Mozilla bug 134402中有一些关于不同解释的讨论。

饼干

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

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 标准的许多进步，却没有注意到这种可能性。