Content-Type requirement and Content Negotiation
azaroth42 opened this issue · comments
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.
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 Accept header in the subscription request, so that the hub would be able to look at that and use the Accept header when deciding what format to deliver the notifications in. This might be a relatively seamless way to allow WebSub to be used on URLs that are content-negotiated.
I like the idea of forwarding the Accept header. However this is also a significant complexity in the sense that that this means the hub has to "remember" the Accept header used upon subscription to ensure that the data sent later to the subscriber is still using the right content-type.
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.
This means in practice that we cannot support content negotiation for websub at this point.
Here's a neat trick publishers can use to support content negotiation with websub: https://gist.github.com/aaronpk/d9c60bcf03b135cf26b3d6bc35a41564
PROPOSED (and accepted resolution): add example of using different rel=self based on Accept header to close + add normative text that shows that the rel=self URL has onl
y a single representation
@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 :)
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