Navigation Menu

Skip to content
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

Closed
gobengo opened this issue Dec 2, 2015 · 9 comments
Closed

Support whole-domain delegation #21

gobengo opened this issue Dec 2, 2015 · 9 comments

Comments

@gobengo
Copy link

gobengo commented Dec 2, 2015

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

@aaronpk
Copy link
Member

aaronpk commented Dec 8, 2015

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 /.well-known/webmention on the same domain. The response to the request MUST be a text/plain response with the full URL of the webmention endpoint as the only content of the body. For example, the request and response might look like the following:

GET /.well-known/webmention HTTP/1.1
Host: example.com

HTTP 200 Ok
Content-type: text/plain

http://example.com/webmention

@gobengo
Copy link
Author

gobengo commented Dec 8, 2015

Nice! I also think that this change would benefit from requiring a ?target (or similar) querystring to specify the target of the webmention. This would make it as useful as webfinger.

The (real-world for me) use case is: Sometimes one origin will serve more than one separately-administered Sites.
e.g.
CNN (politics): http://www.cnn.com/2015/12/07/politics/donald-trump-muslim-travel-ban-rally/index.html
CNN blogs: http://www.cnn.com/exchange/blogs/
CNN ireport: http://www.cnn.com/specials/opinions/cnnireport

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.

@aaronpk
Copy link
Member

aaronpk commented Dec 8, 2015

Interesting. If the sender is going to include the target parameter, then why not also send source, at which point you've just sent the webmention to the /.well-known/webmention path.

@kevinmarks
Copy link
Contributor

The drawback of .well-known as a side file is mitigated by making it last in the resolution order.

@aaronpk
Copy link
Member

aaronpk commented Dec 8, 2015

Another option is advertising the webmention rel in host-meta

@tantek
Copy link
Member

tantek commented Dec 8, 2015

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.

@gobengo
Copy link
Author

gobengo commented Dec 8, 2015

-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.

@aaronpk
Copy link
Member

aaronpk commented Dec 14, 2015

@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 /.well-known/webmention work for them?

@aaronpk
Copy link
Member

aaronpk commented Mar 19, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants