distribution

[Kongaloosh]

A content distribution request is sent from the Hub to the Subscriber when new content is available for a topic URL. The request is an HTTP [RFC7231] (or HTTPS [RFC2818]) POST request from the hub to the subscriber's callback URL. The HTTP body of the POST request MUST include the payload of the content distribution notification. The content distribution request MUST have a Content-Type Header corresponding to the Content-Type of the topic, and MUST contain the full contents of the topic URL, with an exception allowed as described below.

For Atom ([RFC4287]) and RSS ([RSS-2.0]) feeds, the hub MAY remove already-delivered atom:entry or rss:item elements from the feed.

The request MUST include at least one Link Header [RFC5988] with rel=hub pointing to a Hub associated with the topic being updated. It MUST also include one Link Header [RFC5988] with rel=self set to the canonical URL of the topic being updated. The Hub SHOULD combine these headers into a single Link Header [RFC5988]. All these URLs are those resulting from the discovery process (Section 3). 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.

The subscriber's callback URL MUST return an HTTP [RFC7231] 2xx response code to indicate a success. The subscriber's callback URL MAY return an HTTP 410 code to indicate that the subscription has been deleted, and the hub MAY terminate the subscription if it receives that code as a response. The hub MUST consider all other subscriber response codes as failures; that means subscribers MUST NOT use HTTP redirects for moving subscriptions. Subscribers SHOULD respond to content distribution requests as quickly as possible; their success response code SHOULD only indicate receipt of the message, not acknowledgment that it was successfully processed by the subscriber. The response body from the subscriber MUST be ignored by the hub. Hubs SHOULD retry content distribution requests up to self-imposed limits on the number of times and the overall time period to retry. When the failing delivery exceeds the hub's limits, the hub stops attempting to deliver that nofication. The hub MUST keep the subscription active until the end of the lease duration, and if a new update is published to the topic, MUST continue to retry delivery to the previously-failing subscriber.