为什么网址后面加点号会去掉登录信息？

Question

考虑：

当我在超级用户 URL 后面加一个点时https://superuser.com.，它就像我没有登录一样。为什么会发生这种情况？URL 中的点代表什么？

Answer 1

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

一点背景：

域名系统是严格分层的，就像文件系统或 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，因此大多数人不知道它们。

Answer 2

这是因为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”。

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

URI

从那里我们可以了解域名在 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描述了 HTTP over TLS (HTTPS)。除了遵循 RFC2459 中的规则（由 Proposed Standard RFC5280替换）之外，它没有明确说明主机匹配。这可以追溯到 RFC1034（定义 DNS 的那个），但没有明确说明绝对地址或尾随点。

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

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

饼干

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

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