kongaloosh / hubbub-a-loosh Goto Github PK

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.

The HTTP body of the POST request MUST include the payload of the content distribution notification.

I'm not sure how I'm supposed to include the http body in the payload. Do I just say "body" in the form?

If a hub finds any errors in the subscription request, an appropriate HTTP [RFC7231] error response code (4xx or 5xx) MUST be returned. In the event of an error, hubs SHOULD return a description of the error in the response body as plain text, used to assist the client developer in understanding the error. This is not meant to be shown to the end user. Hubs MAY decide to reject some callback URLs or topic URLs based on their own policies (e.g., domain authorization, topic URL port numbers). However, since verification and validation of intent are asynchronous steps that logically begin after the HTTP response has been returned, the HTTP response MUST NOT depend on the process or outcome of verification or validation.

The callback URL MAY contain arbitrary query string parameters (e.g., ?foo=bar&red=fish). Hubs MUST preserve the query string during subscription verification by appending new parameters to the end of the list using the & (ampersand) character to join. Existing parameters with names that overlap with those used by verification requests will not be overwritten. When sending the content distribution request, the hub will make a POST request to the callback URL including any query string parameters in the URL portion of the request, not as POST body parameters.

Subscriptions MAY be validated by the Hubs who may require more details to accept or refuse a subscription. The Hub MAY also check with the publisher whether the subscription should be accepted.

If (and when) the subscription is accepted, the hub MUST perform the verification of intent of the subscriber.

If (and when) the subscription is denied, the hub MUST inform the subscriber by sending an HTTP [RFC7231] (or HTTPS [RFC2818]) GET request to the subscriber's callback URL as given in the subscription request. This request has the following query string arguments appended (format described in Section 4 of [URL]):

hub.mode
REQUIRED. The literal string "denied".
hub.topic
REQUIRED. The topic URL given in the corresponding subscription request.
hub.reason
OPTIONAL. The hub may include a reason for which the subscription has been denied.
The subscription MAY be denied by the hub at any point (even if it was previously accepted). The Subscriber SHOULD then consider that the subscription is not possible anymore.

The Hub MUST use the exact callback used by the subscriber (including the use of HTTPS). Hubs MUST sign their requests using the hub.secret supplied by subscribers if requested.

If the subscriber included a hub.secret in the subscription request, the subscriber SHOULD validate the hub's provided signature, and if they do so, they MUST use the server's stated signature mechanism, and discard requests which fail the test.

If a subscriber does not use a secure callback URL (HTTPS), or if it is suspected that the TLS transport between the hub and subscriber may be compromised, then the integrity of the content delivery notification is only protected by the hub.secret and the hashing algorithm used. In this case, an appropriate hashing algorithm should be used based on the security requirements of the application. As SHA-1 has been demonstrated to be compromised as of the date of this publication, a minimum of SHA-256 should be used.

Right now, the response to verification request is verification result, which is unnecessary

If the subscriber supplied a value for hub.secret in their subscription request, the hub MUST generate an HMAC signature of the payload and include that signature in the request headers of the content distribution request. The X-Hub-Signature header's value MUST be in the form method=signature where method is one of the recognized algorithm names and signature is the hexadecimal representation of the signature. The signature MUST be computed using the HMAC algorithm [RFC6151] with the request body as the data and the hub.secret as the key.

The gitignore should be ignoring the .DS_Store that macOS introduces

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.