所以你想定义一个众所周知的 URI

嗨，我是马克·诺丁汉。我写的内容涉及 Web、协议设计、HTTP、互联网治理等等。这是个人博客，不代表任何人。了解更多。评论？我们来谈谈乳齿象。 @mnot@techpolicy.social 其他互联网和网络帖子 互联网标准的本质（系列） 没有人应该拥有那么大的权力 2024 年 4 月 29 日星期一 RFC 9518 - 互联网标准可以对集中化做什么？ 2023 年 12 月 19 日，星期二 将控制权移至端点 2019 年 6 月 11 日，星期二 什么是 Web？星期四，2014 年 12 月 4 日 五篇最喜欢的协议设计论文 星期四，2004 年 4 月 15 日 所以你想定义一个众所周知的 URI 星期五，2026 年 6 月 19 日 互联网和网络 作为众所周知的 URI 规范的作者之一和当前的注册表指定专家，我提出了很多关于如何使用它们的问题，并最终指导了很多人如何最好地使用它们。下面，我总结了我对它们的看法。请注意，这些并不是注册的全部要求——只是我认为好的做法。众所周知的 URI 的优点 当客户端（无论是浏览器、机器人还是其他软件）了解站点 1 并且需要以有效的方式发现有关整个站点的信息时，众所周知的 URI 效果最佳。 robots.txt 就是一个完美的例子 - 它早于 RFC，因此它不使用众所周知的 URI，但这是我们为它们保留空间的主要原因。爬虫需要知道站点的访问策略是什么，并将其放在站点的一个中心位置可以避免检查每个响应的标头和内容（这将破坏制定此类策略的许多目的）。不过，知名地点不一定包含政策。任何客户端已经了解该站点但需要了解该站点或与其整体交互的机制都可以成为众所周知的 URI。例如，更改密码众所周知的位置允许客户端更改其站点的密码。当它们是错误的工具时虽然众所周知的位置可以解决某些协议的实际问题，但在其他情况下，设计者似乎正在指定一个众所周知的 URI，因为它似乎是要做的事情。一些提案注册了一个提案，希望它能够赋予合法性，或者促进采用——就好像注册表中的一个位置是一种凭证一样。事实并非如此。众所周知的 URI 可以解决特定问题（客户端知道该站点，并且需要站点范围内的某些内容）；如果你的协议不存在这个问题，那么注册可能只会创建新的协议，而不会带来你所希望的采用。同样，一些针对知名位置的提案正在有效地将它们用作 URL 缩短器。他们不需要在协议中传达完整的 URL，而只需要传达相关站点 - 众所周知的位置填写其余部分。问题在于，这种模式将您锁定在服务和站点之间 1:1 的关系中。如果部署需要多个服务，他们将需要创建一个不同的站点，并找到一种方法将用户引导至适当的站点。如果您的协议确实只能携带主机名，那么使用众所周知的位置是合理的。不过，通常这样做只是为了方便——也许是为了让协议感觉更“官方”——导致部署中不必要的僵化。如果您的协议可以使用真实的 URL，则不必担心众所周知的位置。常见的陷阱和权衡即使知名地点是正确的工具，我们对网站所做的假设也并不总是正确，并且可能会造成严重的复杂性。如果您正在为协议定义众所周知的 URI，则应该注意以下问题。发现机制 许多协议尝试使用众所周知的位置作为发现机制，其理念是“用户已经知道该站点”。问题在于，现实比乍听起来更加模糊——用户当前交互的范围与发现发生的位置之间可能不匹配。例如，如果客户端以“login.example.com”开头，他们应该在该网站还是“example.com”上查找众所周知的 URI？他们应该遵循从一个到另一个的重定向吗？发布者应该在哪些网站上提供众所周知的 URI 以确保互操作性？当协议实际上与网站无关，而只是利用 HTTP 来完成其他任务时，这一点尤其重要。例如，指定可注册域名的众所周知的位置位于顶点可能很诱人，但这对于某些人来说操作起来可能很困难。如果您的协议属于此类，请考虑正在发现的内容以及您的用户从什么开始，然后弄清楚他们如何可靠地找到正确的主机名，而无需过多假设其架构。内容元数据 某些协议尝试使用众所周知的位置作为了解网站内容的方式。毕竟，这就是 /robots.txt 的工作原理。虽然该模式 w