New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support whole-domain delegation #21
Comments
Thanks for providing real-world justification for this use case. I'm considering adding the following as a fourth discovery step as you suggested. If no webmention endpoint is found after searching the three previously mentioned locations, the sender MUST make a GET request to the .well-known webmention path
|
Nice! I also think that this change would benefit from requiring a The (real-world for me) use case is: Sometimes one origin will serve more than one separately-administered Sites. If the Enterprise operating the origin is sufficiently complex, it can take years for each sub-site to adopt or migrate to new technology. With the above proposed change, an Enterprise with many subsections (and a legacy tech stack/team/politics) making it difficult to alter the response body/headers could vary the well-known webmention response according to the ?target parameter. |
Interesting. If the sender is going to include the |
The drawback of .well-known as a side file is mitigated by making it last in the resolution order. |
Another option is advertising the webmention rel in host-meta |
I just remembered that we did resolve on preferring follow-your-nose (i.e. link relations) back in the March f2f: https://www.w3.org/wiki/Socialwg/2015-03-18-minutes#resolution04 "RESOLVED the WG will prefer follow-your-nose architecture in the API candidates we consider " And both fixed-path and host-meta style approaches (e.g. webfinger) were considered at the time and rejected explicitly in the minutes. Unless there is compelling new information, I'd prefer to stick with the resolution. And if/when new information is brought forth in the future, this issue can be reopened then. Propose closing, no support. |
-1 for closing with no support. I think having this as last in the discovery chain is compatible with that resolution ('prefer follow your nose') and this is an important use case. @aaronpk just sending the webmention there is tempting. But my experience with this use case is such that the delegation is really useful when the server cannot easily process/store/retry the webmention message and wants to say "Go send it to this endpoint I'm paying to have a high SLA". If it COULD receive the webmention, it could delegate to itself. |
@gobengo that makes sense. It looks like host-meta is the "standard" way of doing something like this, since it's already used to advertise PubSubHubbub values. My hesitation around this is that the host-meta spec is primarily an XML format, but also supports a JSON format, and I don't want to require webmention senders deal with both of those cases. I would much rather provide exactly one way to advertise and find the webmention endpoint for a host. Do you have a sense of how many of the types of customers you're talking about have deployed an XML vs JSON host-meta file? Would a specific path like |
Whole-domain delegation can be achieved by adding an HTTP Link header at the server level. This allows an organization to configure their web server to delegate the whole domain regardless of how many apps are running in subfolders. The assumption is that if you have write access to create a new folder at the root of the domain, you are probably in a position to add the Link header as well. A previous resolution of the group was to only use follow-your-nose methods of discovery. After further discussion at the March F2F meeting, we determined we do not have enough new information to warrant adding a .well-known discovery method that does not follow-your-nose. More notes from the minutes here: https://www.w3.org/wiki/Socialwg/2016-03-16-minutes#Webmention_open_issues |
link: https://hypothes.is/a/yHecWAE6SOewee7LbZheEg
Add a fourth discovery layer of whole-domain delegation via .well-known.
http://indiewebcamp.com/irc/2015-11-29#t1448856141695
(this could also just be documenting how to use webfinger for this)
This lets one domain delegate all its webmentioning to another provider without having to adjust server code to add new response headers or HTML
The text was updated successfully, but these errors were encountered: