Should tolerate host-meta without <hm:Host/> for Webfinger addresses
Should tolerate host-meta without <hm:Host/> for Webfinger addresses
| Issue ID: | 3235 |
| Issue Category: | compatibility |
| Component: | ostatus |
| Priority: | normal |
| Status: | active |
| Assigned: | Unassigned |
| Version: | 0.9 |
| Keywords: | .well-known, hm:Host, host-meta, ostatus, well-known |
In 0.9.7fix1, if the host specified by hostname in .well-known/host-meta/ file on a remote service does not match the hostname part of the Webfinger address, the address is rejected. For example, user@host.com is not accepted if host.com's host-meta at URL http://host.com/.well-known/host-meta/ specifies example.com.
This is all well, except in case where is not specified.
Wordpress plugin set for OStatus (including plugins for adding support for Webfinger, host-meta, etc) currently does NOT specify , and it was almost certainly designed with Status.net in mind.
I will also report to the Wordpress plugin's author that should be specified.

Updates
#1
Ugh. Bug report was frakked up, and any instance of [hm:Host/], [hm:Host] and [/hm:Host] (with less-than and greater-than symbols) is not displayed.
-- Re-post for readability:
In 0.9.7fix1, if the host specified by [hm:Host]hostname[/hm:Host] in .well-known/host-meta/ file on a remote service does not match the hostname part of the Webfinger address, the address is rejected. For example, user@host.com is not accepted if host.com's host-meta at URL http://host.com/.well-known/host-meta/ specifies [hm:Host]example.com[/hm:Host].
This is all well, except in case where the [hm:Host/] stanza is not specified.
One example of an incompatible service is the set of plugins for Wordpress for OStatus (including plugins for adding support for Webfinger, host-meta, etc). It currently does NOT specify [hm:Host/], and it was almost certainly designed with Status.net in mind.
I will also report to the Wordpress plugin's author that [hm:Host/] should be specified.
#2
[hm:Host/] should be optional, because it is no longer part of the latest host-meta draft: http://tools.ietf.org/html/draft-hammer-hostmeta-16
You can also subscribe to the
RSS feed for updates to this issue.