4

所以我一直在尝试理解WebFinger (RFC7033) 并偶然发现了Web 主机元数据(RFC6415)。据我所知，它们都是 RFC，并且以几乎相同的方式解决相同的问题。

因此，如果我想通过 URI 查找有关人或事物的信息，我可以做两件事：

  • WebFinger 建议我导航到/.well-known/webfinger?resource=...
  • Host-Meta 建议我看看/.well-known/host-meta哪个返回 JRD 或 XRD 之类的东西<link rel="lrdd" template="http://example.com/lrdd?uri={uri}">

Webfinger 只是少了一次查找并鼓励 JRD。为什么我不能只创建一个host-meta看起来像http://example.com/.well-known/webfinger?resource={uri}并做这两件事的模板（尽管是多余的）？

我错过的两者之间有什么重要区别吗？我应该更喜欢一个吗？

4

2 回答 2

4

RFC 7033 的作者在这里。

WebFinger 多年来一直在进行中，并在此期间经历了许多变化。RFC 6415 是标准化 WebFinger 概念的第一次尝试，其中包括主机元和 LRDD。使用 RFC 6415 进行发现的过程很复杂，因为需要执行两个查询，然后合并来自每个查询的信息以创建一组链接关系。此外，一段时间以来，JSON 也有了一些发展。WebFinger 曾使用 XML，但 RFC 6415 附录 A 引入了 JSON 编码。人们希望这是唯一的编码。

与 RFC 6415 的原始作者和 WebFinger 社区中的其他人合作，我们 IETF 中的一组人致力于简化流程，将 JSON 作为内容编码迁移，确保解决方案是安全的（仅限 HTTPS），并获得就用于查询用户帐户信息的 URI 方案达成一致（“acct”URI）。

因此，使用 RFC 7033，我们有一种安全、简单、单查询的发现机制，其工作原理基本上如下：

$ wfinger paulej@packetizer.com

这个“wfinger”客户端会做的是找到域“packetizer.com”，然后发出以下查询（使用 curl 只是为了使示例清晰）：

$ curl https://packetizer.com/.well-known/webfinger?resource=acct%3Apaulej%40packetizer.com

请注意，任何 URI 方案仍然可以与 WebFinger 一起使用——这个概念并没有丢失。因此，正如最初的 WebFinger 所期望的那样，可以查询有关网页（例如 www.packetizer.com）或其他类型内容的信息。这是一个例子：

$ curl https://packetizer.com/.well-known/webfinger?resource=http%3A%2F%2Fwww.packetizer.com

这将返回有关页面“ http://www.packetizer.com ”的链接关系和其他元数据。

于 2015-05-07T22:58:34.590 回答
0

尽管 Webfinger RFC 说/.well-known/webfinger?实际实现使用/.well-known/host-meta

见：http ://hueniverse.com/2009/09/02/implementing-webfinger/

WF似乎已被WHM取代。

于 2015-05-07T13:55:25.323 回答