-
Notifications
You must be signed in to change notification settings - Fork 51
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
Content-Type requirement and Content Negotiation #86
Comments
Thanks for forking this off #84 Thinking about this a little more, basically, we can just say the rel=self URL must not be content-negotiated. Basically give the content-location URL as the rel=self URL. So if you want to allow subscriptions to a content-negotiated URL, you need to figure out different URLs for each content type and serve those in the rel=self. What the most compelling use case for con-neg with websub? |
RSS and ATOM? Or some sort of XML / JSON transformation? |
This is an interesting one. I'm curious about the use case, although there is also some precedent in requesting alternate content types by Superfeedr. This part of Superfeedr is outside the PubSubHubbub spec, but it allows you to subscribe to any URL and receive notifications in a chosen content type. https://documentation.superfeedr.com/subscribers.html#webhooks This is accomplished with an additional parameter in the subscription request. The more HTTP-like or content-negotiation-friendly way to do that might be to include an |
I like the idea of forwarding the I may be wrong, but I feel like content negotiation is actually losing in popularity? These days, at least for RSS/Atom feeds, I only know of Feedburner which still supports content negociation. The rest of the world seems to be using a most "REST-ful" approach where each URL has a single resource AND format... feed discovery seems to work better. So, I am leaning toward requiring rel=self urls that do not support content negotiation. |
To be clear, my understanding is saying rel=self url's MUST NOT do con-neg solves this issue, but still leaves implementations perfectly free to do conneg if they want, they just have to negotiate to different urls, as they commonly already do. |
I will add a mention that states that even though we think Content Negotiation is a great mechanism, it may bring confusion because the subscriber has no knowledge (and can't have any) of the headers used by the hub. |
Here's a neat trick publishers can use to support content negotiation with websub: https://gist.github.com/aaronpk/d9c60bcf03b135cf26b3d6bc35a41564 |
|
adding text about content negociation. fixes #86
@azaroth42 We discussed this with the group, and added an example of how to use content negotiation with WebSub. See the comments above for the details. Here is the new section in the spec: https://w3c.github.io/websub/#content-negotiation |
Looks like a good compromise. A short worked example might make it easier to understand, without the background of this thread? |
Do you think the example in this gist is enough to illustrate the idea? https://gist.github.com/aaronpk/d9c60bcf03b135cf26b3d6bc35a41564 |
That's pretty much exactly what I had in mind :) |
including example of content negotiation per the discussion from #86
Thanks @azaroth42, I'm closing the issue now that I've added the example! |
@aaronpk Varying the rel=self link seems to violate the idea that it should be the "canonical" URL. Can I suggest varying the rel=hub link instead? Maybe the spec should mention both options and let a publisher select their preferred one? |
"Satisfied" is a little strong... Commenter withdraws objection for the sake of not getting in the way, but still thinks that Content Negotiation is a fundamental aspect of the web architecture. |
Sorry. I've changed the tag. Did you see the example in the current draft: https://www.w3.org/TR/websub/#content-negotiation |
Section 6 requires the content type of the callback request to be the same as the topic's content type. For resources that support content negotiation, this is impossible as the same topic URL has multiple, equally valid content types.
If the specification requires a single type, then the content-location URL would be required as the Topic URL, requiring the publisher to provide many notifications for each change.
The text was updated successfully, but these errors were encountered: