2026年6月19日，星期五 互联网和网络 作为知名URI规范的作者之一以及当前注册处的指定专家，我接到许多关于如何使用知名URI的问题，最终也为很多人提供指导，教他们如何最好地使用它们。以下是我对它们的总结。请注意，这些并不是注册的所有要求——只是我认为的良好实践。 何为知名URI的用途 知名URI在客户端（无论是浏览器、机器人或其他软件）了解网站并需要以高效的方式发现整个网站的信息时效果最佳。robots.txt就是一个完美的例子——它比RFC早出现，因此没有使用知名URI，但这是我们为其保留空间的主要原因之一。爬虫需要知道网站的访问政策，将其放置在一个中心位置可以避免在每个响应中检查头信息和内容（这会使得拥有此类政策的许多目的失去意义）。然而，知名位置不一定要包含政策。任何客户端已经知道网站但需要了解或与其整体互动的机制都可以成为知名URI的候选者。例如，变更密码的知名位置允许客户端更改其在某个网站的密码。 何时不适合使用知名URI 尽管知名位置为某些协议解决了实际问题，但在其他情况下，设计者似乎因为觉得应该这样做而指定了知名URI。一些提案注册知名URI，期待它能赋予合法性或促进采用——就好像注册表中的一个位置就是一种凭证。事实上并非如此。知名URI解决的是一个特定问题（客户端知道网站，并需要某种网站范围内的信息）；如果你的协议不存在这个问题，注册可能只会带来新的问题——而不会带来你所希望的采用。同样，一些关于知名位置的提案实际上是把它们当作URL缩短工具使用。它们并不需要在协议中传达完整的URL，只需要传达相关的网站——知名位置填补其余部分。问题在于，这种模式锁定了服务与站点之间的1:1关系。如果一次部署需要多个服务，他们需要创建一个不同的网站，并找到一种方法将用户指向适当的服务。如果你的协议确实只能承载主机名，使用知名位置是合理的。然而，往往这样做只是为了方便——也许是为了让协议感觉更“官方”——导致部署中出现不必要的僵化。如果你的协议可以使用真实的URL，就不必使用知名位置。 常见陷阱和权衡 即使知名位置是合适的工具，我们对网站的假设也并不总是成立，可能会造成重大复杂性。如果你正在为你的协议定义一个知名URI，你应当注意以下问题。 发现机制 许多协议尝试将知名位置用作发现机制，想法是“用户已经知道该网站。”问题是现实比一开始听起来要模糊——用户当前的互动范围与发现发生的地方之间可能存在不匹配。例如，如果客户端从“login.example.com”开始，他们应该在该网站上查找知名URI，还是在“example.com”上查找？他们是否应该从一个重定向到另一个？发布者应该在哪个网站上提供可用的知名URI以确保互操作性？这在协议实际上并不是关于网站，而是仅仅利用HTTP完成其他事情的情况下尤为重要。例如，指定可注册域名的知名位置位于域顶可能会在操作上对某些人来说比较困难。如果你的协议属于这一类，考虑一下正在发现的内容以及用户从哪里开始，然后找出他们如何可靠地找到正确的主机名，而无需对他们的架构做出过多假设。 内容元数据 一些协议试图将知名位置用作了解网站内容的方式。毕竟，这就是/robots.txt的工作原理。虽然这种模式适用于某些类型的元数据，但许多网站表示多个出版者（例如，旧的/~username/约定）。将内容元数据放在一个中心位置，要么使该机制无法访问这些用户，要么要求管理员开发复杂的基础设施来支持和监督他们的控制。这种类型的部署体现了便利性与细粒度之间的权衡，通常需要创建一个平行的元数据机制——例如在HTTP响应头中或在内容本身中——以及不同的元数据附加机制的合理化。这并不是说知名URI没有其存在的价值。