Giters

w3c / websub

WebSub Spec in Social Web Working Group

Home Page:https://w3c.github.io/websub/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Content distribution: link header meanings

tonyg opened this issue · comments

commented

In the draft of 20 Oct 2016, section 6 says

The request MUST include a Link Header [RFC5988] with rel=hub pointing to the Hub as well as a Link Header [RFC5988] with rel=self set to the topic that's being updated.

I have two questions:

  1. Which hub is to be denoted in the rel=hub link?
    1. The local hub, the one immediately issuing this particular notification
    2. The upstream-most hub, the one advertised by the topic resource itself during discovery
  2. Which resource is to be denoted in the rel=self link?
    1. The topic url as supplied in the subscription request
    2. The rel=self from discovery, if there was one, falling back if not to the topic url supplied in the subscription request

My guess is 1.(i) and 2.(i).

commented

@voxpelli wrote in #43 that my guesses were mistaken: The Link headers are associated with the content, not the subscription, and so may vary as the upstream content's metadata varies.

So I think the right answers must actually be 1.(ii) and 2.(ii).

I think this should be clarified in the spec, since others might fall into the same trap I did of wanting to use the Link headers on the receiving end to identify the subscription.

commented

I am not sure what you call local hub vs. upstream-most hub. The only ones to which subscribers should subscribe are the ones that are designated by the HTTP resources themselves. If the subscriber decides to use another 3rd party, then we're outside if the protocol.

Similarly, if one follows the spec, 2.i and 2.ii are the same URL, because the subscriber needs to subscribe using the rel=self from discovery.

commented

@julien51: My terminology choices were poor. By "local hub" I mean the hub that a subscriber used to establish a subscription; by "upstream-most hub" I mean the hub advertised in a link header coming from the topic itself. Usually, these will be the same URL, at least initially.

For both rel=hub and rel=self, the URLs may be the same initially, but may change: the topic might advertise a new hub and a new canonical topic URL. Because the URLs advertised by a topic may change over time, the question above becomes relevant again.

I think this should be reopened, because I think the spec should make it very clear that the URLs for the hub and the topic that are sent in link headers in content distribution are NOT necessarily the ones that the subscriber subscribed to originally, but ARE the ones most recently retrieved from the topic. Therefore, the link headers MUST NOT be used to identify the subscription. This was not clear to me in the spec.

commented

Usually, these will be the same URL, at least initially.

They should always be the same.

When a publisher wants to change hub, it should of course keep pinging the old hub, but that's out of the spec because the publisher/hub relationship is not in the spec.
The hub will then continue sending notifications to the subscriber as long as the subscription is not expired. When that expiration happens, the subscriber MUST perform discovery again and use the new hub that it'll have found.

I think the spec should make it very clear that the URLs for the hub and the topic that are sent in link headers in content distribution are NOT necessarily the ones that the subscriber subscribed to originally, but ARE the ones most recently retrieved from the topic. Therefore, the link headers MUST NOT be used to identify the subscription. This was not clear to me in the spec.

I agree with this. Do you mind sending a PR about this?