Content Distribution topic clarification

[twitch-jordanpotter]

In section 7, it says:

The subscriber MUST NOT use these Link headers to identify the subscription corresponding to the content distribution request, because the Link headers are metadata associated with the topic content, not with any particular subscription. For example, the topic URL in the content distribution request may be different from the topic URL that was originally subscribed to.

Could we get some clarification on why the topic url might be modified in the content distribution request? Is this implying that we may send payloads for different data than what was requested in the original topic?

[aaronpk]

I believe that was there in order to allow a form of content negotiation, where a subscriber can subscribe to a URL but tell it that it expects e.g. a JSON subscription. However the site being subscribed to may not support actual HTTP content negotiation, so may have a JSON version of a page available at a different URL. This allows the hub to deliver the JSON URL to some subscribers and the HTML URL to others. This is described here: https://www.w3.org/TR/websub/#content-negotiation

Subscribers are expected to use a unique URL per subscription, so they should be using that to identify the subscription from the delivery anyway.

[twitch-jordanpotter]

In example 2, if GET /feed provides the topic /feed.json, then the user would subcribe with topic /feed.json and any future content distribution request would include topic /feed.json. Thus, the topic URL in the content distribution request would match the topic URL that was originally subscribed to 🤔

[ltankey]

We're facing the same questions here -- how would the topic URL originally subscribed to ever really differ?

I know the conversation around light ping vs fat ping has been covered in tickets like #84, but does this wording suggest that for subscriptions for some topic URL /foo, we could send content distribution requests for a topic URL /foo/events, where that sub-resource effectively represents a light-ping?

The bolded sentence in the original post is very ambiguous and confusing, and I can't think of a valid use-case other than the one raised in #84: a publisher has a topic URL (/foo) that they only want to return smaller updates for (/foo/bar).