考虑：
当我在超级用户 URL 后面添加一个点时，https://superuser.com.它表现得好像我尚未登录。为什么会发生这种情况？URL 中的点代表什么？
答案1
在域名末尾添加点会使其成为绝对的完全限定域名，而不仅仅是常规的完全限定域名，并且大多数浏览器将绝对域名视为与等效的常规域名不同的域名（我不确定为什么尽管他们确实这么做了。
一些背景知识：
域名系统是严格分层的，就像文件系统或 X.500/LDAP 目录一样。但与文件系统或 X.500 不同的是，层次结构是从右到左而不是从左到右列出的。因此，域名最右边的组件是层次结构的顶部。在域名的最右边放置一个点会使其成为绝对域名，这意味着它明确植根于 DNS 层次结构的顶部。本质上，这与在 X.500 查找中使用完整的专有名称而不是通用名称，或/在 POSIX 路径的开头放置一个相同。
使用绝对 FQDN 对于客户端系统如何查找该域的 DNS 记录有一些特定的影响：
- 它会导致一些解析器跳过任何本地定义的条目（例如，它会导致一些解析器
/etc/hosts在类 UNIX 系统上忽略）。 - 与域一起使用时
.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 查找（而不是使用操作系统解析器）并因此找出最终的绝对域名可能并不违法，但我发现任何标准都没有要求这样做。
实际差异
正如 Austin 所指出的，不同的含义部分是 DNS 查找如何使用搜索后缀的结果。典型的非根标签（例如example.com）将导致您的典型 DNS 解析器首先尝试系统上定义的任何搜索后缀。在公司环境中，这可能是您的公司域，例如，如果您已将其mycompany.example.定义为搜索后缀，则任何查找example.com都将首先尝试example.com.mycompany.example.。如果您想查找内部服务器而不必键入整个完全限定（“完整”）域，这将非常有用。
但如果你真的想要公开呢？你可以在表单中example.com使用结尾的，以便告诉解析器你输入了绝对（“完整”）名称，并且不要尝试针对搜索充分性进行任何相对查找。.example.com.
互联网标准如何看待这一情况
我们需要从几个地方寻找这些标准是如何标准化的，不幸的是，水可能有点混浊。我通常喜欢先寻找最相关的标准，然后再从那里回过头来，但由于这些标准非常分散，从底层开始可能更容易。
域名
互联网标准RFC1034描述域名第 3.1 节并规定了域名的“首选名称语法”第 3.5 节. 3.1节中的注释：
每个节点都有一个标签，长度为 0 到 63 个八位字节。兄弟节点可能没有相同的标签，尽管非兄弟节点可以使用相同的标签。一个标签被保留，即用于根的空（即零长度）标签。
[...]
当用户需要输入域名时，每个标签的长度将被省略，标签之间用点（“。”）分隔。由于完整的域名以根标签结尾，因此打印形式以点结尾。我们使用此属性来区分：
表示完整域名（通常称为“绝对”）的字符串。例如，“poneria.ISI.EDU”。
表示不完整域名起始标签的字符串，应由本地软件使用本地域的知识（通常称为“相对”）完成。例如，ISI.EDU 域中使用的“poneria”。
相对名称要么相对于众所周知的来源，要么相对于用作搜索列表的域列表。相对名称主要出现在用户界面上，其解释因实现而异，并在主文件中出现，它们相对于单个来源域名。最常见的解释是使用根“。”作为单个来源或搜索列表的成员之一，因此多标签相对名称通常是省略尾随点以节省输入的相对名称。
URI
从这里我们可以了解域名在 URI 中的使用方式，互联网标准RFC3986。 在第3节我们看到了 URI 语法。我们感兴趣的部分是权威，其中包含主持人（后跟可选:端口）。这在第 3.2.2 节，特别是谈论注册名称：
用于在 DNS 中查找的注册名称使用 [RFC1034] 第 3.5 节和 [RFC1123] 第 2.1 节中定义的语法。此类名称由一系列以“.”分隔的域标签组成，每个域标签以字母数字字符开头和结尾，可能还包含“-”字符。DNS 中完全限定域名的最右侧域标签后面可能跟一个“.”，如果需要区分完整域名和某个本地域，则应该这样做。
这又将我们带回到搜索充分性以及“本地域”与“完整域”匹配不同结果的可能性。请记住，根据 RFC1034，从概念上讲，example.com.相当于example.com.<root>，其中<root>是特殊的空标签。
关于规范化的讨论第六节但没有关于主机的任何信息，更不用说尾随的点了。
拟议标准RFC 7230定义了 HTTP/1.1，并指出其 URI 定义在很大程度上遵循了 RFC3986。第2.7节。
TLS
这就是事情变得令人困惑的地方。
信息RFC2818描述了 HTTP over TLS (HTTPS)。除了遵循 RFC2459 中的规则（已被拟议标准取代）外，它没有明确说明主机匹配RFC5280）。这参考了 RFC1034（定义 DNS 的那个），但没有明确说明绝对地址或尾随点。
拟议标准RFC6125是对 TLS 用途的更现代的看法。它更多地讨论了域名匹配，但同样没有明确解决尾随点的问题——尽管它确实说你应该只匹配“完全合格的域名”（这是一个令人惊讶的定义不明确的概念）。它确实说了所有标签必须匹配——这可以追溯到 RFC1034，如果我们认为空标签代表根，那么example.com和example.com.确实有不同的标签（后者有 3、、example和com）<root>。
有一些讨论Mozilla 错误 134402不同的解释。
饼干
稍微远离 TLS，我们可以看看拟议标准中的 cookieRFC6265。 那里，第 5.1.2 节和第 5.1.3 节讨论主机名的规范化和匹配。在这里，我们再次将主机名拆分为单独的标签以执行规范化（本质上将 Unicode 域名转换为 ASCII/punycode 小写）。并且，再次取决于您是否认为通过此规范化步骤保留了表示根的空标签。如果您这样做，那么它们具有不同的标签，因此对于 cookie 而言是不同的主机。
答案3
Mokubai 给出的解释完全正确，问题在于浏览器没有识别出这是同一个域，因此没有发送 cookie。
但情况甚至更糟：末尾的点仅标记该域名为完全合格（无歧义），这与 DNS 配合得很好，因为消息最终确实到达了正确的地址（superuser.com）。
我甚至从 Fiddler 获得了这个对话框superuser.com.（带点）：
经过一些实证测试，以下是随这两个请求发送的标头。
https://superuser.com（敏感信息已划掉）
https://superuser.com.（带点，表示无敏感信息需划掉）
结论：问题在于浏览器没有忽略完全限定域名末尾的点，而根据 DNS 标准，这完全有可能。
进一步说明：陷入此陷阱的并非只有浏览器开发人员。我安装了 NoScript 插件来阻止所有 JavaScript，但
superuser.com允许 (no dot) 通过。但 NoScript 仍将
superuser.com.(with dot) 视为未知网站进行阻止。我毫不怀疑，测试会在许多其他产品中发现同样的行为。
奇怪的是，Web 领域的主要参与者的开发人员，例如 Google Chrome、Firefox 和微软的 Fiddler，都为 Web 标准的许多进步做出了贡献，但他们却没有注意到这种可能性。