From a8374507caa9c4e9279c30181b1983be1184c52a Mon Sep 17 00:00:00 2001
From: julien
Date: Sun, 5 Feb 2012 23:10:09 +0100
Subject: [PATCH 01/76] spec 0.4 as seen by Julien
---
pubsubhubbub-core.xml | 575 +++++++++---------------------------------
1 file changed, 122 insertions(+), 453 deletions(-)
diff --git a/pubsubhubbub-core.xml b/pubsubhubbub-core.xml
index 0d27bb7..410835d 100644
--- a/pubsubhubbub-core.xml
+++ b/pubsubhubbub-core.xml
@@ -28,7 +28,7 @@
- PubSubHubbub Core 0.3 -- Working Draft
+ PubSubHubbub Core 0.4 -- Working DraftGoogle, Inc
@@ -53,14 +53,20 @@
mart@degeneration.co.uk
+
+
+ Notifixious Inc.
-
+
+ julien@superfeedr.com
+
+
+
+
- An open, simple, web-scale pubsub protocol, along with an open source
- reference implentation targetting Google App Engine. Notably, however,
- nothing in the protocol is centralized, or Google- or App
- Engine-specific. Anybody can play.
+ An open, simple, web-scale and decentralized pubsub protocol.
+ Anybody can play.As opposed to more developed (and more complex) pubsub specs like Jabber Publish-Subscribe this spec's base profile
@@ -93,25 +99,17 @@
- An Atom or RSS feed URL. The
- unit to which one can subscribe to changes. This spec currently only
- addresses feed URLs that require no additional authorization
- headers.
+ An HTTP resource URL. The
+ unit to which one can subscribe to changes. The server (URL) which implements both sides of this
- protocol. We have implemented this and are running a server at
- http://pubsubhubbub.appspot.com that is, at least for now, open
- to anybody for use, as either a publisher or subscriber. Any hub MAY
- implement its own policies on who can use it.
+ protocol. Any hub MAY implement its own policies on who can use it.An owner of a topic. Notifies the hub when
- the topic feed has been updated. It just notifies that it has been updated, but not how. As in almost all
- pubsub systems, the publisher is unaware of the subscribers, if any.
- Other pubsub systems might call the publisher the "source".
+ the topic feed has been updated. As in almost all pubsub systems, the
+ publisher is unaware of the subscribers, if any. Other pubsub systems
+ might call the publisher the "source".An entity (person or program) that wants
to be notified of changes on a topic. The subscriber must be
@@ -136,17 +134,9 @@
sending out notifications to subscribers.A payload describing how a topic's
- contents have changed. This difference (or "delta") is computed by the
- hub and sent to all subscribers. The format of the notification will
- be an Atom or RSS feed served by the publisher with only those entries
- present which are new or have changed. The notification can be the
- result of a publisher telling the hub of an update, or the hub
- proactively polling a topic feed, perhaps for a subscriber subscribing
- to a topic that's not pubsub-aware. Note also that a notification to a
- subscriber can be a payload consisting of updates for multiple topics.
- Hubs MAY choose to send multi-topic notifications as an optimization
- for heavy subscribers, but subscribers MUST understand them. See for format details.
+ contents have changed, or the full cupdated content.
+ Depending on the topic's content type, the difference (or "delta") may be
+ computed by the hub and sent to all subscribers.
@@ -154,7 +144,7 @@
(This section is non-normative.)
- Publishers POST a ping to their hub(s) URLs when their topic(s)
+ Publishers notify their hub(s) URLs when their topic(s)
change.Subscribers POST to one or more of the advertised hubs for a
@@ -168,133 +158,38 @@
delta, it enqueues a notification to all registered subscribers.
-
-
- Notification and source formats will be Atom or RSS. The
- Publisher makes the decision as to include full body, truncated body, or
- meta data of most recent event(s). One of:
-
-
- URL + metadata
-
- URL + metadata + truncated
-
- URL + metadata + full
-
-
- The trade-off between including all content in outgoing notifications
- or having the thundering herd (by clients who fetch the //atom:feed/entry/link in response to a notification)
- is up to the publisher. Entries of the most recent events (for recipient
- to know whether or not they'd missed any recent items-- like TCP SACK) MAY
- be provided as context. Some examples of Atom feed entries follow.
-
-
-
-
-
-
-
-
- 2008-08-11T02:15:01Z
-
-
-
- Heathcliff
-
- http://publisher.example.com/happycat25.xml
- 2008-08-11T02:15:01Z
-
- What a happy cat. Full content goes here.
-
-
-
-
-
- Heathcliff
-
- http://publisher.example.com/happycat25.xml
- 2008-08-11T02:15:01Z
-
- What a happy cat!
-
-
-
-
-
- Garfield
-
- http://publisher.example.com/happycat25.xml
- 2008-08-11T02:15:01Z
-
-
-
-
- Nermal
-
- http://publisher.example.com/happycat25.xml
- 2008-07-10T12:28:13Z
-
-
-
-]]>
-
-
- A potential subscriber initiates discovery by retrieving the feed to
- which it wants to subscribe. A feed that acts as a topic as per this
- specification MUST publish, as a child of //atom:feed or //rss:rss/channel , an atom:link element whose rel attribute has the value hub and whose href
- attribute contains the hub's endpoint URL. Feeds MAY contain multiple
- atom:link[@rel="hub"] elements if the
- publisher wishes to notify multiple hubs. When a potential subscriber
- encounters one or more such links, that subscriber MAY subscribe to the
- feed using one or more hubs URLs as described in .
+ A potential subscriber initiates discovery by retrieving the topic to
+ which it wants to subscribe. The HTTP response from the publisher MUST
+ include at least one X-Hub-Url
+ HTTP header, as well as exactly one X-Hub-Self-Url
+ HTTP header. The X-Hub-Url MUST
+ indicate the exact url of the PubSubHubbub hub designated by the publisher.
+ If more than one url is specified, it is expected that the publisher pings each
+ of these urls, so the subscriber may subscribe to one or more of these.
+ The X-Hub-Self-Url will point to the
+ permanent URL for the resource being polled.Example:
-
-
-
-
-
-
- ....
-
- ....
-
-
- ....
-
-
-]]>
-
- Hubs MUST use the same URL for both the publishing and subscribing
- interfaces, which is why only a single atom:link
- element is required to declare a hub. Publishers SHOULD use HTTPS in their hubs' discovery URLs. However,
- subscribers that do not support HTTPS MAY
+ Hubs should provide an HTTPS interface and publishers
+ SHOULD use HTTPS in their hubs' discovery URLs.
+ However, subscribers that do not support HTTPS MAY
try to fallback to HTTP, which MAY work
- depending on the hub's policy.
+ depending on the hub's policy. If the advertised url is HTTP,
+ subscriber MAY choose to try HTTPS first.
- Subscribing to a topic URL consists of three parts that may occur
+ Subscribing to a topic URL consists of four parts that may occur
immediately in sequence or have a delay.Requesting a subscription using the hubConfirming the subscription was actually desired
+ Receiving an acknowledgement from the hub that the subscription was accepted (OPTIONAL).Periodically reconfirming the subscription is still active
@@ -302,15 +197,17 @@
changed to indicate the desire to unsubscribe.
- Subscription is initiated by the subscriber making an HTTP POST request to the hub URL. This request
+ Subscription is initiated by the subscriber making an HTTPS
+ or HTTP POST request to the hub URL. This request
has a Content-Type of application/x-www-form-urlencoded (described in
Section 17.13.4 of ) and the
following parameters in its body:
- REQUIRED. The subscriber's callback URL where notifications should be delivered.
+ REQUIRED. The subscriber's callback URL
+ where notifications should be delivered. The subscriber's
+ callback URL SHOULD be unique for each subscription.REQUIRED. The literal string "subscribe" or
"unsubscribe", depending on the goal of the request.
@@ -318,10 +215,6 @@
REQUIRED. The topic URL that the subscriber
wishes to subscribe to.
- REQUIRED. Keyword describing verification
- modes supported by this subscriber, as described below. This
- parameter may be repeated to indicate multiple supported modes.
-
OPTIONAL. Number of seconds for
which the subscriber would like to have the subscription active. If
not present or an empty value, the subscription will be permanent
@@ -339,32 +232,8 @@
the request was made over HTTPS. This
parameter MUST be less than 200 bytes in length.
- OPTIONAL. A subscriber-provided
- opaque token that will be echoed back in the verification request to
- assist the subscriber in identifying which subscription request is
- being verified. If this is not included, no token will be included
- in the verification request.
-
-
-
- The following keywords are supported for hub.verify:
-
-
- The subscriber supports synchronous
- verification, where the verification request must occur before the
- subscription request's HTTP response is returned.
-
- The subscriber supports asynchronous
- verification, where the verification request may occur at a later
- point after the subscription request has returned.
- Where repeated keywords are used, their order indicates the
- subscriber's order of preference. Subscribers MUST use at least one of
- the modes indicated in the list above, but MAY include additional
- keywords defined by extension specifications. Hubs MUST ignore verify
- mode keywords that they do not understand.
-
Hubs MUST ignore additional request parameters they do not
understand.
@@ -379,14 +248,14 @@
- The topic and callback URLs MUST NOT contain an anchor fragment.
- These URLs MAY use HTTP or HTTPS schemes. These URLs MAY have port
- numbers specified; however, hubs MAY choose to disallow certain ports
- based on their own policies (e.g., security) and return errors for
- these requests. The topic URL can otherwise be free-form following
- the URI spec. Hubs MUST always decode
- non-reserved characters for these URL parameters; see section 2.4 on
+ The topic and callback URLs MAY use HTTP
+ or HTTPS schemes. The topic URL MUST
+ be the one advertised by the publisher in the X-Hub-Self-Url
+ Header during the discovery phase. (See ).
+ Hubs MAY refuse subscriptions if the topic url does not correspond to the one
+ advertised by the publisher. The topic URL can otherwise be free-form
+ following the URI spec. Hubs MUST always
+ decode non-reserved characters for these URL parameters; see section 2.4 on
"When to Encode or Decode" in the URI spec.
@@ -403,35 +272,24 @@
Subscribers MAY choose to use HTTPS
for their callback URLs if they care about the privacy of
- notifications as they come over the wire from the Hub. The use of
- mechanisms (such as XML signatures) to verify the integrity of
- notifications coming from the original publisher is out of the scope
- of this specification.
+ notifications as they come over the wire from the Hub (see )
-
- The hub MUST respond to a subscription request with an HTTP 204 "No
- Content" response to indicate that the request was verified and that
- the subscription is active. If the subscription has yet to be verified
- (i.e., the hub is using asynchronous verification), the hub MUST
- respond with a 202 "Accepted" code.
-
+
+ The hub MUST respond to a subscription request with an HTTP 202 "Accepted"
+ response to indicate that the request was received and will now
+ be verified () and validated () by the hub. The hub SHOULD perform the
+ verification of intent as soon as possible.
+
If a hub finds any errors in the subscription request, an
appropriate HTTP 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. Hubs MAY decide to reject some
callback URLs or topic URLs based on their own policies (e.g., domain
authorization, topic URL port numbers).
-
- In synchronous mode, the verification () MUST be completed before the hub returns a
- response. In asynchronous mode, the verification MAY be deferred until
- a later time. This is useful to enable hubs to defer work; this could
- allow them to alleviate servers under heavy load or do verification
- work in batches.
-
@@ -467,43 +325,24 @@
present for unsubscribe requests and MUST be ignored by subscribers
during unsubscription.
- OPTIONAL. The subscriber-provided
- opaque token from the corresponding subscription request, if one was
- provided.
-
The subscriber MUST confirm that the hub.topic
- and hub.verify_token correspond
- to a pending subscription or unsubscription that it wishes to carry
- out. If so, the subscriber MUST respond with an HTTP success (2xx)
- code with a response body equal to the correspond to a pending subscription or unsubscription that it
+ wishes to carry out. If so, the subscriber MUST respond with an HTTP
+ success (2xx) code with a response body equal to the hub.challenge parameter. If the subscriber does
not agree with the action, the subscriber MUST respond with a 404 "Not
Found" response.
- For synchronous verification, the hub MUST consider other server
- response codes (3xx, 4xx, 5xx) to mean that the verification request
- has immediately failed and no retries should occur. If the subscriber
+ The hub MUST consider other server response codes (3xx, 4xx, 5xx)
+ to mean that the verification request has failed. If the subscriber
returns an HTTP success (2xx) but the content body does not match the
hub.challenge parameter, the hub MUST also
consider verification to have failed.
-
- For asynchronous verification, the hub MUST consider other server
- response codes (3xx, 4xx, and 5xx) to mean that the subscription
- action was temporarily not verified. If
- the subscriber returns an HTTP success (2xx) but the content body does
- not match the hub.challenge parameter, the
- hub MUST consider this to be a temporary
- failure and retry. The hub SHOULD retry verification a reasonable
- number of times over the course of a longer time period (e.g., 6
- hours) until a definite acknowledgement (positive or negative) is
- received. If a definite response still cannot be determined after this
- retry period, the subscription action verification MUST be abandoned,
- leaving the previous subscription state.
-
+
Hubs MAY make the hub.lease_seconds
equal to the period the subscriber passed in their subscription
request but MAY change the value depending on the hub's policies. To
@@ -516,7 +355,42 @@
target="autorefresh">automatic subscription refreshing.
-
+
+
+ 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 has been accepted,
+ the hub MUST indicate it to the subscriber by performing a notification
+ of the current state of the resource to the subscriber (see ).
+ (this is optional in synchronous mode). The subscriber will use this has
+ an indication that its subscription has been confirmed.
+
+ Additionally, this notification MUST include a X-Hub-Self-Url
+ HTTP header which indicates to the subscriber to what feed he has been subscribed.
+ This feed url MAY be different from the feed for which the subscriber has initially subscribed,
+ as the publisher MAY have considered that this one was better suited for the subscriber.
+ (This is specifically useful in the context of private content with limited distribution.)
+
+ If (and when), the subscription is denied, the hub will inform the subscriber
+ by sending an HTTP 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 17.13.4 of
+ ):
+
+ REQUIRED. The literal string "denied".
+ REQUIRED. The topic URL given in the corresponding
+ subscription request.
+ OPTIONAL. The hub may include a reason
+ for which the subscription has been denied.
+
+
+ The subscription may be intentionally 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.
+
+
@@ -527,8 +401,8 @@
by sending the subscriber a verification
request with hub.mode equal to
subscribe. This request MUST match the original verification request
- sent to the subscriber (but with a new hub.challenge).
+ sent to the subscriber (but with a new hub.challenge
+ ).
The response codes returned by the subscriber MUST be interpreted the
same way as during a subscriber-initiated verification flow. However,
@@ -556,107 +430,21 @@
The publisher MUST inform the hub it previously designated when a topic
has been updated. The hub and the publisher CAN agree on any mechanism, as
long as the hub is eventually able send the updated payload to the
- subscribers. The following sub-sections ( and
- ) illustrate a default mechanism that SHOULD be implemented when by
- Hub and the Publisher.
-
-
- When new content is added to a feed, a notification is sent to
- the hub by the publisher. The hub MUST accept a POST request to
- the hub URL containing the notification. This request MUST have a
- Content-Type of application/x-www-form-urlencoded
- (described in Section 17.13.4 of ) and the following parameters in
- its body:
-
-
- REQUIRED. The literal string "publish".
-
- REQUIRED. The topic URL of the topic that
- has been updated. This field may be repeated to indicate multiple
- topics that have been updated.
-
-
- The new content notification is a signal to the hub that there is new
- content available. The hub SHOULD arrange for a content fetch request
- () to be performed in the near future
- to retrieve the new content. If the notification was acceptable, the hub
- MUST return a 204 No Content response. If the notification is not
- acceptable for some reason, the hub MUST return an appropriate HTTP
- error response code (4xx and 5xx). Hubs MUST return a 204 No Content
- response even when they do not have any subscribers for all of the
- specified topic URLs.
-
-
-
- When the hub wishes to retrieve new content for a topic, the hub
- sends an HTTP GET request to the topic
- URL. The hub MUST follow HTTP redirects. The Hub SHOULD use best
- practices for caching headers in its requests (e.g., If-None-Match, If-Modified-Since).
-
- The request SHOULD include the header field User-Agent in the form expected by HTTP. The header MAY have one or more additional
- suffixes like (example.com; 20 subscribers)
- to indicate the number of subscriptions the hub has active for this
- topic.
-
- If present, the first suffix MUST indicate the total number of
- subscriptions the hub has aggregated across all subscriber domains by
- means of the X-Hub-On-Behalf-Of header
- (). Any additional suffixes
- indicate a breakdown of subscriber counts across subscriber domains.
- This allows content publishers to distinguish the source of their
- subscriber counts and mitigate subscriber count spam. An example header
- could be (ignoring line-wrapping):
-
-
-
-User-Agent: MyHub (+http://hub.example.com; 26 subscribers)
- (sub.example.com; 4 subscribers)
- (other-sub.example.com; 22 subscribers)
-
-
-
- If, after a content fetch, the hub determines that the topic feed
- content has changed, the hub MUST send information about the changes to
- each of the subscribers to the topic (). Hubs MUST consider new feed
- entries, updated entries, or changes to the surrounding feed document as
- significant content changes that require content distribution.
-
-
+ subscribers.
+ A content distribution request is an HTTP POST request from hub to the subscriber's
- callback URL with the list of new and changed entries. This request MUST
- have a Content-Type of application/atom+xml when the request body is an
- Atom feed document, or a Content-Type of application/rss+xml when the request body is an
- RSS feed document. The behavior for other
- content types is not yet defined. Hubs MAY transform the content type
- and request body as desired (e.g., for language translation).
-
- If the document represents a single feed being replicated for the
- subscriber, then the feed-level elements SHOULD be preserved aside from
- the atom:entry or rss:item elements. However, the atom:id element MUST be reproduced exactly. The
- other atom:updated and atom:title elements required by the Atom
- specification SHOULD be present. Each atom:entry or rss:item
- element in the feed contains the content from an entry in the single
- topic that the subscriber has an active subscription for. Essentially,
- in the single feed case the subscriber will receive a feed document
- that looks like the original but with old content removed.
+ callback URL with the payload of the notification. This request MUST
+ have a Content-Type corresponding to the
+ type of the topic. The hub MAY reduce the payload to a diff if its format
+ allows it.
+
+ The POST request must include a X-Hub-Self-Url
+ and a X-Hub-Url HTTP headers that correspond
+ to topic's url, as well as hub.The successful response from the subscriber's callback URL MUST be an
HTTP success (2xx) code. The hub MUST consider all other subscriber
@@ -669,17 +457,6 @@ User-Agent: MyHub (+http://hub.example.com; 26 subscribers)
receipt of the message, not acknowledgment that it was successfully
processed by the subscriber.
- The subscriber's callback response MAY include the header field
- X-Hub-On-Behalf-Of with an integer value,
- possibly approximate, representing the number of subscribers on behalf
- of which this feed notification was delivered. This value SHOULD be
- aggregated by the hub across all subscribers and used to provide the
- subscriber counts in the User-Agent header
- field sent to publishers (). Hubs MAY
- ignore or respect X-Hub-On-Behalf-Of values
- from subscribers depending on their own policies (i.e., to prevent
- spam).
-
@@ -702,125 +479,17 @@ User-Agent: MyHub (+http://hub.example.com; 26 subscribers)
same method as the hub. If the signature does not match, subscribers
MUST still return a 2xx success response to acknowledge receipt, but
locally ignore the message as invalid. Using this technique along with
- HTTPS for subscription requests enables simple subscribers to receive
- authenticated content delivery from hubs without the need for
- subscribers to run an HTTPS server.
-
-
+ HTTPS for subscription requests enables
+ simple subscribers to receive authenticated content delivery from hubs
+ without the need for subscribers to run an HTTPS server.
+
+ Please note however that this signature only ensures that the payload
+ was not forged. Since the notification also includes headers, these should
+ not be considered as safe by the subscriber, unless of course the subscriber
+ uses HTTPS callbacks.
-
-
- For Atom feeds only. Pending further review.
-
- When a subscriber indicates the same callback URL is used for
- multiple subscriptions, hubs MAY choose to combine content delivery
- requests into a single payload containing an aggregated set of feeds.
- This bulk delivery results in fewer requests and more efficient
- distribution. If the subscriber indicated a hub.secret value for these overlapping
- subscriptions, the secret MUST also be the same for all subscriptions.
- This allows the hub to generate a single X-Hub-Signature header to sign the entire payload.
- Hubs MUST return an error response (4xx, 5xx) for subscription
- requests with overlapping callback URLs and different secret values.
-
-
- With an aggregated set of feeds, the hub SHOULD reproduce all of the
- elements from the source feed inside the
- corresponding atom:entry in the content
- distribution request by using an atom:source
- element. However, the atom:id value MUST be
- reproduced exactly within the source element. If the source entry does
- not have an atom:source element, the hub
- MUST create an atom:source element
- containing the atom:id element. The hub
- SHOULD also include the atom:title element
- and an atom:link element with rel="self" values that are functionally
- equivalent to the corresponding elements in the original topic feed.
-
- Example aggregated feed:
-
-
-
-
- Aggregated feed
- 2008-08-11T02:17:44Z
- http://myhub.example.com/aggregated?1232427842-39823
-
-
-
- http://www.example.com/foo
-
-
- Mr. Bar
-
-
- Testing Foo
-
- http://publisher.example.com/foo24.xml
- 2008-08-11T02:15:01Z
-
- This is some content from the user named foo.
-
-
-
-
-
- http://www.example.com/bar
-
-
- Mr. Bar
-
-
- Testing Bar
-
- http://publisher.example.com/bar18.xml
- 2008-08-11T02:17:44Z
-
- Some data from the user named bar.
-
-
-
-
-]]>
-
-
-
-
-
-
- (This section is non-normative.)
-
- The vast majority of feeds on the web have multiple variants that contain essentially the same content
- but appear on different URLs. A common set of variants is http://example.com/feed?format=atom and http://example.com/feed?format=rss. In practice,
- these URLs also fail to set their //atom:feed/link[@rel="self"] values properly,
- meaning it's difficult for subscribers to discover which feed URL they
- truly wanted. Making matters worse, feeds often have redirects
- (temporary or permanent) to new hosting locations, analytics providers,
- or other feed-processors. To solve this, it's important for Hub
- implementations to determine feed URL equivalences using heuristics.
- Examples: follow all feed URLs redirects and see if they end up at the
- same location; use overlaps in feed HTML alternate links; use the atom:id value across all domains. This specific
- problem is considered out of scope of this specification but this
- section is meant as a reminder to implementors that feed URL aliasing is
- an important issue that hubs should address instead of putting
- the burden on publishers and subscribers.
-
- The hub.verify_token parameter in
- subscription requests enables subscribers to verify the identity and
- intent of the hub making the verification request. Subscribers should
- use the token to retrieve internal state to ensure the subscription
- request outcome is what they intended.
-
From 049463165696e0497194dc194aa67bfe09cd6fc1 Mon Sep 17 00:00:00 2001
From: julien
Date: Sun, 5 Feb 2012 23:11:52 +0100
Subject: [PATCH 02/76] usiing the 0.4.xml
---
pubsubhubbub-core-0.4.xml | 706 ++++++++++++++++++++++++++++++++++++++
pubsubhubbub-core.xml | 578 ++++++++++++++++++++++++-------
2 files changed, 1159 insertions(+), 125 deletions(-)
create mode 100644 pubsubhubbub-core-0.4.xml
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
new file mode 100644
index 0000000..410835d
--- /dev/null
+++ b/pubsubhubbub-core-0.4.xml
@@ -0,0 +1,706 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ PubSubHubbub Core 0.4 -- Working Draft
+
+
+ Google, Inc
+
+
+ brad@danga.com
+
+
+
+
+ Google, Inc
+
+
+ bslatkin@gmail.com
+
+
+
+
+ Six Apart Ltd.
+
+
+ mart@degeneration.co.uk
+
+
+
+
+ Notifixious Inc.
+
+
+ julien@superfeedr.com
+
+
+
+
+
+
+ An open, simple, web-scale and decentralized pubsub protocol.
+ Anybody can play.
+
+ As opposed to more developed (and more complex) pubsub specs like Jabber Publish-Subscribe this spec's base profile
+ (the barrier-to-entry to speak it) is dead simple. The fancy bits required
+ for high-volume publishers and subscribers are optional. The base profile
+ is HTTP-based, as opposed to XMPP (see more on this below).
+
+ To dramatically simplify this spec in several places where we had to
+ choose between supporting A or B, we took it upon ourselves to say "only
+ A", rather than making it an implementation decision.
+
+ We offer this spec in hopes that it fills a need or at least advances
+ the state of the discussion in the pubsub space. Polling sucks. We think
+ a decentralized pubsub layer is a fundamental, missing layer in the
+ Internet architecture today and its existence, more than just enabling
+ the obvious lower latency feed readers, would enable many cool
+ applications, most of which we can't even imagine. But we're looking
+ forward to decentralized social networking.
+
+
+
+
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in . Domain name examples use .
+
+
+
+
+ An HTTP resource URL. The
+ unit to which one can subscribe to changes.
+
+ The server (URL) which implements both sides of this
+ protocol. Any hub MAY implement its own policies on who can use it.
+
+ An owner of a topic. Notifies the hub when
+ the topic feed has been updated. As in almost all pubsub systems, the
+ publisher is unaware of the subscribers, if any. Other pubsub systems
+ might call the publisher the "source".
+
+ An entity (person or program) that wants
+ to be notified of changes on a topic. The subscriber must be
+ directly network-accessible and is identified by its Subscriber
+ Callback URL.
+
+ A unique relation to a topic by a
+ subscriber that indicates it should receive updates for that topic. A
+ subscription's unique key is the tuple (Topic URL, Subscriber Callback
+ URL). Subscriptions may (at the hub's decision) have expiration times
+ akin to DHCP leases which must be periodically renewed.
+
+ The URL at which a subscriber wishes to receive
+ notifications.
+
+ An event that causes updates to multiple topics.
+ For each event that happens (e.g. "Brad posted to the Linux
+ Community."), multiple topics could be affected (e.g. "Brad posted."
+ and "Linux community has new post"). Publisher events cause topics to
+ be updated and the hub looks up all subscriptions for affected topics,
+ sending out notifications to subscribers.
+
+ A payload describing how a topic's
+ contents have changed, or the full cupdated content.
+ Depending on the topic's content type, the difference (or "delta") may be
+ computed by the hub and sent to all subscribers.
+
+
+
+
+ (This section is non-normative.)
+
+
+ Publishers notify their hub(s) URLs when their topic(s)
+ change.
+
+ Subscribers POST to one or more of the advertised hubs for a
+ topic they're interested in. Alternatively, some hubs may offer
+ auto-polling capability, to let {their,any} subscribers subscribe to
+ topics which don't advertise a hub.
+
+ The hub caches minimal metadata (id, data, entry digest) about
+ each topic's previous state. When the hub re-fetches a topic feed (on
+ its own initiative or as a result of a publisher's ping) and finds a
+ delta, it enqueues a notification to all registered subscribers.
+
+
+
+
+
+ A potential subscriber initiates discovery by retrieving the topic to
+ which it wants to subscribe. The HTTP response from the publisher MUST
+ include at least one X-Hub-Url
+ HTTP header, as well as exactly one X-Hub-Self-Url
+ HTTP header. The X-Hub-Url MUST
+ indicate the exact url of the PubSubHubbub hub designated by the publisher.
+ If more than one url is specified, it is expected that the publisher pings each
+ of these urls, so the subscriber may subscribe to one or more of these.
+ The X-Hub-Self-Url will point to the
+ permanent URL for the resource being polled.
+
+ Example:
+
+ Hubs should provide an HTTPS interface and publishers
+ SHOULD use HTTPS in their hubs' discovery URLs.
+ However, subscribers that do not support HTTPS MAY
+ try to fallback to HTTP, which MAY work
+ depending on the hub's policy. If the advertised url is HTTP,
+ subscriber MAY choose to try HTTPS first.
+
+
+
+
+ Subscribing to a topic URL consists of four parts that may occur
+ immediately in sequence or have a delay.
+
+ Requesting a subscription using the hub
+ Confirming the subscription was actually desired
+ Receiving an acknowledgement from the hub that the subscription was accepted (OPTIONAL).
+ Periodically reconfirming the subscription is still active
+
+
+ Unsubscribing works in the same way, except with a single parameter
+ changed to indicate the desire to unsubscribe.
+
+
+ Subscription is initiated by the subscriber making an HTTPS
+ or HTTP POST request to the hub URL. This request
+ has a Content-Type of application/x-www-form-urlencoded (described in
+ Section 17.13.4 of ) and the
+ following parameters in its body:
+
+
+ REQUIRED. The subscriber's callback URL
+ where notifications should be delivered. The subscriber's
+ callback URL SHOULD be unique for each subscription.
+
+ REQUIRED. The literal string "subscribe" or
+ "unsubscribe", depending on the goal of the request.
+
+ REQUIRED. The topic URL that the subscriber
+ wishes to subscribe to.
+
+ OPTIONAL. Number of seconds for
+ which the subscriber would like to have the subscription active. If
+ not present or an empty value, the subscription will be permanent
+ (or active until automatic
+ refreshing removes the subscription). Hubs MAY choose to
+ respect this value or not, depending on their own policies. This
+ parameter MAY be present for unsubscription requests and MUST be
+ ignored by the hub in that case.
+
+ OPTIONAL. A subscriber-provided secret
+ string that will be used to compute an HMAC digest for authorized content distribution. If not
+ supplied, the HMAC digest will not be present for content
+ distribution requests. This parameter SHOULD only be specified when
+ the request was made over HTTPS. This
+ parameter MUST be less than 200 bytes in length.
+
+
+
+ Hubs MUST ignore additional request parameters they do not
+ understand.
+
+ Hubs MUST allow subscribers to re-request subscriptions that are
+ already activate. Each subsequent request to a hub to subscribe or
+ unsubscribe MUST override the previous subscription state for a
+ specific topic URL and callback URL combination once the action is
+ verified. Any failures to confirm the subscription action MUST leave
+ the subscription state unchanged. This is required so subscribers can
+ renew their subscriptions before the lease seconds period is over
+ without any interruption.
+
+
+
+ The topic and callback URLs MAY use HTTP
+ or HTTPS schemes. The topic URL MUST
+ be the one advertised by the publisher in the X-Hub-Self-Url
+ Header during the discovery phase. (See ).
+ Hubs MAY refuse subscriptions if the topic url does not correspond to the one
+ advertised by the publisher. The topic URL can otherwise be free-form
+ following the URI spec. Hubs MUST always
+ decode non-reserved characters for these URL parameters; see section 2.4 on
+ "When to Encode or Decode" in the URI spec.
+
+ 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; Hubs MUST only append verification
+ parameters to the existing list, if any. For event notification, the
+ callback URL will be POSTed to including any query-string parameters
+ in the URL portion of the request, not as POST body parameters.
+
+ Subscribers MAY choose to use HTTPS
+ for their callback URLs if they care about the privacy of
+ notifications as they come over the wire from the Hub (see )
+
+
+
+
+
+ The hub MUST respond to a subscription request with an HTTP 202 "Accepted"
+ response to indicate that the request was received and will now
+ be verified () and validated () by the hub. The hub SHOULD perform the
+ verification of intent as soon as possible.
+
+ If a hub finds any errors in the subscription request, an
+ appropriate HTTP 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. Hubs MAY decide to reject some
+ callback URLs or topic URLs based on their own policies (e.g., domain
+ authorization, topic URL port numbers).
+
+
+
+
+
+ In order to prevent an attacker from creating unwanted subscriptions
+ on behalf of a subscriber (or unsubscribing desired ones), a hub must
+ ensure that the subscriber did indeed send the subscription request.
+
+ The hub verifies a subscription request by sending an HTTP 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 17.13.4 of
+ ):
+
+
+ REQUIRED. The literal string "subscribe" or
+ "unsubscribe", which matches the original request to the hub from
+ the subscriber.
+
+ REQUIRED. The topic URL given in the
+ corresponding subscription request.
+
+ REQUIRED. A hub-generated, random string
+ that MUST be echoed by the subscriber to verify the
+ subscription.
+
+ REQUIRED/OPTIONAL. The
+ hub-determined number of seconds that the subscription will stay
+ active before expiring, measured from the time the verification
+ request was made from the hub to the subscriber. Hubs MUST supply
+ this parameter for subscription requests. This parameter MAY be
+ present for unsubscribe requests and MUST be ignored by subscribers
+ during unsubscription.
+
+
+
+
+
+ The subscriber MUST confirm that the hub.topic
+ correspond to a pending subscription or unsubscription that it
+ wishes to carry out. If so, the subscriber MUST respond with an HTTP
+ success (2xx) code with a response body equal to the hub.challenge parameter. If the subscriber does
+ not agree with the action, the subscriber MUST respond with a 404 "Not
+ Found" response.
+
+ The hub MUST consider other server response codes (3xx, 4xx, 5xx)
+ to mean that the verification request has failed. If the subscriber
+ returns an HTTP success (2xx) but the content body does not match the
+ hub.challenge parameter, the hub MUST also
+ consider verification to have failed.
+
+ Hubs MAY make the hub.lease_seconds
+ equal to the period the subscriber passed in their subscription
+ request but MAY change the value depending on the hub's policies. To
+ sustain a temporary subscription, the subscriber MUST re-request the
+ subscription on the hub before hub.lease_seconds seconds has elapsed. For
+ permanent subscriptions with no hub.lease_seconds value specified, the behavior
+ is different as described in the section on automatic subscription refreshing.
+
+
+
+
+ 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 has been accepted,
+ the hub MUST indicate it to the subscriber by performing a notification
+ of the current state of the resource to the subscriber (see ).
+ (this is optional in synchronous mode). The subscriber will use this has
+ an indication that its subscription has been confirmed.
+
+ Additionally, this notification MUST include a X-Hub-Self-Url
+ HTTP header which indicates to the subscriber to what feed he has been subscribed.
+ This feed url MAY be different from the feed for which the subscriber has initially subscribed,
+ as the publisher MAY have considered that this one was better suited for the subscriber.
+ (This is specifically useful in the context of private content with limited distribution.)
+
+ If (and when), the subscription is denied, the hub will inform the subscriber
+ by sending an HTTP 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 17.13.4 of
+ ):
+
+ REQUIRED. The literal string "denied".
+ REQUIRED. The topic URL given in the corresponding
+ subscription request.
+ OPTIONAL. The hub may include a reason
+ for which the subscription has been denied.
+
+
+ The subscription may be intentionally 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.
+
+
+
+
+
+
+ Before a subscription expires (i.e., before hub.lease_seconds elapses), Hubs MUST recheck with
+ subscribers to see if a continued subscription is desired. Hubs do this
+ by sending the subscriber a verification
+ request with hub.mode equal to
+ subscribe. This request MUST match the original verification request
+ sent to the subscriber (but with a new hub.challenge
+ ).
+
+ The response codes returned by the subscriber MUST be interpreted the
+ same way as during a subscriber-initiated verification flow. However,
+ this refresh request MUST behave like an initial subscription request;
+ this means that if an auto-refresh response from the subscriber
+ constantly returns an error, the hub MUST give up on the subscription
+ verification action altogether and remove the subscription.
+
+ In the case of permanent subscriptions (with no hub.lease_seconds specified in the original
+ request), the hub.lease_seconds value
+ supplied by the hub in the verification request to the subscriber SHOULD
+ represent how many seconds until the hub expects it will next initiate
+ automatic subscription refreshing to ensure that the subscriber is still
+ interested in the topic. This behavior provides the best of both worlds:
+ maximum simplicity of the subscriber through infinitely-long
+ subscriptions, but still garbage collectable subscriptions for hub
+ hygiene.
+
+
+
+
+
+
+ The publisher MUST inform the hub it previously designated when a topic
+ has been updated. The hub and the publisher CAN agree on any mechanism, as
+ long as the hub is eventually able send the updated payload to the
+ subscribers.
+
+
+
+
+ A content distribution request is an HTTP POST request from hub to the subscriber's
+ callback URL with the payload of the notification. This request MUST
+ have a Content-Type corresponding to the
+ type of the topic. The hub MAY reduce the payload to a diff if its format
+ allows it.
+
+ The POST request must include a X-Hub-Self-Url
+ and a X-Hub-Url HTTP headers that correspond
+ to topic's url, as well as hub.
+
+ The successful response from the subscriber's callback URL MUST be an
+ HTTP success (2xx) code. The hub MUST consider all other subscriber
+ response codes as failures; that means subscribers MUST not use HTTP
+ redirects for moving subscriptions. The response body from the
+ subscriber MUST be ignored by the hub. Hubs SHOULD retry notifications
+ repeatedly until successful (up to some reasonable maximum over a
+ reasonable time period). Subscribers SHOULD respond to notifications 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.
+
+
+
+
+
+ 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 sha1=signature where signature is a 40-byte, hexadecimal representation
+ of a SHA1 signature. The signature MUST be
+ computed using the HMAC algorithm with the
+ request body as the data and the hub.secret
+ as the key.
+
+ When subscribers receive a content distribution request with the
+ X-Hub-Signature header specified, they
+ SHOULD recompute the SHA1 signature with the shared secret using the
+ same method as the hub. If the signature does not match, subscribers
+ MUST still return a 2xx success response to acknowledge receipt, but
+ locally ignore the message as invalid. Using this technique along with
+ HTTPS for subscription requests enables
+ simple subscribers to receive authenticated content delivery from hubs
+ without the need for subscribers to run an HTTPS server.
+
+ Please note however that this signature only ensures that the payload
+ was not forged. Since the notification also includes headers, these should
+ not be considered as safe by the subscriber, unless of course the subscriber
+ uses HTTPS callbacks.
+
+
+
+
+
+
+
+
+
+
+
+ HMAC: Keyed-Hashing for Message Authentication
+
+ IBM, T.J. Watson Research Center
+
+
+ University of California at San Diego, Dept of Computer Science and Engineering
+
+
+ IBM T.J. Watson Research Center
+
+
+
+
+
+
+
+ Reserved Top Level DNS Names
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Key words for use in RFCs to Indicate Requirement
+ Levels
+
+
+ Alis Technologies
+
+
+
+
+
+
+
+
+ Hypertext Transfer Protocol -- HTTP/1.1
+
+
+ UC Irvine
+
+
+
+ Compaq/W3C
+
+
+
+ Compaq
+
+
+
+ W3C/MIT
+
+
+
+ Xerox
+
+
+
+ Microsoft
+
+
+
+ W3C/MIT
+
+
+
+
+
+
+
+
+ HTTP Over TLS
+
+
+
+
+ This memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet. This memo provides information for the Internet community.
+
+
+
+
+
+
+
+ US Secure Hash Algorithm 1 (SHA1)
+
+
+
+
+
+
+ The purpose of this document is to make the SHA-1 (Secure Hash Algorithm 1) hash algorithm conveniently available to the Internet community. This memo provides information for the Internet community.
+
+
+
+
+
+
+
+
+ Uniform Resource Identifiers (URI): Generic Syntax
+
+
+
+
+
+
+
+
+
+
+
+ The Atom Syndication Format
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ HTML 4.01 Specification
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Publish-Subscribe
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ RSS 2.0
+
+
+
+
+
+
+
+
+
+
+ Feedback on this specification is welcomed via the
+ pubsubhubbub mailing list, pubsubhubbub@googlegroups.com. For
+ more information, see the
+ PubSubHubbub group on Google Groups. Also, check out the
+ FAQ
+ and other
+ documentation.
+
+
+
+
+
diff --git a/pubsubhubbub-core.xml b/pubsubhubbub-core.xml
index 410835d..d30554e 100644
--- a/pubsubhubbub-core.xml
+++ b/pubsubhubbub-core.xml
@@ -28,7 +28,7 @@
- PubSubHubbub Core 0.4 -- Working Draft
+ PubSubHubbub Core 0.3 -- Working DraftGoogle, Inc
@@ -53,20 +53,14 @@
mart@degeneration.co.uk
-
-
- Notifixious Inc.
-
- julien@superfeedr.com
-
-
-
-
+
- An open, simple, web-scale and decentralized pubsub protocol.
- Anybody can play.
+ An open, simple, web-scale pubsub protocol, along with an open source
+ reference implentation targetting Google App Engine. Notably, however,
+ nothing in the protocol is centralized, or Google- or App
+ Engine-specific. Anybody can play.As opposed to more developed (and more complex) pubsub specs like Jabber Publish-Subscribe this spec's base profile
@@ -99,17 +93,25 @@
- An HTTP resource URL. The
- unit to which one can subscribe to changes.
+ An Atom or RSS feed URL. The
+ unit to which one can subscribe to changes. This spec currently only
+ addresses feed URLs that require no additional authorization
+ headers.The server (URL) which implements both sides of this
- protocol. Any hub MAY implement its own policies on who can use it.
+ protocol. We have implemented this and are running a server at
+ http://pubsubhubbub.appspot.com that is, at least for now, open
+ to anybody for use, as either a publisher or subscriber. Any hub MAY
+ implement its own policies on who can use it.An owner of a topic. Notifies the hub when
- the topic feed has been updated. As in almost all pubsub systems, the
- publisher is unaware of the subscribers, if any. Other pubsub systems
- might call the publisher the "source".
+ the topic feed has been updated. It just notifies that it has been updated, but not how. As in almost all
+ pubsub systems, the publisher is unaware of the subscribers, if any.
+ Other pubsub systems might call the publisher the "source".An entity (person or program) that wants
to be notified of changes on a topic. The subscriber must be
@@ -134,9 +136,17 @@
sending out notifications to subscribers.A payload describing how a topic's
- contents have changed, or the full cupdated content.
- Depending on the topic's content type, the difference (or "delta") may be
- computed by the hub and sent to all subscribers.
+ contents have changed. This difference (or "delta") is computed by the
+ hub and sent to all subscribers. The format of the notification will
+ be an Atom or RSS feed served by the publisher with only those entries
+ present which are new or have changed. The notification can be the
+ result of a publisher telling the hub of an update, or the hub
+ proactively polling a topic feed, perhaps for a subscriber subscribing
+ to a topic that's not pubsub-aware. Note also that a notification to a
+ subscriber can be a payload consisting of updates for multiple topics.
+ Hubs MAY choose to send multi-topic notifications as an optimization
+ for heavy subscribers, but subscribers MUST understand them. See for format details.
@@ -144,7 +154,7 @@
(This section is non-normative.)
- Publishers notify their hub(s) URLs when their topic(s)
+ Publishers POST a ping to their hub(s) URLs when their topic(s)
change.Subscribers POST to one or more of the advertised hubs for a
@@ -158,38 +168,133 @@
delta, it enqueues a notification to all registered subscribers.
+
+
+ Notification and source formats will be Atom or RSS. The
+ Publisher makes the decision as to include full body, truncated body, or
+ meta data of most recent event(s). One of:
+
+
+ URL + metadata
+
+ URL + metadata + truncated
+
+ URL + metadata + full
+
+
+ The trade-off between including all content in outgoing notifications
+ or having the thundering herd (by clients who fetch the //atom:feed/entry/link in response to a notification)
+ is up to the publisher. Entries of the most recent events (for recipient
+ to know whether or not they'd missed any recent items-- like TCP SACK) MAY
+ be provided as context. Some examples of Atom feed entries follow.
+
+
+
+
+
+
+
+
+ 2008-08-11T02:15:01Z
+
+
+
+ Heathcliff
+
+ http://publisher.example.com/happycat25.xml
+ 2008-08-11T02:15:01Z
+
+ What a happy cat. Full content goes here.
+
+
+
+
+
+ Heathcliff
+
+ http://publisher.example.com/happycat25.xml
+ 2008-08-11T02:15:01Z
+
+ What a happy cat!
+
+
+
+
+
+ Garfield
+
+ http://publisher.example.com/happycat25.xml
+ 2008-08-11T02:15:01Z
+
+
+
+
+ Nermal
+
+ http://publisher.example.com/happycat25.xml
+ 2008-07-10T12:28:13Z
+
+
+
+]]>
+
+
- A potential subscriber initiates discovery by retrieving the topic to
- which it wants to subscribe. The HTTP response from the publisher MUST
- include at least one X-Hub-Url
- HTTP header, as well as exactly one X-Hub-Self-Url
- HTTP header. The X-Hub-Url MUST
- indicate the exact url of the PubSubHubbub hub designated by the publisher.
- If more than one url is specified, it is expected that the publisher pings each
- of these urls, so the subscriber may subscribe to one or more of these.
- The X-Hub-Self-Url will point to the
- permanent URL for the resource being polled.
+ A potential subscriber initiates discovery by retrieving the feed to
+ which it wants to subscribe. A feed that acts as a topic as per this
+ specification MUST publish, as a child of //atom:feed or //rss:rss/channel , an atom:link element whose rel attribute has the value hub and whose href
+ attribute contains the hub's endpoint URL. Feeds MAY contain multiple
+ atom:link[@rel="hub"] elements if the
+ publisher wishes to notify multiple hubs. When a potential subscriber
+ encounters one or more such links, that subscriber MAY subscribe to the
+ feed using one or more hubs URLs as described in .Example:
- Hubs should provide an HTTPS interface and publishers
- SHOULD use HTTPS in their hubs' discovery URLs.
- However, subscribers that do not support HTTPS MAY
+
+
+
+
+
+
+ ....
+
+ ....
+
+
+ ....
+
+
+]]>
+
+ Hubs MUST use the same URL for both the publishing and subscribing
+ interfaces, which is why only a single atom:link
+ element is required to declare a hub. Publishers SHOULD use HTTPS in their hubs' discovery URLs. However,
+ subscribers that do not support HTTPS MAY
try to fallback to HTTP, which MAY work
- depending on the hub's policy. If the advertised url is HTTP,
- subscriber MAY choose to try HTTPS first.
+ depending on the hub's policy.
- Subscribing to a topic URL consists of four parts that may occur
+ Subscribing to a topic URL consists of three parts that may occur
immediately in sequence or have a delay.Requesting a subscription using the hubConfirming the subscription was actually desired
- Receiving an acknowledgement from the hub that the subscription was accepted (OPTIONAL).Periodically reconfirming the subscription is still active
@@ -197,17 +302,15 @@
changed to indicate the desire to unsubscribe.
- Subscription is initiated by the subscriber making an HTTPS
- or HTTP POST request to the hub URL. This request
+ Subscription is initiated by the subscriber making an HTTP POST request to the hub URL. This request
has a Content-Type of application/x-www-form-urlencoded (described in
Section 17.13.4 of ) and the
following parameters in its body:
- REQUIRED. The subscriber's callback URL
- where notifications should be delivered. The subscriber's
- callback URL SHOULD be unique for each subscription.
+ REQUIRED. The subscriber's callback URL where notifications should be delivered.REQUIRED. The literal string "subscribe" or
"unsubscribe", depending on the goal of the request.
@@ -215,6 +318,10 @@
REQUIRED. The topic URL that the subscriber
wishes to subscribe to.
+ REQUIRED. Keyword describing verification
+ modes supported by this subscriber, as described below. This
+ parameter may be repeated to indicate multiple supported modes.
+
OPTIONAL. Number of seconds for
which the subscriber would like to have the subscription active. If
not present or an empty value, the subscription will be permanent
@@ -232,8 +339,32 @@
the request was made over HTTPS. This
parameter MUST be less than 200 bytes in length.
+ OPTIONAL. A subscriber-provided
+ opaque token that will be echoed back in the verification request to
+ assist the subscriber in identifying which subscription request is
+ being verified. If this is not included, no token will be included
+ in the verification request.
+
+
+
+ The following keywords are supported for hub.verify:
+
+
+ The subscriber supports synchronous
+ verification, where the verification request must occur before the
+ subscription request's HTTP response is returned.
+
+ The subscriber supports asynchronous
+ verification, where the verification request may occur at a later
+ point after the subscription request has returned.
+ Where repeated keywords are used, their order indicates the
+ subscriber's order of preference. Subscribers MUST use at least one of
+ the modes indicated in the list above, but MAY include additional
+ keywords defined by extension specifications. Hubs MUST ignore verify
+ mode keywords that they do not understand.
+
Hubs MUST ignore additional request parameters they do not
understand.
@@ -248,14 +379,14 @@
- The topic and callback URLs MAY use HTTP
- or HTTPS schemes. The topic URL MUST
- be the one advertised by the publisher in the X-Hub-Self-Url
- Header during the discovery phase. (See ).
- Hubs MAY refuse subscriptions if the topic url does not correspond to the one
- advertised by the publisher. The topic URL can otherwise be free-form
- following the URI spec. Hubs MUST always
- decode non-reserved characters for these URL parameters; see section 2.4 on
+ The topic and callback URLs MUST NOT contain an anchor fragment.
+ These URLs MAY use HTTP or HTTPS schemes. These URLs MAY have port
+ numbers specified; however, hubs MAY choose to disallow certain ports
+ based on their own policies (e.g., security) and return errors for
+ these requests. The topic URL can otherwise be free-form following
+ the URI spec. Hubs MUST always decode
+ non-reserved characters for these URL parameters; see section 2.4 on
"When to Encode or Decode" in the URI spec.
@@ -272,24 +403,35 @@
Subscribers MAY choose to use HTTPS
for their callback URLs if they care about the privacy of
- notifications as they come over the wire from the Hub (see )
+ notifications as they come over the wire from the Hub. The use of
+ mechanisms (such as XML signatures) to verify the integrity of
+ notifications coming from the original publisher is out of the scope
+ of this specification.
-
- The hub MUST respond to a subscription request with an HTTP 202 "Accepted"
- response to indicate that the request was received and will now
- be verified () and validated () by the hub. The hub SHOULD perform the
- verification of intent as soon as possible.
-
+
+ The hub MUST respond to a subscription request with an HTTP 204 "No
+ Content" response to indicate that the request was verified and that
+ the subscription is active. If the subscription has yet to be verified
+ (i.e., the hub is using asynchronous verification), the hub MUST
+ respond with a 202 "Accepted" code.
+
If a hub finds any errors in the subscription request, an
appropriate HTTP 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. Hubs MAY decide to reject some
callback URLs or topic URLs based on their own policies (e.g., domain
authorization, topic URL port numbers).
+
+ In synchronous mode, the verification () MUST be completed before the hub returns a
+ response. In asynchronous mode, the verification MAY be deferred until
+ a later time. This is useful to enable hubs to defer work; this could
+ allow them to alleviate servers under heavy load or do verification
+ work in batches.
+
@@ -325,24 +467,43 @@
present for unsubscribe requests and MUST be ignored by subscribers
during unsubscription.
+ OPTIONAL. The subscriber-provided
+ opaque token from the corresponding subscription request, if one was
+ provided.
+
The subscriber MUST confirm that the hub.topic
- correspond to a pending subscription or unsubscription that it
- wishes to carry out. If so, the subscriber MUST respond with an HTTP
- success (2xx) code with a response body equal to the and hub.verify_token correspond
+ to a pending subscription or unsubscription that it wishes to carry
+ out. If so, the subscriber MUST respond with an HTTP success (2xx)
+ code with a response body equal to the hub.challenge parameter. If the subscriber does
not agree with the action, the subscriber MUST respond with a 404 "Not
Found" response.
- The hub MUST consider other server response codes (3xx, 4xx, 5xx)
- to mean that the verification request has failed. If the subscriber
+ For synchronous verification, the hub MUST consider other server
+ response codes (3xx, 4xx, 5xx) to mean that the verification request
+ has immediately failed and no retries should occur. If the subscriber
returns an HTTP success (2xx) but the content body does not match the
hub.challenge parameter, the hub MUST also
consider verification to have failed.
-
+
+ For asynchronous verification, the hub MUST consider other server
+ response codes (3xx, 4xx, and 5xx) to mean that the subscription
+ action was temporarily not verified. If
+ the subscriber returns an HTTP success (2xx) but the content body does
+ not match the hub.challenge parameter, the
+ hub MUST consider this to be a temporary
+ failure and retry. The hub SHOULD retry verification a reasonable
+ number of times over the course of a longer time period (e.g., 6
+ hours) until a definite acknowledgement (positive or negative) is
+ received. If a definite response still cannot be determined after this
+ retry period, the subscription action verification MUST be abandoned,
+ leaving the previous subscription state.
+
Hubs MAY make the hub.lease_seconds
equal to the period the subscriber passed in their subscription
request but MAY change the value depending on the hub's policies. To
@@ -355,42 +516,7 @@
target="autorefresh">automatic subscription refreshing.
-
-
- 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 has been accepted,
- the hub MUST indicate it to the subscriber by performing a notification
- of the current state of the resource to the subscriber (see ).
- (this is optional in synchronous mode). The subscriber will use this has
- an indication that its subscription has been confirmed.
-
- Additionally, this notification MUST include a X-Hub-Self-Url
- HTTP header which indicates to the subscriber to what feed he has been subscribed.
- This feed url MAY be different from the feed for which the subscriber has initially subscribed,
- as the publisher MAY have considered that this one was better suited for the subscriber.
- (This is specifically useful in the context of private content with limited distribution.)
-
- If (and when), the subscription is denied, the hub will inform the subscriber
- by sending an HTTP 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 17.13.4 of
- ):
-
- REQUIRED. The literal string "denied".
- REQUIRED. The topic URL given in the corresponding
- subscription request.
- OPTIONAL. The hub may include a reason
- for which the subscription has been denied.
-
-
- The subscription may be intentionally 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.
-
-
+
@@ -401,8 +527,8 @@
by sending the subscriber a verification
request with hub.mode equal to
subscribe. This request MUST match the original verification request
- sent to the subscriber (but with a new hub.challenge
- ).
+ sent to the subscriber (but with a new hub.challenge).
The response codes returned by the subscriber MUST be interpreted the
same way as during a subscriber-initiated verification flow. However,
@@ -427,24 +553,107 @@
- The publisher MUST inform the hub it previously designated when a topic
- has been updated. The hub and the publisher CAN agree on any mechanism, as
- long as the hub is eventually able send the updated payload to the
- subscribers.
-
+ A publisher pings the hub with the topic URL(s) which have been updated
+ and the hub schedules those topics to be fetched and delivered. Because
+ it's just a ping to notify the hub of the topic URL (without a payload),
+ no authentication from the publisher is required.
+
+
+ When new content is added to a feed, a notification is sent to
+ the hub by the publisher. The hub MUST accept a POST request to
+ the hub URL containing the notification. This request MUST have a
+ Content-Type of application/x-www-form-urlencoded
+ (described in Section 17.13.4 of ) and the following parameters in
+ its body:
+
+
+ REQUIRED. The literal string "publish".
+
+ REQUIRED. The topic URL of the topic that
+ has been updated. This field may be repeated to indicate multiple
+ topics that have been updated.
+
+
+ The new content notification is a signal to the hub that there is new
+ content available. The hub SHOULD arrange for a content fetch request
+ () to be performed in the near future
+ to retrieve the new content. If the notification was acceptable, the hub
+ MUST return a 204 No Content response. If the notification is not
+ acceptable for some reason, the hub MUST return an appropriate HTTP
+ error response code (4xx and 5xx). Hubs MUST return a 204 No Content
+ response even when they do not have any subscribers for all of the
+ specified topic URLs.
+
+
+
+ When the hub wishes to retrieve new content for a topic, the hub
+ sends an HTTP GET request to the topic
+ URL. The hub MUST follow HTTP redirects. The Hub SHOULD use best
+ practices for caching headers in its requests (e.g., If-None-Match, If-Modified-Since).
+
+ The request SHOULD include the header field User-Agent in the form expected by HTTP. The header MAY have one or more additional
+ suffixes like (example.com; 20 subscribers)
+ to indicate the number of subscriptions the hub has active for this
+ topic.
+
+ If present, the first suffix MUST indicate the total number of
+ subscriptions the hub has aggregated across all subscriber domains by
+ means of the X-Hub-On-Behalf-Of header
+ (). Any additional suffixes
+ indicate a breakdown of subscriber counts across subscriber domains.
+ This allows content publishers to distinguish the source of their
+ subscriber counts and mitigate subscriber count spam. An example header
+ could be (ignoring line-wrapping):
+
+
+
+User-Agent: MyHub (+http://hub.example.com; 26 subscribers)
+ (sub.example.com; 4 subscribers)
+ (other-sub.example.com; 22 subscribers)
+
+
+
+ If, after a content fetch, the hub determines that the topic feed
+ content has changed, the hub MUST send information about the changes to
+ each of the subscribers to the topic (). Hubs MUST consider new feed
+ entries, updated entries, or changes to the surrounding feed document as
+ significant content changes that require content distribution.
+
+ A content distribution request is an HTTP POST request from hub to the subscriber's
- callback URL with the payload of the notification. This request MUST
- have a Content-Type corresponding to the
- type of the topic. The hub MAY reduce the payload to a diff if its format
- allows it.
-
- The POST request must include a X-Hub-Self-Url
- and a X-Hub-Url HTTP headers that correspond
- to topic's url, as well as hub.
+ callback URL with the list of new and changed entries. This request MUST
+ have a Content-Type of application/atom+xml when the request body is an
+ Atom feed document, or a Content-Type of application/rss+xml when the request body is an
+ RSS feed document. The behavior for other
+ content types is not yet defined. Hubs MAY transform the content type
+ and request body as desired (e.g., for language translation).
+
+ If the document represents a single feed being replicated for the
+ subscriber, then the feed-level elements SHOULD be preserved aside from
+ the atom:entry or rss:item elements. However, the atom:id element MUST be reproduced exactly. The
+ other atom:updated and atom:title elements required by the Atom
+ specification SHOULD be present. Each atom:entry or rss:item
+ element in the feed contains the content from an entry in the single
+ topic that the subscriber has an active subscription for. Essentially,
+ in the single feed case the subscriber will receive a feed document
+ that looks like the original but with old content removed.The successful response from the subscriber's callback URL MUST be an
HTTP success (2xx) code. The hub MUST consider all other subscriber
@@ -457,6 +666,17 @@
receipt of the message, not acknowledgment that it was successfully
processed by the subscriber.
+ The subscriber's callback response MAY include the header field
+ X-Hub-On-Behalf-Of with an integer value,
+ possibly approximate, representing the number of subscribers on behalf
+ of which this feed notification was delivered. This value SHOULD be
+ aggregated by the hub across all subscribers and used to provide the
+ subscriber counts in the User-Agent header
+ field sent to publishers (). Hubs MAY
+ ignore or respect X-Hub-On-Behalf-Of values
+ from subscribers depending on their own policies (i.e., to prevent
+ spam).
+
@@ -479,17 +699,125 @@
same method as the hub. If the signature does not match, subscribers
MUST still return a 2xx success response to acknowledge receipt, but
locally ignore the message as invalid. Using this technique along with
- HTTPS for subscription requests enables
- simple subscribers to receive authenticated content delivery from hubs
- without the need for subscribers to run an HTTPS server.
-
- Please note however that this signature only ensures that the payload
- was not forged. Since the notification also includes headers, these should
- not be considered as safe by the subscriber, unless of course the subscriber
- uses HTTPS callbacks.
+ HTTPS for subscription requests enables simple subscribers to receive
+ authenticated content delivery from hubs without the need for
+ subscribers to run an HTTPS server.
+
+
+
+
+ For Atom feeds only. Pending further review.
+
+ When a subscriber indicates the same callback URL is used for
+ multiple subscriptions, hubs MAY choose to combine content delivery
+ requests into a single payload containing an aggregated set of feeds.
+ This bulk delivery results in fewer requests and more efficient
+ distribution. If the subscriber indicated a hub.secret value for these overlapping
+ subscriptions, the secret MUST also be the same for all subscriptions.
+ This allows the hub to generate a single X-Hub-Signature header to sign the entire payload.
+ Hubs MUST return an error response (4xx, 5xx) for subscription
+ requests with overlapping callback URLs and different secret values.
+
+
+ With an aggregated set of feeds, the hub SHOULD reproduce all of the
+ elements from the source feed inside the
+ corresponding atom:entry in the content
+ distribution request by using an atom:source
+ element. However, the atom:id value MUST be
+ reproduced exactly within the source element. If the source entry does
+ not have an atom:source element, the hub
+ MUST create an atom:source element
+ containing the atom:id element. The hub
+ SHOULD also include the atom:title element
+ and an atom:link element with rel="self" values that are functionally
+ equivalent to the corresponding elements in the original topic feed.
+
+ Example aggregated feed:
+
+
+
+
+ Aggregated feed
+ 2008-08-11T02:17:44Z
+ http://myhub.example.com/aggregated?1232427842-39823
+
+
+
+ http://www.example.com/foo
+
+
+ Mr. Bar
+
+
+ Testing Foo
+
+ http://publisher.example.com/foo24.xml
+ 2008-08-11T02:15:01Z
+
+ This is some content from the user named foo.
+
+
+
+
+
+ http://www.example.com/bar
+
+
+ Mr. Bar
+
+
+ Testing Bar
+
+ http://publisher.example.com/bar18.xml
+ 2008-08-11T02:17:44Z
+
+ Some data from the user named bar.
+
+
+
+
+]]>
+
+
+
+
+
+
+ (This section is non-normative.)
+
+ The vast majority of feeds on the web have multiple variants that contain essentially the same content
+ but appear on different URLs. A common set of variants is http://example.com/feed?format=atom and http://example.com/feed?format=rss. In practice,
+ these URLs also fail to set their //atom:feed/link[@rel="self"] values properly,
+ meaning it's difficult for subscribers to discover which feed URL they
+ truly wanted. Making matters worse, feeds often have redirects
+ (temporary or permanent) to new hosting locations, analytics providers,
+ or other feed-processors. To solve this, it's important for Hub
+ implementations to determine feed URL equivalences using heuristics.
+ Examples: follow all feed URLs redirects and see if they end up at the
+ same location; use overlaps in feed HTML alternate links; use the atom:id value across all domains. This specific
+ problem is considered out of scope of this specification but this
+ section is meant as a reminder to implementors that feed URL aliasing is
+ an important issue that hubs should address instead of putting
+ the burden on publishers and subscribers.
+
+ The hub.verify_token parameter in
+ subscription requests enables subscribers to verify the identity and
+ intent of the hub making the verification request. Subscribers should
+ use the token to retrieve internal state to ensure the subscription
+ request outcome is what they intended.
+
From 7445e4538185777a3ea0022f42f33a5d01e22387 Mon Sep 17 00:00:00 2001
From: julien
Date: Sun, 5 Feb 2012 23:17:00 +0100
Subject: [PATCH 03/76] generated 0.4.html
---
pubsubhubbub-core-0.4.html | 729 +++++++++++++++++++++++++++++++++++++
pubsubhubbub-core-0.4.xml | 34 +-
2 files changed, 731 insertions(+), 32 deletions(-)
create mode 100644 pubsubhubbub-core-0.4.html
diff --git a/pubsubhubbub-core-0.4.html b/pubsubhubbub-core-0.4.html
new file mode 100644
index 0000000..cf91acd
--- /dev/null
+++ b/pubsubhubbub-core-0.4.html
@@ -0,0 +1,729 @@
+
+Draft: PubSubHubbub Core 0.4 -- Working Draft
+
+
+
+
+
+
+
An open, simple, web-scale and decentralized pubsub protocol.
+ Anybody can play.
+
+
As opposed to more developed (and more complex) pubsub specs like Jabber Publish-Subscribe (Millard, P., Saint-Andre, P., and R. Meijer, “Publish-Subscribe,” .) [XEP‑0060] this spec's base profile
+ (the barrier-to-entry to speak it) is dead simple. The fancy bits required
+ for high-volume publishers and subscribers are optional. The base profile
+ is HTTP-based, as opposed to XMPP (see more on this below).
+
+
To dramatically simplify this spec in several places where we had to
+ choose between supporting A or B, we took it upon ourselves to say "only
+ A", rather than making it an implementation decision.
+
+
We offer this spec in hopes that it fills a need or at least advances
+ the state of the discussion in the pubsub space. Polling sucks. We think
+ a decentralized pubsub layer is a fundamental, missing layer in the
+ Internet architecture today and its existence, more than just enabling
+ the obvious lower latency feed readers, would enable many cool
+ applications, most of which we can't even imagine. But we're looking
+ forward to decentralized social networking.
+
+
Table of Contents
+
+1.
+Notation and Conventions
+2.
+Definitions
+3.
+High-level protocol flow
+4.
+Discovery
+5.
+Subscribing and Unsubscribing
+ 5.1.
+Subscriber Sends Subscription Request
+ 5.2.
+Hub Verifies Intent of the Subscriber
+ 5.3.
+Automatic Subscription Refreshing
+6.
+Publishing
+7.
+Content Distribution
+8.
+Authenticated Content Distribution
+9.
+References
+Appendix A.
+Specification Feedback
+§
+Authors' Addresses
+
An owner of a topic. Notifies the hub when
+ the topic feed has been updated. As in almost all pubsub systems, the
+ publisher is unaware of the subscribers, if any. Other pubsub systems
+ might call the publisher the "source".
+
+
Subscriber:
+
An entity (person or program) that wants
+ to be notified of changes on a topic. The subscriber must be
+ directly network-accessible and is identified by its Subscriber
+ Callback URL.
+
+
Subscription:
+
A unique relation to a topic by a
+ subscriber that indicates it should receive updates for that topic. A
+ subscription's unique key is the tuple (Topic URL, Subscriber Callback
+ URL). Subscriptions may (at the hub's decision) have expiration times
+ akin to DHCP leases which must be periodically renewed.
+
An event that causes updates to multiple topics.
+ For each event that happens (e.g. "Brad posted to the Linux
+ Community."), multiple topics could be affected (e.g. "Brad posted."
+ and "Linux community has new post"). Publisher events cause topics to
+ be updated and the hub looks up all subscriptions for affected topics,
+ sending out notifications to subscribers.
+
+
Notification:
+
A payload describing how a topic's
+ contents have changed, or the full cupdated content.
+ Depending on the topic's content type, the difference (or "delta") may be
+ computed by the hub and sent to all subscribers.
+
Publishers notify their hub(s) URLs when their topic(s)
+ change.
+
+
Subscribers POST to one or more of the advertised hubs for a
+ topic they're interested in. Alternatively, some hubs may offer
+ auto-polling capability, to let {their,any} subscribers subscribe to
+ topics which don't advertise a hub.
+
+
The hub caches minimal metadata (id, data, entry digest) about
+ each topic's previous state. When the hub re-fetches a topic feed (on
+ its own initiative or as a result of a publisher's ping) and finds a
+ delta, it enqueues a notification to all registered subscribers.
+
A potential subscriber initiates discovery by retrieving the topic to
+ which it wants to subscribe. The HTTP response from the publisher MUST
+ include at least one X-Hub-Url
+ HTTP header, as well as exactly one X-Hub-Self-Url
+ HTTP header. The X-Hub-Url MUST
+ indicate the exact url of the PubSubHubbub hub designated by the publisher.
+ If more than one url is specified, it is expected that the publisher pings each
+ of these urls, so the subscriber may subscribe to one or more of these.
+ The X-Hub-Self-Url will point to the
+ permanent URL for the resource being polled.
+
REQUIRED. The subscriber's callback URL
+ where notifications should be delivered. The subscriber's
+ callback URL SHOULD be unique for each subscription.
+
+
hub.mode
+
REQUIRED. The literal string "subscribe" or
+ "unsubscribe", depending on the goal of the request.
+
+
hub.topic
+
REQUIRED. The topic URL that the subscriber
+ wishes to subscribe to.
+
+
hub.lease_seconds
+
OPTIONAL. Number of seconds for
+ which the subscriber would like to have the subscription active. If
+ not present or an empty value, the subscription will be permanent
+ (or active until automatic
+ refreshing (Automatic Subscription Refreshing) removes the subscription). Hubs MAY choose to
+ respect this value or not, depending on their own policies. This
+ parameter MAY be present for unsubscription requests and MUST be
+ ignored by the hub in that case.
+
Hubs MUST ignore additional request parameters they do not
+ understand.
+
+
Hubs MUST allow subscribers to re-request subscriptions that are
+ already activate. Each subsequent request to a hub to subscribe or
+ unsubscribe MUST override the previous subscription state for a
+ specific topic URL and callback URL combination once the action is
+ verified. Any failures to confirm the subscription action MUST leave
+ the subscription state unchanged. This is required so subscribers can
+ renew their subscriptions before the lease seconds period is over
+ without any interruption.
+
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; Hubs MUST only append verification
+ parameters to the existing list, if any. For event notification, the
+ callback URL will be POSTed to including any query-string parameters
+ in the URL portion of the request, not as POST body parameters.
+
If a hub finds any errors in the subscription request, an
+ appropriate HTTP 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. Hubs MAY decide to reject some
+ callback URLs or topic URLs based on their own policies (e.g., domain
+ authorization, topic URL port numbers).
+
In order to prevent an attacker from creating unwanted subscriptions
+ on behalf of a subscriber (or unsubscribing desired ones), a hub must
+ ensure that the subscriber did indeed send the subscription request.
+
REQUIRED. The literal string "subscribe" or
+ "unsubscribe", which matches the original request to the hub from
+ the subscriber.
+
+
hub.topic
+
REQUIRED. The topic URL given in the
+ corresponding subscription request.
+
+
hub.challenge
+
REQUIRED. A hub-generated, random string
+ that MUST be echoed by the subscriber to verify the
+ subscription.
+
+
hub.lease_seconds
+
REQUIRED/OPTIONAL. The
+ hub-determined number of seconds that the subscription will stay
+ active before expiring, measured from the time the verification
+ request was made from the hub to the subscriber. Hubs MUST supply
+ this parameter for subscription requests. This parameter MAY be
+ present for unsubscribe requests and MUST be ignored by subscribers
+ during unsubscription.
+
The subscriber MUST confirm that the hub.topic
+ correspond to a pending subscription or unsubscription that it
+ wishes to carry out. If so, the subscriber MUST respond with an HTTP
+ success (2xx) code with a response body equal to the hub.challenge parameter. If the subscriber does
+ not agree with the action, the subscriber MUST respond with a 404 "Not
+ Found" response.
+
+
The hub MUST consider other server response codes (3xx, 4xx, 5xx)
+ to mean that the verification request has failed. If the subscriber
+ returns an HTTP success (2xx) but the content body does not match the
+ hub.challenge parameter, the hub MUST also
+ consider verification to have failed.
+
+
Hubs MAY make the hub.lease_seconds
+ equal to the period the subscriber passed in their subscription
+ request but MAY change the value depending on the hub's policies. To
+ sustain a temporary subscription, the subscriber MUST re-request the
+ subscription on the hub before hub.lease_seconds seconds has elapsed. For
+ permanent subscriptions with no hub.lease_seconds value specified, the behavior
+ is different as described in the section on automatic subscription refreshing (Automatic Subscription Refreshing).
+
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 has been accepted,
+ the hub MUST indicate it to the subscriber by performing a notification
+ of the current state of the resource to the subscriber (see Section 7 (Content Distribution)).
+ (this is optional in synchronous mode). The subscriber will use this has
+ an indication that its subscription has been confirmed.
+
+
Additionally, this notification MUST include a X-Hub-Self-Url
+ HTTP header which indicates to the subscriber to what feed he has been subscribed.
+ This feed url MAY be different from the feed for which the subscriber has initially subscribed,
+ as the publisher MAY have considered that this one was better suited for the subscriber.
+ (This is specifically useful in the context of private content with limited distribution.)
+
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 intentionally 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.
+
Before a subscription expires (i.e., before hub.lease_seconds elapses), Hubs MUST recheck with
+ subscribers to see if a continued subscription is desired. Hubs do this
+ by sending the subscriber a verification
+ request (Hub Verifies Intent of the Subscriber) with hub.mode equal to
+ subscribe. This request MUST match the original verification request
+ sent to the subscriber (but with a new hub.challenge
+ ).
+
+
The response codes returned by the subscriber MUST be interpreted the
+ same way as during a subscriber-initiated verification flow. However,
+ this refresh request MUST behave like an initial subscription request;
+ this means that if an auto-refresh response from the subscriber
+ constantly returns an error, the hub MUST give up on the subscription
+ verification action altogether and remove the subscription.
+
+
In the case of permanent subscriptions (with no hub.lease_seconds specified in the original
+ request), the hub.lease_seconds value
+ supplied by the hub in the verification request to the subscriber SHOULD
+ represent how many seconds until the hub expects it will next initiate
+ automatic subscription refreshing to ensure that the subscriber is still
+ interested in the topic. This behavior provides the best of both worlds:
+ maximum simplicity of the subscriber through infinitely-long
+ subscriptions, but still garbage collectable subscriptions for hub
+ hygiene.
+
The publisher MUST inform the hub it previously designated when a topic
+ has been updated. The hub and the publisher CAN agree on any mechanism, as
+ long as the hub is eventually able send the updated payload to the
+ subscribers.
+
The POST request must include a X-Hub-Self-Url
+ and a X-Hub-Url HTTP headers that correspond
+ to topic's url, as well as hub.
+
+
The successful response from the subscriber's callback URL MUST be an
+ HTTP success (2xx) code. The hub MUST consider all other subscriber
+ response codes as failures; that means subscribers MUST not use HTTP
+ redirects for moving subscriptions. The response body from the
+ subscriber MUST be ignored by the hub. Hubs SHOULD retry notifications
+ repeatedly until successful (up to some reasonable maximum over a
+ reasonable time period). Subscribers SHOULD respond to notifications 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.
+
When subscribers receive a content distribution request with the
+ X-Hub-Signature header specified, they
+ SHOULD recompute the SHA1 signature with the shared secret using the
+ same method as the hub. If the signature does not match, subscribers
+ MUST still return a 2xx success response to acknowledge receipt, but
+ locally ignore the message as invalid. Using this technique along with
+ HTTPS (Rescorla, E., “HTTP Over TLS,” May 2000.) [RFC2818] for subscription requests enables
+ simple subscribers to receive authenticated content delivery from hubs
+ without the need for subscribers to run an HTTPS server.
+
+
Please note however that this signature only ensures that the payload
+ was not forged. Since the notification also includes headers, these should
+ not be considered as safe by the subscriber, unless of course the subscriber
+ uses HTTPS (Rescorla, E., “HTTP Over TLS,” May 2000.) [RFC2818] callbacks.
+
+
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index 410835d..985d100 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -12,7 +12,7 @@
$ xml2rfc pubsubhubbub-core-0.1.xml pubsubhubbub-core-0.1.html
-->
-
+
@@ -158,7 +158,6 @@
delta, it enqueues a notification to all registered subscribers.
-
A potential subscriber initiates discovery by retrieving the topic to
@@ -363,7 +362,7 @@
If (and when), the subscription has been accepted,
the hub MUST indicate it to the subscriber by performing a notification
- of the current state of the resource to the subscriber (see ).
+ of the current state of the resource to the subscriber (see ).
(this is optional in synchronous mode). The subscriber will use this has
an indication that its subscription has been confirmed.
@@ -489,8 +488,6 @@
uses HTTPS callbacks.
-
-
@@ -620,23 +617,6 @@
-
-
- The Atom Syndication Format
-
-
-
-
-
-
-
-
-
-
-
-
-
-
@@ -677,16 +657,6 @@
-
-
- RSS 2.0
-
-
-
-
-
-
-
From dd309e22786cc5bb627d61c4e9510fd47806da4d Mon Sep 17 00:00:00 2001
From: julien
Date: Wed, 15 Feb 2012 22:19:19 -0800
Subject: [PATCH 04/76] clarified 'content delivery' as per Ralphm's feedback
---
pubsubhubbub-core.xml | 101 +++---------------------------------------
1 file changed, 7 insertions(+), 94 deletions(-)
diff --git a/pubsubhubbub-core.xml b/pubsubhubbub-core.xml
index d30554e..aff8917 100644
--- a/pubsubhubbub-core.xml
+++ b/pubsubhubbub-core.xml
@@ -135,18 +135,12 @@
be updated and the hub looks up all subscriptions for affected topics,
sending out notifications to subscribers.
- A payload describing how a topic's
- contents have changed. This difference (or "delta") is computed by the
- hub and sent to all subscribers. The format of the notification will
- be an Atom or RSS feed served by the publisher with only those entries
- present which are new or have changed. The notification can be the
- result of a publisher telling the hub of an update, or the hub
- proactively polling a topic feed, perhaps for a subscriber subscribing
- to a topic that's not pubsub-aware. Note also that a notification to a
- subscriber can be a payload consisting of updates for multiple topics.
- Hubs MAY choose to send multi-topic notifications as an optimization
- for heavy subscribers, but subscribers MUST understand them. See for format details.
+ A payload which can either be the
+ topic's full content of the difference (or "delta") computed by the
+ hub between the previous content of the resource and its current context.
+ The notification can be the result of a publisher telling the hub of an
+ update, or the hub proactively polling a topic, perhaps for a subscriber
+ subscribing to a topic that's not pubsub-aware.
@@ -700,91 +694,10 @@ User-Agent: MyHub (+http://hub.example.com; 26 subscribers)
MUST still return a 2xx success response to acknowledge receipt, but
locally ignore the message as invalid. Using this technique along with
HTTPS for subscription requests enables simple subscribers to receive
- authenticated content delivery from hubs without the need for
+ authenticated notifications from hubs without the need for
subscribers to run an HTTPS server.
-
-
-
- For Atom feeds only. Pending further review.
-
- When a subscriber indicates the same callback URL is used for
- multiple subscriptions, hubs MAY choose to combine content delivery
- requests into a single payload containing an aggregated set of feeds.
- This bulk delivery results in fewer requests and more efficient
- distribution. If the subscriber indicated a hub.secret value for these overlapping
- subscriptions, the secret MUST also be the same for all subscriptions.
- This allows the hub to generate a single X-Hub-Signature header to sign the entire payload.
- Hubs MUST return an error response (4xx, 5xx) for subscription
- requests with overlapping callback URLs and different secret values.
-
-
- With an aggregated set of feeds, the hub SHOULD reproduce all of the
- elements from the source feed inside the
- corresponding atom:entry in the content
- distribution request by using an atom:source
- element. However, the atom:id value MUST be
- reproduced exactly within the source element. If the source entry does
- not have an atom:source element, the hub
- MUST create an atom:source element
- containing the atom:id element. The hub
- SHOULD also include the atom:title element
- and an atom:link element with rel="self" values that are functionally
- equivalent to the corresponding elements in the original topic feed.
-
- Example aggregated feed:
-
-
-
-
- Aggregated feed
- 2008-08-11T02:17:44Z
- http://myhub.example.com/aggregated?1232427842-39823
-
-
-
- http://www.example.com/foo
-
-
- Mr. Bar
-
-
- Testing Foo
-
- http://publisher.example.com/foo24.xml
- 2008-08-11T02:15:01Z
-
- This is some content from the user named foo.
-
-
-
-
-
- http://www.example.com/bar
-
-
- Mr. Bar
-
-
- Testing Bar
-
- http://publisher.example.com/bar18.xml
- 2008-08-11T02:17:44Z
-
- Some data from the user named bar.
-
-
-
-
-]]>
-
-
-
From 7457abe742307c1bb7f40eaf7feee2250a485c41 Mon Sep 17 00:00:00 2001
From: julien
Date: Wed, 15 Feb 2012 22:20:51 -0800
Subject: [PATCH 05/76] Revert "clarified 'content delivery' as per Ralphm's
feedback"
This reverts commit dd309e22786cc5bb627d61c4e9510fd47806da4d.
---
pubsubhubbub-core.xml | 101 +++++++++++++++++++++++++++++++++++++++---
1 file changed, 94 insertions(+), 7 deletions(-)
diff --git a/pubsubhubbub-core.xml b/pubsubhubbub-core.xml
index aff8917..d30554e 100644
--- a/pubsubhubbub-core.xml
+++ b/pubsubhubbub-core.xml
@@ -135,12 +135,18 @@
be updated and the hub looks up all subscriptions for affected topics,
sending out notifications to subscribers.
- A payload which can either be the
- topic's full content of the difference (or "delta") computed by the
- hub between the previous content of the resource and its current context.
- The notification can be the result of a publisher telling the hub of an
- update, or the hub proactively polling a topic, perhaps for a subscriber
- subscribing to a topic that's not pubsub-aware.
+ A payload describing how a topic's
+ contents have changed. This difference (or "delta") is computed by the
+ hub and sent to all subscribers. The format of the notification will
+ be an Atom or RSS feed served by the publisher with only those entries
+ present which are new or have changed. The notification can be the
+ result of a publisher telling the hub of an update, or the hub
+ proactively polling a topic feed, perhaps for a subscriber subscribing
+ to a topic that's not pubsub-aware. Note also that a notification to a
+ subscriber can be a payload consisting of updates for multiple topics.
+ Hubs MAY choose to send multi-topic notifications as an optimization
+ for heavy subscribers, but subscribers MUST understand them. See for format details.
@@ -694,10 +700,91 @@ User-Agent: MyHub (+http://hub.example.com; 26 subscribers)
MUST still return a 2xx success response to acknowledge receipt, but
locally ignore the message as invalid. Using this technique along with
HTTPS for subscription requests enables simple subscribers to receive
- authenticated notifications from hubs without the need for
+ authenticated content delivery from hubs without the need for
subscribers to run an HTTPS server.
+
+
+
+ For Atom feeds only. Pending further review.
+
+ When a subscriber indicates the same callback URL is used for
+ multiple subscriptions, hubs MAY choose to combine content delivery
+ requests into a single payload containing an aggregated set of feeds.
+ This bulk delivery results in fewer requests and more efficient
+ distribution. If the subscriber indicated a hub.secret value for these overlapping
+ subscriptions, the secret MUST also be the same for all subscriptions.
+ This allows the hub to generate a single X-Hub-Signature header to sign the entire payload.
+ Hubs MUST return an error response (4xx, 5xx) for subscription
+ requests with overlapping callback URLs and different secret values.
+
+
+ With an aggregated set of feeds, the hub SHOULD reproduce all of the
+ elements from the source feed inside the
+ corresponding atom:entry in the content
+ distribution request by using an atom:source
+ element. However, the atom:id value MUST be
+ reproduced exactly within the source element. If the source entry does
+ not have an atom:source element, the hub
+ MUST create an atom:source element
+ containing the atom:id element. The hub
+ SHOULD also include the atom:title element
+ and an atom:link element with rel="self" values that are functionally
+ equivalent to the corresponding elements in the original topic feed.
+
+ Example aggregated feed:
+
+
+
+
+ Aggregated feed
+ 2008-08-11T02:17:44Z
+ http://myhub.example.com/aggregated?1232427842-39823
+
+
+
+ http://www.example.com/foo
+
+
+ Mr. Bar
+
+
+ Testing Foo
+
+ http://publisher.example.com/foo24.xml
+ 2008-08-11T02:15:01Z
+
+ This is some content from the user named foo.
+
+
+
+
+
+ http://www.example.com/bar
+
+
+ Mr. Bar
+
+
+ Testing Bar
+
+ http://publisher.example.com/bar18.xml
+ 2008-08-11T02:17:44Z
+
+ Some data from the user named bar.
+
+
+
+
+]]>
+
+
+
From b06a92e03972dc805c7376742dc279b021f3fe89 Mon Sep 17 00:00:00 2001
From: julien
Date: Wed, 15 Feb 2012 22:22:39 -0800
Subject: [PATCH 06/76] clarified 'content delivery' as per Ralphm's feedback
---
pubsubhubbub-core-0.4.xml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index 985d100..6dcebbe 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -134,7 +134,7 @@
sending out notifications to subscribers.
A payload describing how a topic's
- contents have changed, or the full cupdated content.
+ contents have changed, or the full updated content.
Depending on the topic's content type, the difference (or "delta") may be
computed by the hub and sent to all subscribers.
@@ -479,7 +479,7 @@
MUST still return a 2xx success response to acknowledge receipt, but
locally ignore the message as invalid. Using this technique along with
HTTPS for subscription requests enables
- simple subscribers to receive authenticated content delivery from hubs
+ simple subscribers to receive authenticated notifications from hubs
without the need for subscribers to run an HTTPS server.
Please note however that this signature only ensures that the payload
From 7ac2e599865e6929ecc6b2eb573600b1c4cfd4e9 Mon Sep 17 00:00:00 2001
From: julien
Date: Fri, 24 Feb 2012 10:44:41 +0100
Subject: [PATCH 07/76] =?UTF-8?q?using=20Link=20Header=20per=20Evan's=20re?=
=?UTF-8?q?quest.=20Fixes=20issue=20#=C3=A92?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
---
pubsubhubbub-core-0.4.xml | 38 ++++++++++++++++++++++++++------------
1 file changed, 26 insertions(+), 12 deletions(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index 6dcebbe..278fba7 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -160,16 +160,15 @@
- A potential subscriber initiates discovery by retrieving the topic to
- which it wants to subscribe. The HTTP response from the publisher MUST
- include at least one X-Hub-Url
- HTTP header, as well as exactly one X-Hub-Self-Url
- HTTP header. The X-Hub-Url MUST
- indicate the exact url of the PubSubHubbub hub designated by the publisher.
+ A potential subscriber initiates discovery by retrieving (GET or HEAD request)
+ the topic to which it wants to subscribe. The HTTP response from the publisher MUST
+ include at least one Link Header with
+ rel=hub (a hub link header) as well as exactly one Link Header
+ with rel=self (the self link header).
+ The former MUST indicate the exact url of a PubSubHubbub hub designated by the publisher.
If more than one url is specified, it is expected that the publisher pings each
of these urls, so the subscriber may subscribe to one or more of these.
- The X-Hub-Self-Url will point to the
- permanent URL for the resource being polled.
+ The former will point to the permanent URL for the resource being polled.Example:
@@ -249,7 +248,7 @@
The topic and callback URLs MAY use HTTP
or HTTPS schemes. The topic URL MUST
- be the one advertised by the publisher in the X-Hub-Self-Url
+ be the one advertised by the publisher in a Hub Link Header
Header during the discovery phase. (See ).
Hubs MAY refuse subscriptions if the topic url does not correspond to the one
advertised by the publisher. The topic URL can otherwise be free-form
@@ -366,7 +365,7 @@
(this is optional in synchronous mode). The subscriber will use this has
an indication that its subscription has been confirmed.
- Additionally, this notification MUST include a X-Hub-Self-Url
+ Additionally, this notification MUST include a Self Link Header
HTTP header which indicates to the subscriber to what feed he has been subscribed.
This feed url MAY be different from the feed for which the subscriber has initially subscribed,
as the publisher MAY have considered that this one was better suited for the subscriber.
@@ -441,8 +440,8 @@
type of the topic. The hub MAY reduce the payload to a diff if its format
allows it.
- The POST request must include a X-Hub-Self-Url
- and a X-Hub-Url HTTP headers that correspond
+ The POST request must include the Self Link Header
+ and a Hub Link Header that correspond
to topic's url, as well as hub.The successful response from the subscriber's callback URL MUST be an
@@ -588,6 +587,21 @@
+
+
+ Web Linking
+
+
+
+
+ This document specifies relation types for Web links, and defines a
+ registry for them. It also defines the use of such links in HTTP
+ headers with the Link header field.
+
+
+
+
+
US Secure Hash Algorithm 1 (SHA1)
From cde42a14af6d999db93bef885561877137ae4d73 Mon Sep 17 00:00:00 2001
From: julien
Date: Fri, 24 Feb 2012 10:51:07 +0100
Subject: [PATCH 08/76] pointing to the W3C CG for feedback. Fixes #6
---
pubsubhubbub-core-0.4.xml | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index 278fba7..b300aab 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -675,14 +675,10 @@
Feedback on this specification is welcomed via the
- pubsubhubbub mailing list, pubsubhubbub@googlegroups.com. For
+ PubSubHubbub W3C Community Group. For
more information, see the
- PubSubHubbub group on Google Groups. Also, check out the
- FAQ
- and other
- documentation.
+ target="http://www.w3.org/community/pubsub/">the
+ W3C PubSubHubbub Community Group.
From 6507fb63b67c727caf1a9847a2486460c5742009 Mon Sep 17 00:00:00 2001
From: julien
Date: Fri, 24 Feb 2012 10:56:56 +0100
Subject: [PATCH 09/76] fixing tags
---
pubsubhubbub-core-0.4.xml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index b300aab..87a656f 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -162,8 +162,8 @@
A potential subscriber initiates discovery by retrieving (GET or HEAD request)
the topic to which it wants to subscribe. The HTTP response from the publisher MUST
- include at least one Link Header with
- rel=hub (a hub link header) as well as exactly one Link Header
+ include at least one Link Header with
+ rel=hub (a hub link header) as well as exactly one Link Header
with rel=self (the self link header).
The former MUST indicate the exact url of a PubSubHubbub hub designated by the publisher.
If more than one url is specified, it is expected that the publisher pings each
From 07a6cf945a2c43746534a4ce86668efae2a808e1 Mon Sep 17 00:00:00 2001
From: julien
Date: Fri, 24 Feb 2012 10:58:04 +0100
Subject: [PATCH 10/76] fixing tag issue
---
pubsubhubbub-core-0.4.html | 38 ++++++++++++++++++--------------------
pubsubhubbub-core-0.4.xml | 2 +-
2 files changed, 19 insertions(+), 21 deletions(-)
diff --git a/pubsubhubbub-core-0.4.html b/pubsubhubbub-core-0.4.html
index cf91acd..86bae54 100644
--- a/pubsubhubbub-core-0.4.html
+++ b/pubsubhubbub-core-0.4.html
@@ -264,7 +264,7 @@
Table of Contents
Notification:
A payload describing how a topic's
- contents have changed, or the full cupdated content.
+ contents have changed, or the full updated content.
Depending on the topic's content type, the difference (or "delta") may be
computed by the hub and sent to all subscribers.
@@ -299,16 +299,15 @@
Table of Contents
4.
Discovery
-
A potential subscriber initiates discovery by retrieving the topic to
- which it wants to subscribe. The HTTP response from the publisher MUST
- include at least one X-Hub-Url
- HTTP header, as well as exactly one X-Hub-Self-Url
- HTTP header. The X-Hub-Url MUST
- indicate the exact url of the PubSubHubbub hub designated by the publisher.
+
A potential subscriber initiates discovery by retrieving (GET or HEAD request)
+ the topic to which it wants to subscribe. The HTTP response from the publisher MUST
+ include at least one Link Header (Nottingham, M., “Web Linking,” October 2010.) [RFC5988] with
+ rel=hub (a hub link header) as well as exactly one Link Header (Nottingham, M., “Web Linking,” October 2010.) [RFC5988]
+ with rel=self (the self link header).
+ The former MUST indicate the exact url of a PubSubHubbub hub designated by the publisher.
If more than one url is specified, it is expected that the publisher pings each
of these urls, so the subscriber may subscribe to one or more of these.
- The X-Hub-Self-Url will point to the
- permanent URL for the resource being polled.
+ The former will point to the permanent URL for the resource being polled.
(this is optional in synchronous mode). The subscriber will use this has
an indication that its subscription has been confirmed.
-
Additionally, this notification MUST include a X-Hub-Self-Url
+
Additionally, this notification MUST include a Self Link Header
HTTP header which indicates to the subscriber to what feed he has been subscribed.
This feed url MAY be different from the feed for which the subscriber has initially subscribed,
as the publisher MAY have considered that this one was better suited for the subscriber.
@@ -610,8 +609,8 @@
Table of Contents
type of the topic. The hub MAY reduce the payload to a diff if its format
allows it.
-
The POST request must include a X-Hub-Self-Url
- and a X-Hub-Url HTTP headers that correspond
+
The POST request must include the Self Link Header
+ and a Hub Link Header that correspond
to topic's url, as well as hub.
The successful response from the subscriber's callback URL MUST be an
@@ -647,7 +646,7 @@
Table of Contents
MUST still return a 2xx success response to acknowledge receipt, but
locally ignore the message as invalid. Using this technique along with
HTTPS (Rescorla, E., “HTTP Over TLS,” May 2000.) [RFC2818] for subscription requests enables
- simple subscribers to receive authenticated content delivery from hubs
+ simple subscribers to receive authenticated notifications from hubs
without the need for subscribers to run an HTTPS server.
Please note however that this signature only ensures that the payload
@@ -674,6 +673,8 @@
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index 87a656f..c507c29 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -587,7 +587,7 @@
-
+ Web Linking
From 667b02dc04cfbaf29404f46fc4e3c47585b1a301 Mon Sep 17 00:00:00 2001
From: julien
Date: Fri, 24 Feb 2012 16:30:37 +0100
Subject: [PATCH 11/76] Ralphm's comment about fallback. For some reason I
couldn't merge
---
pubsubhubbub-core-0.4.xml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index c507c29..f987f97 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -179,6 +179,13 @@
depending on the hub's policy. If the advertised url is HTTP,
subscriber MAY choose to try HTTPS first.
+
+ In the absence of HTTP Link headers, subscribers MAY fall back to
+ other methods to discover the hub(s) and the canonical URI of the topic.
+ If the topic is a Atom or RSS feed, it MAY use embedded link elements
+ as described in Appendix B of Web Linking.
+ Similarly, for HTML pages, it MAY use embedded link elements as described
+ in Appendix A of Web Linking.
From 7b128137a17d99e566ededc64be00acc04bb040e Mon Sep 17 00:00:00 2001
From: julien
Date: Fri, 24 Feb 2012 16:31:17 +0100
Subject: [PATCH 12/76] regenerating the html
---
pubsubhubbub-core-0.4.html | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/pubsubhubbub-core-0.4.html b/pubsubhubbub-core-0.4.html
index 86bae54..e75a515 100644
--- a/pubsubhubbub-core-0.4.html
+++ b/pubsubhubbub-core-0.4.html
@@ -318,6 +318,13 @@
In the absence of HTTP Link headers, subscribers MAY fall back to
+ other methods to discover the hub(s) and the canonical URI of the topic.
+ If the topic is a Atom or RSS feed, it MAY use embedded link elements
+ as described in Appendix B of Web Linking (Nottingham, M., “Web Linking,” October 2010.) [RFC5988].
+ Similarly, for HTML pages, it MAY use embedded link elements as described
+ in Appendix A of Web Linking (Nottingham, M., “Web Linking,” October 2010.) [RFC5988].
+
5.
From 5bcf9b954c71413f1a09ff2432b11f3f07ede375 Mon Sep 17 00:00:00 2001
From: julien
Date: Fri, 30 Mar 2012 20:27:36 +0200
Subject: [PATCH 13/76] using 202 as per Jay's comments
---
pubsubhubbub-core.xml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/pubsubhubbub-core.xml b/pubsubhubbub-core.xml
index d30554e..8829a4e 100644
--- a/pubsubhubbub-core.xml
+++ b/pubsubhubbub-core.xml
@@ -478,7 +478,7 @@
The subscriber MUST confirm that the hub.topic
and hub.verify_token correspond
to a pending subscription or unsubscription that it wishes to carry
- out. If so, the subscriber MUST respond with an HTTP success (2xx)
+ out. If so, the subscriber MUST respond with an HTTP success (202)
code with a response body equal to the hub.challenge parameter. If the subscriber does
not agree with the action, the subscriber MUST respond with a 404 "Not
@@ -487,14 +487,14 @@
For synchronous verification, the hub MUST consider other server
response codes (3xx, 4xx, 5xx) to mean that the verification request
has immediately failed and no retries should occur. If the subscriber
- returns an HTTP success (2xx) but the content body does not match the
+ returns an HTTP success (202) but the content body does not match the
hub.challenge parameter, the hub MUST also
consider verification to have failed.For asynchronous verification, the hub MUST consider other server
response codes (3xx, 4xx, and 5xx) to mean that the subscription
action was temporarily not verified. If
- the subscriber returns an HTTP success (2xx) but the content body does
+ the subscriber returns an HTTP success (202) but the content body does
not match the hub.challenge parameter, the
hub MUST consider this to be a temporary
failure and retry. The hub SHOULD retry verification a reasonable
@@ -656,7 +656,7 @@ User-Agent: MyHub (+http://hub.example.com; 26 subscribers)
that looks like the original but with old content removed.The successful response from the subscriber's callback URL MUST be an
- HTTP success (2xx) code. The hub MUST consider all other subscriber
+ HTTP success (202) code. The hub MUST consider all other subscriber
response codes as failures; that means subscribers MUST not use HTTP
redirects for moving subscriptions. The response body from the
subscriber MUST be ignored by the hub. Hubs SHOULD retry notifications
@@ -697,7 +697,7 @@ User-Agent: MyHub (+http://hub.example.com; 26 subscribers)
X-Hub-Signature header specified, they
SHOULD recompute the SHA1 signature with the shared secret using the
same method as the hub. If the signature does not match, subscribers
- MUST still return a 2xx success response to acknowledge receipt, but
+ MUST still return a 202 success response to acknowledge receipt, but
locally ignore the message as invalid. Using this technique along with
HTTPS for subscription requests enables simple subscribers to receive
authenticated content delivery from hubs without the need for
From 137a382b4b5fcf7222fb9d871baed6d594b37e22 Mon Sep 17 00:00:00 2001
From: julien
Date: Tue, 3 Apr 2012 09:59:36 +0200
Subject: [PATCH 14/76] fixing the initial for Julien Genestoux
---
pubsubhubbub-core-0.4.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index f987f97..47ec32a 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -54,7 +54,7 @@
The former MUST indicate the exact url of a PubSubHubbub hub designated by the publisher.
If more than one url is specified, it is expected that the publisher pings each
of these urls, so the subscriber may subscribe to one or more of these.
- The former will point to the permanent URL for the resource being polled.
-
-
In the absence of HTTP Link headers, subscribers MAY fall back to
other methods to discover the hub(s) and the canonical URI of the topic.
@@ -622,7 +613,7 @@
Table of Contents
The successful response from the subscriber's callback URL MUST be an
HTTP success (2xx) code. The hub MUST consider all other subscriber
- response codes as failures; that means subscribers MUST not use HTTP
+ response codes as failures; that means subscribers MUST NOT use HTTP
redirects for moving subscriptions. The response body from the
subscriber MUST be ignored by the hub. Hubs SHOULD retry notifications
repeatedly until successful (up to some reasonable maximum over a
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index 47ec32a..2a408a3 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -168,16 +168,7 @@
The former MUST indicate the exact url of a PubSubHubbub hub designated by the publisher.
If more than one url is specified, it is expected that the publisher pings each
of these urls, so the subscriber may subscribe to one or more of these.
- The former will point to the permanent URL for the resource being polled.
-
- Example:
-
- Hubs should provide an HTTPS interface and publishers
- SHOULD use HTTPS in their hubs' discovery URLs.
- However, subscribers that do not support HTTPS MAY
- try to fallback to HTTP, which MAY work
- depending on the hub's policy. If the advertised url is HTTP,
- subscriber MAY choose to try HTTPS first.
+ The latter will point to the permanent URL for the resource being polled.
In the absence of HTTP Link headers, subscribers MAY fall back to
@@ -453,7 +444,7 @@
The successful response from the subscriber's callback URL MUST be an
HTTP success (2xx) code. The hub MUST consider all other subscriber
- response codes as failures; that means subscribers MUST not use HTTP
+ response codes as failures; that means subscribers MUST NOT use HTTP
redirects for moving subscriptions. The response body from the
subscriber MUST be ignored by the hub. Hubs SHOULD retry notifications
repeatedly until successful (up to some reasonable maximum over a
From 654ab27b2804df5705a311d32bb2b2faa705bb37 Mon Sep 17 00:00:00 2001
From: julien
Date: Wed, 2 May 2012 14:20:56 +0200
Subject: [PATCH 16/76] adding From: header mention, as well as Location: for
denied subscriptions
---
pubsubhubbub-core-0.4.xml | 37 +++++++++++++++++++++++++------------
1 file changed, 25 insertions(+), 12 deletions(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index 2a408a3..ffd3346 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -241,6 +241,13 @@
the subscription state unchanged. This is required so subscribers can
renew their subscriptions before the lease seconds period is over
without any interruption.
+
+ Subscribers MAY also include additional HTTP Query params, as well as HTTP Headers
+ if they are required by the hub, or the publisher. In the context
+ of social web applications, it is considered good practice to include a From
+ HTTP header (as described in section 14.22 of Hypertext Transfer Protocol).
+ This header should indicate on behalf of which user the subscription is being performed.
+
@@ -326,7 +333,7 @@
The subscriber MUST confirm that the hub.topic
- correspond to a pending subscription or unsubscription that it
+ corresponds to a pending subscription or unsubscription that it
wishes to carry out. If so, the subscriber MUST respond with an HTTP
success (2xx) code with a response body equal to the hub.challenge parameter. If the subscriber does
@@ -357,18 +364,18 @@
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 has been accepted,
- the hub MUST indicate it to the subscriber by performing a notification
- of the current state of the resource to the subscriber (see ).
- (this is optional in synchronous mode). The subscriber will use this has
- an indication that its subscription has been confirmed.
- Additionally, this notification MUST include a Self Link Header
- HTTP header which indicates to the subscriber to what feed he has been subscribed.
- This feed url MAY be different from the feed for which the subscriber has initially subscribed,
- as the publisher MAY have considered that this one was better suited for the subscriber.
- (This is specifically useful in the context of private content with limited distribution.)
-
+ If (and when), the subscription is accepted, the hub will inform the subscriber
+ by sending an HTTP 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 17.13.4 of
+ ):
+
+ REQUIRED. The literal string "accepted".
+ REQUIRED. The topic URL given in the corresponding
+ subscription request.
+
+
If (and when), the subscription is denied, the hub will inform the subscriber
by sending an HTTP GET request to the subscriber's
callback URL as given in the subscription request. This request has the following
@@ -382,6 +389,12 @@
for which the subscription has been denied.
+ Hubs may provide an additional HTTP Location header (as described in section 14.30
+ of Hypertext Transfer Protocol) to indicate that the
+ subscriber may retry subscribing to a different hub.topic. This will allow
+ for limited distribution to specific groups, users in the context of social web
+ applications.
+
The subscription may be intentionally 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.
From df2d64ce5ec1380939eaeeb79d0f930c6003555f Mon Sep 17 00:00:00 2001
From: julien
Date: Wed, 2 May 2012 14:21:26 +0200
Subject: [PATCH 17/76] regenerated the 0.4 html
---
pubsubhubbub-core-0.4.html | 42 +++++++++++++++++++++++++++-----------
1 file changed, 30 insertions(+), 12 deletions(-)
diff --git a/pubsubhubbub-core-0.4.html b/pubsubhubbub-core-0.4.html
index 0fdfa40..cb23484 100644
--- a/pubsubhubbub-core-0.4.html
+++ b/pubsubhubbub-core-0.4.html
@@ -397,6 +397,13 @@
Table of Contents
renew their subscriptions before the lease seconds period is over
without any interruption.
The subscriber MUST confirm that the hub.topic
- correspond to a pending subscription or unsubscription that it
+ corresponds to a pending subscription or unsubscription that it
wishes to carry out. If so, the subscriber MUST respond with an HTTP
success (2xx) code with a response body equal to the hub.challenge parameter. If the subscriber does
not agree with the action, the subscriber MUST respond with a 404 "Not
@@ -519,18 +526,23 @@
Table of Contents
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 has been accepted,
- the hub MUST indicate it to the subscriber by performing a notification
- of the current state of the resource to the subscriber (see Section 7 (Content Distribution)).
- (this is optional in synchronous mode). The subscriber will use this has
- an indication that its subscription has been confirmed.
-
-
Additionally, this notification MUST include a Self Link Header
- HTTP header which indicates to the subscriber to what feed he has been subscribed.
- This feed url MAY be different from the feed for which the subscriber has initially subscribed,
- as the publisher MAY have considered that this one was better suited for the subscriber.
- (This is specifically useful in the context of private content with limited distribution.)
+
The subscription may be intentionally 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.
From 66d902a5c5e8a6a5dea8666b49a9ef5132436361 Mon Sep 17 00:00:00 2001
From: julien
Date: Wed, 2 May 2012 14:25:55 +0200
Subject: [PATCH 18/76] adding host-meta discovery fallback mechanism
---
pubsubhubbub-core-0.4.xml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index ffd3346..fd261c0 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -176,7 +176,9 @@
If the topic is a Atom or RSS feed, it MAY use embedded link elements
as described in Appendix B of Web Linking.
Similarly, for HTML pages, it MAY use embedded link elements as described
- in Appendix A of Web Linking.
+ in Appendix A of Web Linking. Finally, publishers
+ MAY also use the Well-Known Uniform Resource Identifiers
+ .host-meta to include the <Link> element.
From 54d2b2165f08ce4672f239ee36fa4f8ef30138e2 Mon Sep 17 00:00:00 2001
From: julien
Date: Wed, 2 May 2012 14:31:07 +0200
Subject: [PATCH 19/76] adding reference to RFC5785
---
pubsubhubbub-core-0.4.html | 6 +++++-
pubsubhubbub-core-0.4.xml | 18 ++++++++++++++++++
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/pubsubhubbub-core-0.4.html b/pubsubhubbub-core-0.4.html
index cb23484..4386f3f 100644
--- a/pubsubhubbub-core-0.4.html
+++ b/pubsubhubbub-core-0.4.html
@@ -314,7 +314,9 @@
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index fd261c0..8e3fca8 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -643,6 +643,24 @@
+
+
+
+ Defining Well-Known Uniform Resource Identifiers (URIs)
+
+
+
+
+
+
+
+
+
+
+
+
From d097c90c9ed30a7adfe5d9a10b57f9eeea60a5e6 Mon Sep 17 00:00:00 2001
From: julien
Date: Wed, 30 May 2012 10:27:46 +0200
Subject: [PATCH 20/76] mentionning an XML based feed, rather than RSS/Atom
---
pubsubhubbub-core-0.4.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index 8e3fca8..4a93d9d 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -173,7 +173,7 @@
In the absence of HTTP Link headers, subscribers MAY fall back to
other methods to discover the hub(s) and the canonical URI of the topic.
- If the topic is a Atom or RSS feed, it MAY use embedded link elements
+ If the topic is an XML based feed, it MAY use embedded link elements
as described in Appendix B of Web Linking.
Similarly, for HTML pages, it MAY use embedded link elements as described
in Appendix A of Web Linking. Finally, publishers
From 86331adda774c934e824f62fef8072dad8cea4f8 Mon Sep 17 00:00:00 2001
From: julien
Date: Wed, 30 May 2012 10:28:28 +0200
Subject: [PATCH 21/76] rebuilt the HTML feed
---
pubsubhubbub-core-0.4.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pubsubhubbub-core-0.4.html b/pubsubhubbub-core-0.4.html
index 4386f3f..5703969 100644
--- a/pubsubhubbub-core-0.4.html
+++ b/pubsubhubbub-core-0.4.html
@@ -311,7 +311,7 @@
Table of Contents
In the absence of HTTP Link headers, subscribers MAY fall back to
other methods to discover the hub(s) and the canonical URI of the topic.
- If the topic is a Atom or RSS feed, it MAY use embedded link elements
+ If the topic is an XML based feed, it MAY use embedded link elements
as described in Appendix B of Web Linking (Nottingham, M., “Web Linking,” October 2010.) [RFC5988].
Similarly, for HTML pages, it MAY use embedded link elements as described
in Appendix A of Web Linking (Nottingham, M., “Web Linking,” October 2010.) [RFC5988]. Finally, publishers
From d7119f0ca634fc39fc3bc69fad8023a88e4cbecd Mon Sep 17 00:00:00 2001
From: julien
Date: Mon, 4 Jun 2012 09:54:30 +0200
Subject: [PATCH 22/76] activate is now activated. Thank you Alkis
---
pubsubhubbub-core.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pubsubhubbub-core.xml b/pubsubhubbub-core.xml
index 8829a4e..bab7d77 100644
--- a/pubsubhubbub-core.xml
+++ b/pubsubhubbub-core.xml
@@ -369,7 +369,7 @@
understand.
Hubs MUST allow subscribers to re-request subscriptions that are
- already activate. Each subsequent request to a hub to subscribe or
+ already activated. Each subsequent request to a hub to subscribe or
unsubscribe MUST override the previous subscription state for a
specific topic URL and callback URL combination once the action is
verified. Any failures to confirm the subscription action MUST leave
From 840b1277521f742d158108e3e2b343b6ad472ca6 Mon Sep 17 00:00:00 2001
From: julien
Date: Mon, 4 Jun 2012 10:07:46 +0200
Subject: [PATCH 23/76] activate is now activated. Thank you Alkis
---
pubsubhubbub-core-0.4.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index 4a93d9d..0211080 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -236,7 +236,7 @@
understand.Hubs MUST allow subscribers to re-request subscriptions that are
- already activate. Each subsequent request to a hub to subscribe or
+ already activated. Each subsequent request to a hub to subscribe or
unsubscribe MUST override the previous subscription state for a
specific topic URL and callback URL combination once the action is
verified. Any failures to confirm the subscription action MUST leave
From 66f23fadca2d131006cd8cb051f87b333d09b716 Mon Sep 17 00:00:00 2001
From: julien
Date: Mon, 4 Jun 2012 10:12:55 +0200
Subject: [PATCH 24/76] minor working changes to clarify things. Thanks alkis
---
pubsubhubbub-core-0.4.xml | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index 0211080..17fd0ef 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -450,12 +450,12 @@
target="RFC2616">HTTP POST request from hub to the subscriber's
callback URL with the payload of the notification. This request MUST
have a Content-Type corresponding to the
- type of the topic. The hub MAY reduce the payload to a diff if its format
- allows it.
+ type of the topic. The hub MAY reduce the payload to a diff between two
+ consecutive versions if its format allows it.
The POST request must include the Self Link Header
and a Hub Link Header that correspond
- to topic's url, as well as hub.
+ to topic's url, as well as hub url respectively.
The successful response from the subscriber's callback URL MUST be an
HTTP success (2xx) code. The hub MUST consider all other subscriber
From 5eae0492f2fdb5de18dcfc0f32ca2d51099ca705 Mon Sep 17 00:00:00 2001
From: julien
Date: Mon, 4 Jun 2012 10:19:32 +0200
Subject: [PATCH 25/76] removed permanent subscriptions mentions. All
subscriptions have an expiration
---
pubsubhubbub-core-0.4.xml | 26 +++++---------------------
1 file changed, 5 insertions(+), 21 deletions(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index 17fd0ef..b542198 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -215,11 +215,10 @@
OPTIONAL. Number of seconds for
which the subscriber would like to have the subscription active. If
- not present or an empty value, the subscription will be permanent
- (or active until automatic
- refreshing removes the subscription). Hubs MAY choose to
- respect this value or not, depending on their own policies. This
- parameter MAY be present for unsubscription requests and MUST be
+ not present or an empty value, hubs SHOULD provide a default value
+ upon verification of intent.Hubs MAY
+ choose to respect this value or not, depending on their own policies.
+ This parameter MAY be present for unsubscription requests and MUST be
ignored by the hub in that case.OPTIONAL. A subscriber-provided secret
@@ -353,11 +352,7 @@
request but MAY change the value depending on the hub's policies. To
sustain a temporary subscription, the subscriber MUST re-request the
subscription on the hub before hub.lease_seconds seconds has elapsed. For
- permanent subscriptions with no hub.lease_seconds value specified, the behavior
- is different as described in the section on automatic subscription refreshing.
+ style="verb">hub.lease_seconds seconds has elapsed.
@@ -422,17 +417,6 @@
constantly returns an error, the hub MUST give up on the subscription
verification action altogether and remove the subscription.
- In the case of permanent subscriptions (with no hub.lease_seconds specified in the original
- request), the hub.lease_seconds value
- supplied by the hub in the verification request to the subscriber SHOULD
- represent how many seconds until the hub expects it will next initiate
- automatic subscription refreshing to ensure that the subscriber is still
- interested in the topic. This behavior provides the best of both worlds:
- maximum simplicity of the subscriber through infinitely-long
- subscriptions, but still garbage collectable subscriptions for hub
- hygiene.
-
From 2aa6302ef1f8e0cafebbfce51febce2459528abe Mon Sep 17 00:00:00 2001
From: alkis
Date: Mon, 4 Jun 2012 19:45:59 +0300
Subject: [PATCH 26/76] Require that hubs respond with a hub.lease_seconds.
---
pubsubhubbub-core-0.4.xml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index b542198..eb3cb03 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -215,8 +215,8 @@
OPTIONAL. Number of seconds for
which the subscriber would like to have the subscription active. If
- not present or an empty value, hubs SHOULD provide a default value
- upon verification of intent.Hubs MAY
+ not present or an empty value, hubs MUST provide a value upon
+ verification of intent.Hubs MAY
choose to respect this value or not, depending on their own policies.
This parameter MAY be present for unsubscription requests and MUST be
ignored by the hub in that case.
From a3ea1748e14a3f038a387a73b3b33fc3ded818cd Mon Sep 17 00:00:00 2001
From: julien
Date: Mon, 18 Jun 2012 16:27:48 +0200
Subject: [PATCH 27/76] url is now URL
---
pubsubhubbub-core-0.4.xml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index b542198..8394b52 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -165,9 +165,9 @@
include at least one Link Header with
rel=hub (a hub link header) as well as exactly one Link Header
with rel=self (the self link header).
- The former MUST indicate the exact url of a PubSubHubbub hub designated by the publisher.
- If more than one url is specified, it is expected that the publisher pings each
- of these urls, so the subscriber may subscribe to one or more of these.
+ The former MUST indicate the exact URL of a PubSubHubbub hub designated by the publisher.
+ If more than one URL is specified, it is expected that the publisher pings each
+ of these URLs, so the subscriber may subscribe to one or more of these.
The latter will point to the permanent URL for the resource being polled.
@@ -256,7 +256,7 @@
or HTTPS schemes. The topic URL MUST
be the one advertised by the publisher in a Hub Link Header
Header during the discovery phase. (See ).
- Hubs MAY refuse subscriptions if the topic url does not correspond to the one
+ Hubs MAY refuse subscriptions if the topic URL does not correspond to the one
advertised by the publisher. The topic URL can otherwise be free-form
following the URI spec. Hubs MUST always
decode non-reserved characters for these URL parameters; see section 2.4 on
@@ -439,7 +439,7 @@
The POST request must include the Self Link Header
and a Hub Link Header that correspond
- to topic's url, as well as hub url respectively.
+ to topic's URL, as well as hub URL respectively.
The successful response from the subscriber's callback URL MUST be an
HTTP success (2xx) code. The hub MUST consider all other subscriber
From 899e595af627c33f8a787c0b72bfc6a2c3796f32 Mon Sep 17 00:00:00 2001
From: julien
Date: Mon, 18 Jun 2012 16:36:15 +0200
Subject: [PATCH 28/76] s/HTTP Query params/request parameters/
---
pubsubhubbub-core-0.4.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index 8394b52..81bebf9 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -243,7 +243,7 @@
renew their subscriptions before the lease seconds period is over
without any interruption.
- Subscribers MAY also include additional HTTP Query params, as well as HTTP Headers
+ Subscribers MAY also include additional HTTP request parameters, as well as HTTP Headers
if they are required by the hub, or the publisher. In the context
of social web applications, it is considered good practice to include a From
HTTP header (as described in section 14.22 of Hypertext Transfer Protocol).
From 6bd2223202965dceb44dcd764f264d564b897221 Mon Sep 17 00:00:00 2001
From: julien
Date: Mon, 18 Jun 2012 16:41:44 +0200
Subject: [PATCH 29/76] rephrased based on Roman's comments
---
pubsubhubbub-core-0.4.xml | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index 417460f..6192d68 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -243,11 +243,12 @@
renew their subscriptions before the lease seconds period is over
without any interruption.
- Subscribers MAY also include additional HTTP request parameters, as well as HTTP Headers
- if they are required by the hub, or the publisher. In the context
- of social web applications, it is considered good practice to include a From
- HTTP header (as described in section 14.22 of Hypertext Transfer Protocol).
- This header should indicate on behalf of which user the subscription is being performed.
+ Subscribers MAY also include additional HTTP request parameters, as well
+ as HTTP Headers if they are required by the hub, or the publisher.
+ In the context of social web applications, it is considered good
+ practice to include a From HTTP header (as described in section 14.22
+ of Hypertext Transfer Protocol) to indicate
+ on behalf of which user the subscription is being performed.
From b3814b88b17ed4519bd52d7a0b801ab80077ed97 Mon Sep 17 00:00:00 2001
From: julien
Date: Mon, 18 Jun 2012 16:55:15 +0200
Subject: [PATCH 30/76] fixed Hub vs Self Link
---
pubsubhubbub-core-0.4.xml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index 6192d68..1479348 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -255,8 +255,8 @@
The topic and callback URLs MAY use HTTP
or HTTPS schemes. The topic URL MUST
- be the one advertised by the publisher in a Hub Link Header
- Header during the discovery phase. (See ).
+ be the one advertised by the publisher in a Self Link Header
+ during the discovery phase. (See ).
Hubs MAY refuse subscriptions if the topic URL does not correspond to the one
advertised by the publisher. The topic URL can otherwise be free-form
following the URI spec. Hubs MUST always
From 6f2a740c3774d89026433d86ef2e84ac87164741 Mon Sep 17 00:00:00 2001
From: julien
Date: Mon, 18 Jun 2012 16:56:57 +0200
Subject: [PATCH 31/76] wills are MUST
---
pubsubhubbub-core-0.4.xml | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index 1479348..1c74a43 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -362,8 +362,7 @@
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 will inform the subscriber
+ If (and when), the subscription is accepted, the hub MUST inform the subscriber
by sending an HTTP 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 17.13.4 of
@@ -374,7 +373,7 @@
subscription request.
- If (and when), the subscription is denied, the hub will inform the subscriber
+ If (and when), the subscription is denied, the hub MUST inform the subscriber
by sending an HTTP 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 17.13.4 of
@@ -389,7 +388,7 @@
Hubs may provide an additional HTTP Location header (as described in section 14.30
of Hypertext Transfer Protocol) to indicate that the
- subscriber may retry subscribing to a different hub.topic. This will allow
+ subscriber may retry subscribing to a different hub.topic. This allows
for limited distribution to specific groups, users in the context of social web
applications.
From 9e21e2d12ba5b5aa5130f9ddd0098f8e75ac83fd Mon Sep 17 00:00:00 2001
From: julien
Date: Mon, 25 Jun 2012 14:43:56 +0200
Subject: [PATCH 32/76] SHOULD is not necessary but added a good practice
---
pubsubhubbub-core-0.4.xml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index 1c74a43..1668be4 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -204,8 +204,8 @@
REQUIRED. The subscriber's callback URL
- where notifications should be delivered. The subscriber's
- callback URL SHOULD be unique for each subscription.
+ where notifications should be delivered. It is considered good practice
+ to use a unique callback url for each subscription.REQUIRED. The literal string "subscribe" or
"unsubscribe", depending on the goal of the request.
From c5e4ea22fefe7217b4e8c413f71ad16cbd35e76b Mon Sep 17 00:00:00 2001
From: julien
Date: Mon, 25 Jun 2012 14:45:38 +0200
Subject: [PATCH 33/76] removed a confusing statement about publihser's
required headers/params
---
pubsubhubbub-core-0.4.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index 1668be4..686963c 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -244,7 +244,7 @@
without any interruption.Subscribers MAY also include additional HTTP request parameters, as well
- as HTTP Headers if they are required by the hub, or the publisher.
+ as HTTP Headers if they are required by the hub.
In the context of social web applications, it is considered good
practice to include a From HTTP header (as described in section 14.22
of Hypertext Transfer Protocol) to indicate
From 3fed2f18a3a54c8c46e79e014ad67adda727f7bb Mon Sep 17 00:00:00 2001
From: julien
Date: Mon, 25 Jun 2012 15:00:37 +0200
Subject: [PATCH 34/76] wording: removed intentionnaly per Roman's comments and
upcased MAY
---
pubsubhubbub-core-0.4.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index 686963c..3f8ccfc 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -392,7 +392,7 @@
for limited distribution to specific groups, users in the context of social web
applications.
- The subscription may be intentionally denied by the hub at any point (even
+ 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.
From 779a7efb41dece7fad105883acc6269027bea969 Mon Sep 17 00:00:00 2001
From: julien
Date: Mon, 13 Aug 2012 18:46:52 +0200
Subject: [PATCH 35/76] removed automatic subscription renewal
---
pubsubhubbub-core-0.4.xml | 138 ++++++++++++++++----------------------
1 file changed, 59 insertions(+), 79 deletions(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index 3f8ccfc..49eb9ba 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -53,7 +53,7 @@
mart@degeneration.co.uk
-
+
Notifixious Inc.
@@ -65,7 +65,7 @@
- An open, simple, web-scale and decentralized pubsub protocol.
+ An open, simple, web-scale and decentralized pubsub protocol.
Anybody can play.As opposed to more developed (and more complex) pubsub specs like An owner of a topic. Notifies the hub when
- the topic feed has been updated. As in almost all pubsub systems, the
- publisher is unaware of the subscribers, if any. Other pubsub systems
+ the topic feed has been updated. As in almost all pubsub systems, the
+ publisher is unaware of the subscribers, if any. Other pubsub systems
might call the publisher the "source".An entity (person or program) that wants
@@ -134,8 +134,8 @@
sending out notifications to subscribers.A payload describing how a topic's
- contents have changed, or the full updated content.
- Depending on the topic's content type, the difference (or "delta") may be
+ contents have changed, or the full updated content.
+ Depending on the topic's content type, the difference (or "delta") may be
computed by the hub and sent to all subscribers.
@@ -160,11 +160,11 @@
- A potential subscriber initiates discovery by retrieving (GET or HEAD request)
+ A potential subscriber initiates discovery by retrieving (GET or HEAD request)
the topic to which it wants to subscribe. The HTTP response from the publisher MUST
- include at least one Link Header with
+ include at least one Link Header with
rel=hub (a hub link header) as well as exactly one Link Header
- with rel=self (the self link header).
+ with rel=self (the self link header).
The former MUST indicate the exact URL of a PubSubHubbub hub designated by the publisher.
If more than one URL is specified, it is expected that the publisher pings each
of these URLs, so the subscriber may subscribe to one or more of these.
@@ -203,7 +203,7 @@
following parameters in its body:
- REQUIRED. The subscriber's callback URL
+ REQUIRED. The subscriber's callback URL
where notifications should be delivered. It is considered good practice
to use a unique callback url for each subscription.
@@ -216,8 +216,8 @@
OPTIONAL. Number of seconds for
which the subscriber would like to have the subscription active. If
not present or an empty value, hubs MUST provide a value upon
- verification of intent.Hubs MAY
- choose to respect this value or not, depending on their own policies.
+ verification of intent.Hubs MAY
+ choose to respect this value or not, depending on their own policies.
This parameter MAY be present for unsubscription requests and MUST be
ignored by the hub in that case.
@@ -242,25 +242,25 @@
the subscription state unchanged. This is required so subscribers can
renew their subscriptions before the lease seconds period is over
without any interruption.
-
- Subscribers MAY also include additional HTTP request parameters, as well
- as HTTP Headers if they are required by the hub.
- In the context of social web applications, it is considered good
- practice to include a From HTTP header (as described in section 14.22
+
+ Subscribers MAY also include additional HTTP request parameters, as well
+ as HTTP Headers if they are required by the hub.
+ In the context of social web applications, it is considered good
+ practice to include a From HTTP header (as described in section 14.22
of Hypertext Transfer Protocol) to indicate
on behalf of which user the subscription is being performed.
- The topic and callback URLs MAY use HTTP
- or HTTPS schemes. The topic URL MUST
+ The topic and callback URLs MAY use HTTP
+ or HTTPS schemes. The topic URL MUST
be the one advertised by the publisher in a Self Link Header
during the discovery phase. (See ).
Hubs MAY refuse subscriptions if the topic URL does not correspond to the one
- advertised by the publisher. The topic URL can otherwise be free-form
- following the URI spec. Hubs MUST always
- decode non-reserved characters for these URL parameters; see section 2.4 on
+ advertised by the publisher. The topic URL can otherwise be free-form
+ following the URI spec. Hubs MUST always
+ decode non-reserved characters for these URL parameters; see section 2.4 on
"When to Encode or Decode" in the URI spec.
@@ -282,13 +282,13 @@
-
- The hub MUST respond to a subscription request with an HTTP 202 "Accepted"
- response to indicate that the request was received and will now
- be verified () and validated () by the hub. The hub SHOULD perform the
+
+ The hub MUST respond to a subscription request with an HTTP 202 "Accepted"
+ response to indicate that the request was received and will now
+ be verified () and validated () by the hub. The hub SHOULD perform the
verification of intent as soon as possible.
-
+
If a hub finds any errors in the subscription request, an
appropriate HTTP error response code (4xx or 5xx) MUST be returned. In
the event of an error, hubs SHOULD return a description of the error
@@ -335,19 +335,19 @@
The subscriber MUST confirm that the hub.topic
- corresponds to a pending subscription or unsubscription that it
- wishes to carry out. If so, the subscriber MUST respond with an HTTP
+ corresponds to a pending subscription or unsubscription that it
+ wishes to carry out. If so, the subscriber MUST respond with an HTTP
success (2xx) code with a response body equal to the hub.challenge parameter. If the subscriber does
not agree with the action, the subscriber MUST respond with a 404 "Not
Found" response.
- The hub MUST consider other server response codes (3xx, 4xx, 5xx)
+ The hub MUST consider other server response codes (3xx, 4xx, 5xx)
to mean that the verification request has failed. If the subscriber
returns an HTTP success (2xx) but the content body does not match the
hub.challenge parameter, the hub MUST also
consider verification to have failed.
-
+
Hubs MAY make the hub.lease_seconds
equal to the period the subscriber passed in their subscription
request but MAY change the value depending on the hub's policies. To
@@ -356,75 +356,55 @@
style="verb">hub.lease_seconds seconds has elapsed.
-
+
- Subscriptions MAY be validated by the Hubs who may require
+ 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 inform the subscriber
- by sending an HTTP GET request to the subscriber's
+ by sending an HTTP 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 17.13.4 of
+ query string arguments appended (format described in Section 17.13.4 of
):REQUIRED. The literal string "accepted".
- REQUIRED. The topic URL given in the corresponding
+ REQUIRED. The topic URL given in the corresponding
subscription request.
-
+
If (and when), the subscription is denied, the hub MUST inform the subscriber
- by sending an HTTP GET request to the subscriber's
+ by sending an HTTP 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 17.13.4 of
+ query string arguments appended (format described in Section 17.13.4 of
):REQUIRED. The literal string "denied".
- REQUIRED. The topic URL given in the corresponding
+ REQUIRED. The topic URL given in the corresponding
subscription request.OPTIONAL. The hub may include a reason
for which the subscription has been denied.
-
- Hubs may provide an additional HTTP Location header (as described in section 14.30
- of Hypertext Transfer Protocol) to indicate that the
+
+ Hubs may provide an additional HTTP Location header (as described in section 14.30
+ of Hypertext Transfer Protocol) to indicate that the
subscriber may retry subscribing to a different hub.topic. This allows
- for limited distribution to specific groups, users in the context of social web
+ for limited distribution to specific groups, users in the context of social web
applications.
-
+
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.
-
-
-
-
-
-
- Before a subscription expires (i.e., before hub.lease_seconds elapses), Hubs MUST recheck with
- subscribers to see if a continued subscription is desired. Hubs do this
- by sending the subscriber a verification
- request with hub.mode equal to
- subscribe. This request MUST match the original verification request
- sent to the subscriber (but with a new hub.challenge
- ).
-
- The response codes returned by the subscriber MUST be interpreted the
- same way as during a subscriber-initiated verification flow. However,
- this refresh request MUST behave like an initial subscription request;
- this means that if an auto-refresh response from the subscriber
- constantly returns an error, the hub MUST give up on the subscription
- verification action altogether and remove the subscription.
+
- The publisher MUST inform the hub it previously designated when a topic
- has been updated. The hub and the publisher CAN agree on any mechanism, as
- long as the hub is eventually able send the updated payload to the
+ The publisher MUST inform the hub it previously designated when a topic
+ has been updated. The hub and the publisher CAN agree on any mechanism, as
+ long as the hub is eventually able send the updated payload to the
subscribers.
@@ -433,10 +413,10 @@
A content distribution request is an HTTP POST request from hub to the subscriber's
callback URL with the payload of the notification. This request MUST
- have a Content-Type corresponding to the
+ have a Content-Type corresponding to the
type of the topic. The hub MAY reduce the payload to a diff between two
consecutive versions if its format allows it.
-
+
The POST request must include the Self Link Header
and a Hub Link Header that correspond
to topic's URL, as well as hub URL respectively.
@@ -474,10 +454,10 @@
same method as the hub. If the signature does not match, subscribers
MUST still return a 2xx success response to acknowledge receipt, but
locally ignore the message as invalid. Using this technique along with
- HTTPS for subscription requests enables
- simple subscribers to receive authenticated notifications from hubs
+ HTTPS for subscription requests enables
+ simple subscribers to receive authenticated notifications from hubs
without the need for subscribers to run an HTTPS server.
-
+
Please note however that this signature only ensures that the payload
was not forged. Since the notification also includes headers, these should
not be considered as safe by the subscriber, unless of course the subscriber
@@ -627,7 +607,7 @@
-
+
Defining Well-Known Uniform Resource Identifiers (URIs)
@@ -644,7 +624,7 @@
-
+
@@ -693,7 +673,7 @@
PubSubHubbub W3C Community Group. For
more information, see the
- W3C PubSubHubbub Community Group.
+ W3C PubSubHubbub Community Group.
From 495bd334bf4fff3631641cbdbe4f65c5fedd9f42 Mon Sep 17 00:00:00 2001
From: julien
Date: Mon, 13 Aug 2012 18:59:04 +0200
Subject: [PATCH 36/76] performaing validation before verification to avoid
'silent' failures, as per discussion with Roman on
https://groups.google.com/forum/#!msg/pubsubhubbub/wUOWcqQmjlQ/iggMELGTtMwJ
---
pubsubhubbub-core-0.4.xml | 72 ++++++++++++++++++---------------------
1 file changed, 33 insertions(+), 39 deletions(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index 49eb9ba..c5b7d4e 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -299,6 +299,39 @@
+
+ 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 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 17.13.4 of
+ ):
+
+ REQUIRED. The literal string "denied".
+ REQUIRED. The topic URL given in the corresponding
+ subscription request.
+ OPTIONAL. The hub may include a reason
+ for which the subscription has been denied.
+
+
+ Hubs may provide an additional HTTP Location header (as described in section 14.30
+ of Hypertext Transfer Protocol) to indicate that the
+ subscriber may retry subscribing to a different hub.topic. This allows
+ for limited distribution to specific groups, users in the context of social web
+ applications.
+
+ 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.
+
+
+
In order to prevent an attacker from creating unwanted subscriptions
on behalf of a subscriber (or unsubscribing desired ones), a hub must
@@ -357,46 +390,7 @@
-
- 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 inform the subscriber
- by sending an HTTP 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 17.13.4 of
- ):
-
- REQUIRED. The literal string "accepted".
- REQUIRED. The topic URL given in the corresponding
- subscription request.
-
- If (and when), the subscription is denied, the hub MUST inform the subscriber
- by sending an HTTP 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 17.13.4 of
- ):
-
- REQUIRED. The literal string "denied".
- REQUIRED. The topic URL given in the corresponding
- subscription request.
- OPTIONAL. The hub may include a reason
- for which the subscription has been denied.
-
-
- Hubs may provide an additional HTTP Location header (as described in section 14.30
- of Hypertext Transfer Protocol) to indicate that the
- subscriber may retry subscribing to a different hub.topic. This allows
- for limited distribution to specific groups, users in the context of social web
- applications.
-
- 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.
-
-
From 66d6bdfcd9fa874ad483eeef1fdc8916e1a5b5f0 Mon Sep 17 00:00:00 2001
From: julien
Date: Mon, 13 Aug 2012 19:01:26 +0200
Subject: [PATCH 37/76] regenrating html
---
pubsubhubbub-core-0.4.html | 241 +++++++++++++++----------------------
1 file changed, 97 insertions(+), 144 deletions(-)
diff --git a/pubsubhubbub-core-0.4.html b/pubsubhubbub-core-0.4.html
index 5703969..4f769fc 100644
--- a/pubsubhubbub-core-0.4.html
+++ b/pubsubhubbub-core-0.4.html
@@ -154,7 +154,7 @@
PubSubHubbub Core 0.4 -- Working Draft
Abstract
-
An open, simple, web-scale and decentralized pubsub protocol.
+
An open, simple, web-scale and decentralized pubsub protocol.
Anybody can play.
An owner of a topic. Notifies the hub when
- the topic feed has been updated. As in almost all pubsub systems, the
- publisher is unaware of the subscribers, if any. Other pubsub systems
+ the topic feed has been updated. As in almost all pubsub systems, the
+ publisher is unaware of the subscribers, if any. Other pubsub systems
might call the publisher the "source".
Subscriber:
@@ -264,8 +264,8 @@
Table of Contents
Notification:
A payload describing how a topic's
- contents have changed, or the full updated content.
- Depending on the topic's content type, the difference (or "delta") may be
+ contents have changed, or the full updated content.
+ Depending on the topic's content type, the difference (or "delta") may be
computed by the hub and sent to all subscribers.
@@ -299,14 +299,14 @@
Table of Contents
4.
Discovery
-
A potential subscriber initiates discovery by retrieving (GET or HEAD request)
+
A potential subscriber initiates discovery by retrieving (GET or HEAD request)
the topic to which it wants to subscribe. The HTTP response from the publisher MUST
- include at least one Link Header (Nottingham, M., “Web Linking,” October 2010.) [RFC5988] with
+ include at least one Link Header (Nottingham, M., “Web Linking,” October 2010.) [RFC5988] with
rel=hub (a hub link header) as well as exactly one Link Header (Nottingham, M., “Web Linking,” October 2010.) [RFC5988]
- with rel=self (the self link header).
- The former MUST indicate the exact url of a PubSubHubbub hub designated by the publisher.
- If more than one url is specified, it is expected that the publisher pings each
- of these urls, so the subscriber may subscribe to one or more of these.
+ with rel=self (the self link header).
+ The former MUST indicate the exact URL of a PubSubHubbub hub designated by the publisher.
+ If more than one URL is specified, it is expected that the publisher pings each
+ of these URLs, so the subscriber may subscribe to one or more of these.
The latter will point to the permanent URL for the resource being polled.
In the absence of HTTP Link headers, subscribers MAY fall back to
@@ -355,9 +355,9 @@
Table of Contents
hub.callback
-
REQUIRED. The subscriber's callback URL
- where notifications should be delivered. The subscriber's
- callback URL SHOULD be unique for each subscription.
+
REQUIRED. The subscriber's callback URL
+ where notifications should be delivered. It is considered good practice
+ to use a unique callback url for each subscription.
hub.mode
REQUIRED. The literal string "subscribe" or
@@ -370,11 +370,10 @@
Table of Contents
hub.lease_seconds
OPTIONAL. Number of seconds for
which the subscriber would like to have the subscription active. If
- not present or an empty value, the subscription will be permanent
- (or active until automatic
- refreshing (Automatic Subscription Refreshing) removes the subscription). Hubs MAY choose to
- respect this value or not, depending on their own policies. This
- parameter MAY be present for unsubscription requests and MUST be
+ not present or an empty value, hubs MUST provide a value upon
+ verification of intent (Hub Verifies Intent of the Subscriber).Hubs MAY
+ choose to respect this value or not, depending on their own policies.
+ This parameter MAY be present for unsubscription requests and MUST be
ignored by the hub in that case.
hub.secret
@@ -391,7 +390,7 @@
Table of Contents
understand.
Hubs MUST allow subscribers to re-request subscriptions that are
- already activate. Each subsequent request to a hub to subscribe or
+ already activated. Each subsequent request to a hub to subscribe or
unsubscribe MUST override the previous subscription state for a
specific topic URL and callback URL combination once the action is
verified. Any failures to confirm the subscription action MUST leave
@@ -399,11 +398,12 @@
Table of Contents
renew their subscriptions before the lease seconds period is over
without any interruption.
-
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.
+
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 subscriber MUST confirm that the hub.topic
- corresponds to a pending subscription or unsubscription that it
- wishes to carry out. If so, the subscriber MUST respond with an HTTP
+ corresponds to a pending subscription or unsubscription that it
+ wishes to carry out. If so, the subscriber MUST respond with an HTTP
success (2xx) code with a response body equal to the hub.challenge parameter. If the subscriber does
not agree with the action, the subscriber MUST respond with a 404 "Not
Found" response.
-
The hub MUST consider other server response codes (3xx, 4xx, 5xx)
+
The hub MUST consider other server response codes (3xx, 4xx, 5xx)
to mean that the verification request has failed. If the subscriber
returns an HTTP success (2xx) but the content body does not match the
hub.challenge parameter, the hub MUST also
@@ -515,105 +557,16 @@
Table of Contents
equal to the period the subscriber passed in their subscription
request but MAY change the value depending on the hub's policies. To
sustain a temporary subscription, the subscriber MUST re-request the
- subscription on the hub before hub.lease_seconds seconds has elapsed. For
- permanent subscriptions with no hub.lease_seconds value specified, the behavior
- is different as described in the section on automatic subscription refreshing (Automatic Subscription Refreshing).
-
-
-
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.
-
The subscription may be intentionally 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.
-
Before a subscription expires (i.e., before hub.lease_seconds elapses), Hubs MUST recheck with
- subscribers to see if a continued subscription is desired. Hubs do this
- by sending the subscriber a verification
- request (Hub Verifies Intent of the Subscriber) with hub.mode equal to
- subscribe. This request MUST match the original verification request
- sent to the subscriber (but with a new hub.challenge
- ).
-
-
The response codes returned by the subscriber MUST be interpreted the
- same way as during a subscriber-initiated verification flow. However,
- this refresh request MUST behave like an initial subscription request;
- this means that if an auto-refresh response from the subscriber
- constantly returns an error, the hub MUST give up on the subscription
- verification action altogether and remove the subscription.
-
-
In the case of permanent subscriptions (with no hub.lease_seconds specified in the original
- request), the hub.lease_seconds value
- supplied by the hub in the verification request to the subscriber SHOULD
- represent how many seconds until the hub expects it will next initiate
- automatic subscription refreshing to ensure that the subscriber is still
- interested in the topic. This behavior provides the best of both worlds:
- maximum simplicity of the subscriber through infinitely-long
- subscriptions, but still garbage collectable subscriptions for hub
- hygiene.
+ subscription on the hub before hub.lease_seconds seconds has elapsed.
The publisher MUST inform the hub it previously designated when a topic
- has been updated. The hub and the publisher CAN agree on any mechanism, as
- long as the hub is eventually able send the updated payload to the
+
The publisher MUST inform the hub it previously designated when a topic
+ has been updated. The hub and the publisher CAN agree on any mechanism, as
+ long as the hub is eventually able send the updated payload to the
subscribers.
@@ -623,13 +576,13 @@
Table of Contents
A content distribution request is an HTTP (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” .) [RFC2616] POST request from hub to the subscriber's
callback URL with the payload of the notification. This request MUST
- have a Content-Type corresponding to the
- type of the topic. The hub MAY reduce the payload to a diff if its format
- allows it.
+ have a Content-Type corresponding to the
+ type of the topic. The hub MAY reduce the payload to a diff between two
+ consecutive versions if its format allows it.
The POST request must include the Self Link Header
and a Hub Link Header that correspond
- to topic's url, as well as hub.
+ to topic's URL, as well as hub URL respectively.
The successful response from the subscriber's callback URL MUST be an
HTTP success (2xx) code. The hub MUST consider all other subscriber
@@ -663,8 +616,8 @@
Table of Contents
same method as the hub. If the signature does not match, subscribers
MUST still return a 2xx success response to acknowledge receipt, but
locally ignore the message as invalid. Using this technique along with
- HTTPS (Rescorla, E., “HTTP Over TLS,” May 2000.) [RFC2818] for subscription requests enables
- simple subscribers to receive authenticated notifications from hubs
+ HTTPS (Rescorla, E., “HTTP Over TLS,” May 2000.) [RFC2818] for subscription requests enables
+ simple subscribers to receive authenticated notifications from hubs
without the need for subscribers to run an HTTPS server.
Please note however that this signature only ensures that the payload
@@ -709,7 +662,7 @@
9. References
Feedback on this specification is welcomed via the
PubSubHubbub W3C Community Group. For
more information, see the
- W3C PubSubHubbub Community Group.
+ W3C PubSubHubbub Community Group.
From 7ecb9a2559cd04c4faf7a8ec736737f39fabf3f7 Mon Sep 17 00:00:00 2001
From: julien
Date: Tue, 21 Aug 2012 11:40:20 +0200
Subject: [PATCH 38/76] upcasing URL
---
pubsubhubbub-core-0.4.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index c5b7d4e..cb2268c 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -205,7 +205,7 @@
REQUIRED. The subscriber's callback URL
where notifications should be delivered. It is considered good practice
- to use a unique callback url for each subscription.
+ to use a unique callback URL for each subscription.REQUIRED. The literal string "subscribe" or
"unsubscribe", depending on the goal of the request.
From a078c3ba2d0fcf9422589d2abfd9986436b4d491 Mon Sep 17 00:00:00 2001
From: julien
Date: Tue, 21 Aug 2012 11:41:03 +0200
Subject: [PATCH 39/76] fixing whitepace
---
pubsubhubbub-core-0.4.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index cb2268c..2702317 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -216,7 +216,7 @@
OPTIONAL. Number of seconds for
which the subscriber would like to have the subscription active. If
not present or an empty value, hubs MUST provide a value upon
- verification of intent.Hubs MAY
+ verification of intent. Hubs MAY
choose to respect this value or not, depending on their own policies.
This parameter MAY be present for unsubscription requests and MUST be
ignored by the hub in that case.
From 548da2756b5730c068a39c23ac3a5b3215903e6c Mon Sep 17 00:00:00 2001
From: julien
Date: Tue, 21 Aug 2012 11:43:19 +0200
Subject: [PATCH 40/76] changed the step by step for subscriptions
---
pubsubhubbub-core-0.4.xml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index 2702317..601b957 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -186,8 +186,8 @@
immediately in sequence or have a delay.
Requesting a subscription using the hub
- Confirming the subscription was actually desired
- Receiving an acknowledgement from the hub that the subscription was accepted (OPTIONAL).
+ Validating the subscription with the publisher (OPTIONAL)
+ Confirming the subscription was actually desired by the subscriberPeriodically reconfirming the subscription is still active
From d6768015c27ff87b31c29ff4ae57e247618fd938 Mon Sep 17 00:00:00 2001
From: julien
Date: Tue, 21 Aug 2012 11:46:38 +0200
Subject: [PATCH 41/76] the hub will not validate unsubscriptions
---
pubsubhubbub-core-0.4.xml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index 601b957..5581f0e 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -192,7 +192,8 @@
Unsubscribing works in the same way, except with a single parameter
- changed to indicate the desire to unsubscribe.
+ changed to indicate the desire to unsubscribe. Also, the Hub will not validate
+ unsubscription requests with the publisher.
Subscription is initiated by the subscriber making an HTTPS
From ad31023956ff72bb086515ed9538226a3f51ba5e Mon Sep 17 00:00:00 2001
From: julien
Date: Tue, 21 Aug 2012 11:55:59 +0200
Subject: [PATCH 42/76] rephrased and reordered
---
pubsubhubbub-core-0.4.xml | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index 5581f0e..a4ef289 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -212,7 +212,7 @@
"unsubscribe", depending on the goal of the request.REQUIRED. The topic URL that the subscriber
- wishes to subscribe to.
+ wishes to subscribe to or unsubscribe from.
OPTIONAL. Number of seconds for
which the subscriber would like to have the subscription active. If
@@ -286,9 +286,9 @@
The hub MUST respond to a subscription request with an HTTP 202 "Accepted"
response to indicate that the request was received and will now
- be verified () and validated () by the hub. The hub SHOULD perform the
- verification of intent as soon as possible.
+ be validated () and verified
+ () and by the hub. The hub SHOULD perform the
+ validation and verification of intent as soon as possible.If a hub finds any errors in the subscription request, an
appropriate HTTP error response code (4xx or 5xx) MUST be returned. In
From 1efd9416a58ada12d6b4d808af6c952b3b0e4ea0 Mon Sep 17 00:00:00 2001
From: julien
Date: Tue, 21 Aug 2012 12:03:41 +0200
Subject: [PATCH 43/76] s/period/value/
---
pubsubhubbub-core-0.4.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index a4ef289..6481e8f 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -383,7 +383,7 @@
consider verification to have failed.Hubs MAY make the hub.lease_seconds
- equal to the period the subscriber passed in their subscription
+ equal to the value the subscriber passed in their subscription
request but MAY change the value depending on the hub's policies. To
sustain a temporary subscription, the subscriber MUST re-request the
subscription on the hub before
Date: Tue, 21 Aug 2012 12:04:10 +0200
Subject: [PATCH 44/76] removed subscription
---
pubsubhubbub-core-0.4.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index 6481e8f..dfd9741 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -385,7 +385,7 @@
Hubs MAY make the hub.lease_seconds
equal to the value the subscriber passed in their subscription
request but MAY change the value depending on the hub's policies. To
- sustain a temporary subscription, the subscriber MUST re-request the
+ sustain a subscription, the subscriber MUST re-request the
subscription on the hub before hub.lease_seconds seconds has elapsed.
From b49a961a88aaab275dd831f319fff3b9499c04c6 Mon Sep 17 00:00:00 2001
From: julien
Date: Fri, 10 May 2013 15:26:58 +0200
Subject: [PATCH 45/76] marking reconfirmation as optional
---
pubsubhubbub-core-0.4.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index dfd9741..79093e0 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -188,7 +188,7 @@
Requesting a subscription using the hubValidating the subscription with the publisher (OPTIONAL)Confirming the subscription was actually desired by the subscriber
- Periodically reconfirming the subscription is still active
+ Periodically reconfirming the subscription is still active (OPTIONAL)Unsubscribing works in the same way, except with a single parameter
From 7dfa4b2c9e867bb00fed59b99b13c0959f36ba73 Mon Sep 17 00:00:00 2001
From: julien
Date: Fri, 10 May 2013 15:28:17 +0200
Subject: [PATCH 46/76] removed mention of default value set up by the hub
---
pubsubhubbub-core-0.4.xml | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index 79093e0..414c749 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -215,9 +215,7 @@
wishes to subscribe to or unsubscribe from.OPTIONAL. Number of seconds for
- which the subscriber would like to have the subscription active. If
- not present or an empty value, hubs MUST provide a value upon
- verification of intent. Hubs MAY
+ which the subscriber would like to have the subscription active. Hubs MAY
choose to respect this value or not, depending on their own policies.
This parameter MAY be present for unsubscription requests and MUST be
ignored by the hub in that case.
From 0d7f7e6005fada70bd1b2a5bf87aeaed7b1f680f Mon Sep 17 00:00:00 2001
From: julien
Date: Fri, 10 May 2013 15:33:28 +0200
Subject: [PATCH 47/76] reordering stuff
---
pubsubhubbub-core-0.4.xml | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index 414c749..0df2607 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -230,6 +230,14 @@
+ Subscribers MAY also include additional HTTP request parameters, as well
+ as HTTP Headers if they are required by the hub.
+ In the context of social web applications, it is considered good
+ practice to include a From HTTP header (as described in section 14.22
+ of Hypertext Transfer Protocol) to indicate
+ on behalf of which user the subscription is being performed.
+
+
Hubs MUST ignore additional request parameters they do not
understand.
@@ -242,14 +250,6 @@
renew their subscriptions before the lease seconds period is over
without any interruption.
- Subscribers MAY also include additional HTTP request parameters, as well
- as HTTP Headers if they are required by the hub.
- In the context of social web applications, it is considered good
- practice to include a From HTTP header (as described in section 14.22
- of Hypertext Transfer Protocol) to indicate
- on behalf of which user the subscription is being performed.
-
-
The topic and callback URLs MAY use HTTP
From 656ff1373eac84cf21ea35a8af5c3f060d454c1f Mon Sep 17 00:00:00 2001
From: julien
Date: Fri, 10 May 2013 15:35:07 +0200
Subject: [PATCH 48/76] rmoved https mention for callbacks as it's redundant
and removed the redundant mention to handling query strings in callback url
---
pubsubhubbub-core-0.4.xml | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index 0df2607..f4e722e 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -269,15 +269,10 @@
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; Hubs MUST only append verification
- parameters to the existing list, if any. For event notification, the
+ requests will not be overwritten. For event notification, the
callback URL will be POSTed to including any query-string parameters
in the URL portion of the request, not as POST body parameters.
- Subscribers MAY choose to use HTTPS
- for their callback URLs if they care about the privacy of
- notifications as they come over the wire from the Hub (see )
-
From 6573a0b139d548b0eacbc191a087320f992b14c9 Mon Sep 17 00:00:00 2001
From: julien
Date: Fri, 10 May 2013 15:36:59 +0200
Subject: [PATCH 49/76] swapped verification and validation
---
pubsubhubbub-core-0.4.xml | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index f4e722e..d64e72c 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -279,9 +279,9 @@
The hub MUST respond to a subscription request with an HTTP 202 "Accepted"
response to indicate that the request was received and will now
- be validated () and verified
- () and by the hub. The hub SHOULD perform the
- validation and verification of intent as soon as possible.
+ be verified () and validated () by the hub. The hub SHOULD perform the
+ verification and validation of intent as soon as possible.
If a hub finds any errors in the subscription request, an
appropriate HTTP error response code (4xx or 5xx) MUST be returned. In
From 9b50d2d8726295887045107698036b7eab446188 Mon Sep 17 00:00:00 2001
From: julien
Date: Fri, 10 May 2013 15:40:07 +0200
Subject: [PATCH 50/76] groups or users
---
pubsubhubbub-core-0.4.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index d64e72c..fd1d507 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -317,7 +317,7 @@
Hubs may provide an additional HTTP Location header (as described in section 14.30
of Hypertext Transfer Protocol) to indicate that the
subscriber may retry subscribing to a different hub.topic. This allows
- for limited distribution to specific groups, users in the context of social web
+ for limited distribution to specific groups or users in the context of social web
applications.The subscription MAY be denied by the hub at any point (even
From 8da54b650b1d03e05fa2700959dd170d6b0bd7bb Mon Sep 17 00:00:00 2001
From: julien
Date: Fri, 10 May 2013 15:43:24 +0200
Subject: [PATCH 51/76] there may be multiple hubs
---
pubsubhubbub-core-0.4.xml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index fd1d507..beedf95 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -390,8 +390,8 @@
- The publisher MUST inform the hub it previously designated when a topic
- has been updated. The hub and the publisher CAN agree on any mechanism, as
+ The publisher MUST inform the hubs it previously designated when a topic
+ has been updated. The hub and the publisher can agree on any mechanism, as
long as the hub is eventually able send the updated payload to the
subscribers.
From 0d6844a2c2b2a9c94c7cb46cf3c3667a0293484e Mon Sep 17 00:00:00 2001
From: julien
Date: Thu, 20 Jun 2013 10:54:53 -0400
Subject: [PATCH 52/76] hubs should combine link headers
---
pubsubhubbub-core-0.4.xml | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index beedf95..0fa4d51 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -405,9 +405,11 @@
type of the topic. The hub MAY reduce the payload to a diff between two
consecutive versions if its format allows it.
- The POST request must include the Self Link Header
- and a Hub Link Header that correspond
- to topic's URL, as well as hub URL respectively.
+ The request MUST include a Link Header
+ with rel=hub pointing to the Hub as well as a Link
+ Header with rel=self set to the topic that's being updated. The Hub
+ SHOULD combine both headers into a single Link
+ Header.The successful response from the subscriber's callback URL MUST be an
HTTP success (2xx) code. The hub MUST consider all other subscriber
From cb934afb852ee8c5e79ab17fdaddfdb5ab6a63b7 Mon Sep 17 00:00:00 2001
From: julien
Date: Thu, 20 Jun 2013 11:02:18 -0400
Subject: [PATCH 53/76] replaced all HTTP instances
---
pubsubhubbub-core-0.4.xml | 36 ++++++++++++++++++++++++------------
1 file changed, 24 insertions(+), 12 deletions(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index 0fa4d51..8427940 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -99,7 +99,8 @@
- An HTTP resource URL. The
+ An HTTP resource URL. The
unit to which one can subscribe to changes. The server (A potential subscriber initiates discovery by retrieving (GET or HEAD request)
- the topic to which it wants to subscribe. The HTTP response from the publisher MUST
+ the topic to which it wants to subscribe. The HTTP response from the publisher MUST
include at least one Link Header with
rel=hub (a hub link header) as well as exactly one Link Header
with rel=self (the self link header).
@@ -171,7 +173,8 @@
The latter will point to the permanent URL for the resource being polled.
- In the absence of HTTP Link headers, subscribers MAY fall back to
+ In the absence of HTTP Link headers, subscribers MAY fall back to
other methods to discover the hub(s) and the canonical URI of the topic.
If the topic is an XML based feed, it MAY use embedded link elements
as described in Appendix B of Web Linking.
@@ -230,10 +233,13 @@
- Subscribers MAY also include additional HTTP request parameters, as well
- as HTTP Headers if they are required by the hub.
+ Subscribers MAY also include additional HTTP request parameters, as well
+ as HTTP Headers if they are required by the hub.
In the context of social web applications, it is considered good
- practice to include a From HTTP header (as described in section 14.22
+ practice to include a From HTTP header (as described in section 14.22
of Hypertext Transfer Protocol) to indicate
on behalf of which user the subscription is being performed.
@@ -277,14 +283,16 @@
- The hub MUST respond to a subscription request with an HTTP 202 "Accepted"
+ The hub MUST respond to a subscription request with an HTTP 202 "Accepted"
response to indicate that the request was received and will now
be verified () and validated () by the hub. The hub SHOULD perform the
verification and validation of intent as soon as possible.If a hub finds any errors in the subscription request, an
- appropriate HTTP error response code (4xx or 5xx) MUST be returned. In
+ appropriate HTTP 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. Hubs MAY decide to reject some
callback URLs or topic URLs based on their own policies (e.g., domain
@@ -314,7 +322,8 @@
for which the subscription has been denied.
- Hubs may provide an additional HTTP Location header (as described in section 14.30
+ Hubs may provide an additional HTTP Location header (as described in section 14.30
of Hypertext Transfer Protocol) to indicate that the
subscriber may retry subscribing to a different hub.topic. This allows
for limited distribution to specific groups or users in the context of social web
@@ -371,7 +380,8 @@
The hub MUST consider other server response codes (3xx, 4xx, 5xx)
to mean that the verification request has failed. If the subscriber
- returns an HTTP success (2xx) but the content body does not match the
+ returns an HTTP success (2xx) but the content body does not match the
hub.challenge parameter, the hub MUST also
consider verification to have failed.
@@ -412,7 +422,8 @@
Header.The successful response from the subscriber's callback URL MUST be an
- HTTP success (2xx) code. The hub MUST consider all other subscriber
+ HTTP success (2xx) code. The hub MUST consider all other subscriber
response codes as failures; that means subscribers MUST NOT use HTTP
redirects for moving subscriptions. The response body from the
subscriber MUST be ignored by the hub. Hubs SHOULD retry notifications
@@ -446,7 +457,8 @@
locally ignore the message as invalid. Using this technique along with
HTTPS for subscription requests enables
simple subscribers to receive authenticated notifications from hubs
- without the need for subscribers to run an HTTPS server.
+ without the need for subscribers to run an HTTPS
+ server.Please note however that this signature only ensures that the payload
was not forged. Since the notification also includes headers, these should
From d645acb8be1c744e32eface3f5f74bb23993b76c Mon Sep 17 00:00:00 2001
From: julien
Date: Thu, 20 Jun 2013 11:10:42 -0400
Subject: [PATCH 54/76] fixing validation problems
---
pubsubhubbub-core-0.4.xml | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index 8427940..c61ba59 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -12,7 +12,7 @@
$ xml2rfc pubsubhubbub-core-0.1.xml pubsubhubbub-core-0.1.html
-->
-
+
@@ -270,10 +270,10 @@
target="RFC3986">the URI spec.The callback URL MAY contain arbitrary query string parameters
- (e.g., ?foo=bar&red=fish). Hubs MUST
+ (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
+ style="verb">& (ampersand) character to join. Existing
parameters with names that overlap with those used by verification
requests will not be overwritten. For event notification, the
callback URL will be POSTed to including any query-string parameters
From 0773ee2c7e2081123c2410dcf411def14ccb22ab Mon Sep 17 00:00:00 2001
From: julien
Date: Thu, 20 Jun 2013 11:11:14 -0400
Subject: [PATCH 55/76] fixing dates
---
pubsubhubbub-core-0.4.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pubsubhubbub-core-0.4.xml b/pubsubhubbub-core-0.4.xml
index c61ba59..e68f9c5 100644
--- a/pubsubhubbub-core-0.4.xml
+++ b/pubsubhubbub-core-0.4.xml
@@ -62,7 +62,7 @@
-
+ An open, simple, web-scale and decentralized pubsub protocol.
From 4f3aabd97b6e402a5980d1e5f03e48500814a087 Mon Sep 17 00:00:00 2001
From: julien
Date: Thu, 20 Jun 2013 11:12:11 -0400
Subject: [PATCH 56/76] regenerated HTML
---
pubsubhubbub-core-0.4.html | 1435 +++++++++++++++++++-----------------
1 file changed, 742 insertions(+), 693 deletions(-)
diff --git a/pubsubhubbub-core-0.4.html b/pubsubhubbub-core-0.4.html
index 4f769fc..4eda9c6 100644
--- a/pubsubhubbub-core-0.4.html
+++ b/pubsubhubbub-core-0.4.html
@@ -1,700 +1,749 @@
-
-Draft: PubSubHubbub Core 0.4 -- Working Draft
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
- td.RFCbug {
- font-size: x-small; text-decoration: none;
- width: 30px; height: 30px; padding-top: 2px;
- text-align: justify; vertical-align: middle;
- background-color: #000;
- }
- td.RFCbug span.RFC {
- font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
- font-weight: bold; color: #666;
- }
- td.RFCbug span.hotText {
- font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
- font-weight: normal; text-align: center; color: #FFF;
- }
-
- table.TOCbug { width: 30px; height: 15px; }
- td.TOCbug {
- text-align: center; width: 30px; height: 15px;
- color: #FFF; background-color: #900;
- }
- td.TOCbug a {
- font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
- font-weight: bold; font-size: x-small; text-decoration: none;
- color: #FFF; background-color: transparent;
- }
-
- td.header {
- font-family: arial, helvetica, sans-serif; font-size: x-small;
- vertical-align: top; width: 33%;
- color: #FFF; background-color: #666;
- }
- td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
- td.author-text { font-size: x-small; }
-
- /* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
- a.info {
- /* This is the key. */
- position: relative;
- z-index: 24;
- text-decoration: none;
- }
- a.info:hover {
- z-index: 25;
- color: #FFF; background-color: #900;
- }
- a.info span { display: none; }
- a.info:hover span.info {
- /* The span will display just on :hover state. */
- display: block;
- position: absolute;
- font-size: smaller;
- top: 2em; left: -5em; width: 15em;
- padding: 2px; border: 1px solid #333;
- color: #900; background-color: #EEE;
- text-align: left;
- }
-
- a { font-weight: bold; }
- a:link { color: #900; background-color: transparent; }
- a:visited { color: #633; background-color: transparent; }
- a:active { color: #633; background-color: transparent; }
-
- p { margin-left: 2em; margin-right: 2em; }
- p.copyright { font-size: x-small; }
- p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
- table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
- td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }
-
- ol.text { margin-left: 2em; margin-right: 2em; }
- ul.text { margin-left: 2em; margin-right: 2em; }
- li { margin-left: 3em; }
-
- /* RFC-2629 s and s. */
- em { font-style: italic; }
- strong { font-weight: bold; }
- dfn { font-weight: bold; font-style: normal; }
- cite { font-weight: normal; font-style: normal; }
- tt { color: #036; }
- tt, pre, pre dfn, pre em, pre cite, pre span {
- font-family: "Courier New", Courier, monospace; font-size: small;
- }
- pre {
- text-align: left; padding: 4px;
- color: #000; background-color: #CCC;
- }
- pre dfn { color: #900; }
- pre em { color: #66F; background-color: #FFC; font-weight: normal; }
- pre .key { color: #33C; font-weight: bold; }
- pre .id { color: #900; }
- pre .str { color: #000; background-color: #CFF; }
- pre .val { color: #066; }
- pre .rep { color: #909; }
- pre .oth { color: #000; background-color: #FCF; }
- pre .err { background-color: #FCC; }
-
- /* RFC-2629 s. */
- table.all, table.full, table.headers, table.none {
- font-size: small; text-align: center; border-width: 2px;
- vertical-align: top; border-collapse: collapse;
- }
- table.all, table.full { border-style: solid; border-color: black; }
- table.headers, table.none { border-style: none; }
- th {
- font-weight: bold; border-color: black;
- border-width: 2px 2px 3px 2px;
- }
- table.all th, table.full th { border-style: solid; }
- table.headers th { border-style: none none solid none; }
- table.none th { border-style: none; }
- table.all td {
- border-style: solid; border-color: #333;
- border-width: 1px 2px;
- }
- table.full td, table.headers td, table.none td { border-style: none; }
-
- hr { height: 1px; }
- hr.insert {
- width: 80%; border-style: none; border-width: 0;
- color: #CCC; background-color: #CCC;
- }
--->
-
-
An open, simple, web-scale and decentralized pubsub protocol.
- Anybody can play.
-
-
As opposed to more developed (and more complex) pubsub specs like Jabber Publish-Subscribe (Millard, P., Saint-Andre, P., and R. Meijer, “Publish-Subscribe,” .) [XEP‑0060] this spec's base profile
- (the barrier-to-entry to speak it) is dead simple. The fancy bits required
- for high-volume publishers and subscribers are optional. The base profile
- is HTTP-based, as opposed to XMPP (see more on this below).
-
-
To dramatically simplify this spec in several places where we had to
- choose between supporting A or B, we took it upon ourselves to say "only
- A", rather than making it an implementation decision.
-
-
We offer this spec in hopes that it fills a need or at least advances
- the state of the discussion in the pubsub space. Polling sucks. We think
- a decentralized pubsub layer is a fundamental, missing layer in the
- Internet architecture today and its existence, more than just enabling
- the obvious lower latency feed readers, would enable many cool
- applications, most of which we can't even imagine. But we're looking
- forward to decentralized social networking.
-
-
Table of Contents
-
-1.
-Notation and Conventions
-2.
-Definitions
-3.
-High-level protocol flow
-4.
-Discovery
-5.
-Subscribing and Unsubscribing
- 5.1.
-Subscriber Sends Subscription Request
- 5.2.
-Subscription Validation
- 5.3.
-Hub Verifies Intent of the Subscriber
-6.
-Publishing
-7.
-Content Distribution
-8.
-Authenticated Content Distribution
-9.
-References
-Appendix A.
-Specification Feedback
-§
-Authors' Addresses
-
An owner of a topic. Notifies the hub when
- the topic feed has been updated. As in almost all pubsub systems, the
- publisher is unaware of the subscribers, if any. Other pubsub systems
- might call the publisher the "source".
-
-
Subscriber:
-
An entity (person or program) that wants
- to be notified of changes on a topic. The subscriber must be
- directly network-accessible and is identified by its Subscriber
- Callback URL.
-
-
Subscription:
-
A unique relation to a topic by a
- subscriber that indicates it should receive updates for that topic. A
- subscription's unique key is the tuple (Topic URL, Subscriber Callback
- URL). Subscriptions may (at the hub's decision) have expiration times
- akin to DHCP leases which must be periodically renewed.
-
An event that causes updates to multiple topics.
- For each event that happens (e.g. "Brad posted to the Linux
- Community."), multiple topics could be affected (e.g. "Brad posted."
- and "Linux community has new post"). Publisher events cause topics to
- be updated and the hub looks up all subscriptions for affected topics,
- sending out notifications to subscribers.
-
-
Notification:
-
A payload describing how a topic's
- contents have changed, or the full updated content.
- Depending on the topic's content type, the difference (or "delta") may be
- computed by the hub and sent to all subscribers.
-
Publishers notify their hub(s) URLs when their topic(s)
- change.
-
-
Subscribers POST to one or more of the advertised hubs for a
- topic they're interested in. Alternatively, some hubs may offer
- auto-polling capability, to let {their,any} subscribers subscribe to
- topics which don't advertise a hub.
-
-
The hub caches minimal metadata (id, data, entry digest) about
- each topic's previous state. When the hub re-fetches a topic feed (on
- its own initiative or as a result of a publisher's ping) and finds a
- delta, it enqueues a notification to all registered subscribers.
-
+
+
+
+
+
Network Working Group
+
B. Fitzpatrick
+
+
+
Internet-Draft
+
B. Slatkin
+
+
+
Intended status: Informational
+
Google, Inc
+
+
+
Expires: December 22, 2013
+
M. Atkins
+
+
+
+
Six Apart Ltd.
+
+
+
+
J. Genestoux
+
+
+
+
Notifixious Inc.
+
+
+
+
June 20, 2013
+
+
+
+
+
+
+
PubSubHubbub Core 0.4 -- Working Draft
+ pubsubhubbub-core-0.4.xml
An open, simple, web-scale and decentralized pubsub protocol. Anybody can play.
+
As opposed to more developed (and more complex) pubsub specs like Jabber Publish-Subscribe [XEP-0060] this spec's base profile (the barrier-to-entry to speak it) is dead simple. The fancy bits required for high-volume publishers and subscribers are optional. The base profile is HTTP-based, as opposed to XMPP (see more on this below).
+
To dramatically simplify this spec in several places where we had to choose between supporting A or B, we took it upon ourselves to say "only A", rather than making it an implementation decision.
+
We offer this spec in hopes that it fills a need or at least advances the state of the discussion in the pubsub space. Polling sucks. We think a decentralized pubsub layer is a fundamental, missing layer in the Internet architecture today and its existence, more than just enabling the obvious lower latency feed readers, would enable many cool applications, most of which we can't even imagine. But we're looking forward to decentralized social networking.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
+
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
+
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
+
This Internet-Draft will expire on December 22, 2013.
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
+
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Domain name examples use [RFC2606].
An HTTP [RFC2616] resource URL. The unit to which one can subscribe to changes.
+
Hub ("the hub"):
+
The server (URL [RFC3986]) which implements both sides of this protocol. Any hub MAY implement its own policies on who can use it.
+
Publisher:
+
An owner of a topic. Notifies the hub when the topic feed has been updated. As in almost all pubsub systems, the publisher is unaware of the subscribers, if any. Other pubsub systems might call the publisher the "source".
+
Subscriber:
+
An entity (person or program) that wants to be notified of changes on a topic. The subscriber must be directly network-accessible and is identified by its Subscriber Callback URL.
+
Subscription:
+
A unique relation to a topic by a subscriber that indicates it should receive updates for that topic. A subscription's unique key is the tuple (Topic URL, Subscriber Callback URL). Subscriptions may (at the hub's decision) have expiration times akin to DHCP leases which must be periodically renewed.
+
Subscriber Callback URL:
+
The URL [RFC3986] at which a subscriber wishes to receive notifications.
+
Event:
+
An event that causes updates to multiple topics. For each event that happens (e.g. "Brad posted to the Linux Community."), multiple topics could be affected (e.g. "Brad posted." and "Linux community has new post"). Publisher events cause topics to be updated and the hub looks up all subscriptions for affected topics, sending out notifications to subscribers.
+
Notification:
+
A payload describing how a topic's contents have changed, or the full updated content. Depending on the topic's content type, the difference (or "delta") may be computed by the hub and sent to all subscribers.
Publishers notify their hub(s) URLs when their topic(s) change.
+
Subscribers POST to one or more of the advertised hubs for a topic they're interested in. Alternatively, some hubs may offer auto-polling capability, to let {their,any} subscribers subscribe to topics which don't advertise a hub.
+
The hub caches minimal metadata (id, data, entry digest) about each topic's previous state. When the hub re-fetches a topic feed (on its own initiative or as a result of a publisher's ping) and finds a delta, it enqueues a notification to all registered subscribers.
A potential subscriber initiates discovery by retrieving (GET or HEAD request)
- the topic to which it wants to subscribe. The HTTP response from the publisher MUST
- include at least one Link Header (Nottingham, M., “Web Linking,” October 2010.) [RFC5988] with
- rel=hub (a hub link header) as well as exactly one Link Header (Nottingham, M., “Web Linking,” October 2010.) [RFC5988]
- with rel=self (the self link header).
- The former MUST indicate the exact URL of a PubSubHubbub hub designated by the publisher.
- If more than one URL is specified, it is expected that the publisher pings each
- of these URLs, so the subscriber may subscribe to one or more of these.
- The latter will point to the permanent URL for the resource being polled.
-
A potential subscriber initiates discovery by retrieving (GET or HEAD request) the topic to which it wants to subscribe. The HTTP [RFC2616] response from the publisher MUST include at least one Link Header [RFC5988] with rel=hub (a hub link header) as well as exactly one Link Header [RFC5988] with rel=self (the self link header). The former MUST indicate the exact URL of a PubSubHubbub hub designated by the publisher. If more than one URL is specified, it is expected that the publisher pings each of these URLs, so the subscriber may subscribe to one or more of these. The latter will point to the permanent URL for the resource being polled.
+
In the absence of HTTP [RFC2616] Link headers, subscribers MAY fall back to other methods to discover the hub(s) and the canonical URI of the topic. If the topic is an XML based feed, it MAY use embedded link elements as described in Appendix B of Web Linking [RFC5988]. Similarly, for HTML pages, it MAY use embedded link elements as described in Appendix A of Web Linking [RFC5988]. Finally, publishers MAY also use the Well-Known Uniform Resource Identifiers [RFC5785] .host-meta to include the <Link> element.
REQUIRED. The subscriber's callback URL
- where notifications should be delivered. It is considered good practice
- to use a unique callback url for each subscription.
-
-
hub.mode
-
REQUIRED. The literal string "subscribe" or
- "unsubscribe", depending on the goal of the request.
-
-
hub.topic
-
REQUIRED. The topic URL that the subscriber
- wishes to subscribe to.
-
-
hub.lease_seconds
-
OPTIONAL. Number of seconds for
- which the subscriber would like to have the subscription active. If
- not present or an empty value, hubs MUST provide a value upon
- verification of intent (Hub Verifies Intent of the Subscriber).Hubs MAY
- choose to respect this value or not, depending on their own policies.
- This parameter MAY be present for unsubscription requests and MUST be
- ignored by the hub in that case.
-
Hubs MUST ignore additional request parameters they do not
- understand.
-
-
Hubs MUST allow subscribers to re-request subscriptions that are
- already activated. Each subsequent request to a hub to subscribe or
- unsubscribe MUST override the previous subscription state for a
- specific topic URL and callback URL combination once the action is
- verified. Any failures to confirm the subscription action MUST leave
- the subscription state unchanged. This is required so subscribers can
- renew their subscriptions before the lease seconds period is over
- without any interruption.
-
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; Hubs MUST only append verification
- parameters to the existing list, if any. For event notification, the
- callback URL will be POSTed to including any query-string parameters
- in the URL portion of the request, not as POST body parameters.
-
If a hub finds any errors in the subscription request, an
- appropriate HTTP 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. Hubs MAY decide to reject some
- callback URLs or topic URLs based on their own policies (e.g., domain
- authorization, topic URL port numbers).
-
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.
-
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.
-
In order to prevent an attacker from creating unwanted subscriptions
- on behalf of a subscriber (or unsubscribing desired ones), a hub must
- ensure that the subscriber did indeed send the subscription request.
-
REQUIRED. The literal string "subscribe" or
- "unsubscribe", which matches the original request to the hub from
- the subscriber.
-
-
hub.topic
-
REQUIRED. The topic URL given in the
- corresponding subscription request.
-
-
hub.challenge
-
REQUIRED. A hub-generated, random string
- that MUST be echoed by the subscriber to verify the
- subscription.
-
-
hub.lease_seconds
-
REQUIRED/OPTIONAL. The
- hub-determined number of seconds that the subscription will stay
- active before expiring, measured from the time the verification
- request was made from the hub to the subscriber. Hubs MUST supply
- this parameter for subscription requests. This parameter MAY be
- present for unsubscribe requests and MUST be ignored by subscribers
- during unsubscription.
-
The subscriber MUST confirm that the hub.topic
- corresponds to a pending subscription or unsubscription that it
- wishes to carry out. If so, the subscriber MUST respond with an HTTP
- success (2xx) code with a response body equal to the hub.challenge parameter. If the subscriber does
- not agree with the action, the subscriber MUST respond with a 404 "Not
- Found" response.
-
-
The hub MUST consider other server response codes (3xx, 4xx, 5xx)
- to mean that the verification request has failed. If the subscriber
- returns an HTTP success (2xx) but the content body does not match the
- hub.challenge parameter, the hub MUST also
- consider verification to have failed.
-
-
Hubs MAY make the hub.lease_seconds
- equal to the period the subscriber passed in their subscription
- request but MAY change the value depending on the hub's policies. To
- sustain a temporary subscription, the subscriber MUST re-request the
- subscription on the hub before hub.lease_seconds seconds has elapsed.
-
The publisher MUST inform the hub it previously designated when a topic
- has been updated. The hub and the publisher CAN agree on any mechanism, as
- long as the hub is eventually able send the updated payload to the
- subscribers.
-
The POST request must include the Self Link Header
- and a Hub Link Header that correspond
- to topic's URL, as well as hub URL respectively.
-
-
The successful response from the subscriber's callback URL MUST be an
- HTTP success (2xx) code. The hub MUST consider all other subscriber
- response codes as failures; that means subscribers MUST NOT use HTTP
- redirects for moving subscriptions. The response body from the
- subscriber MUST be ignored by the hub. Hubs SHOULD retry notifications
- repeatedly until successful (up to some reasonable maximum over a
- reasonable time period). Subscribers SHOULD respond to notifications 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.
-
When subscribers receive a content distribution request with the
- X-Hub-Signature header specified, they
- SHOULD recompute the SHA1 signature with the shared secret using the
- same method as the hub. If the signature does not match, subscribers
- MUST still return a 2xx success response to acknowledge receipt, but
- locally ignore the message as invalid. Using this technique along with
- HTTPS (Rescorla, E., “HTTP Over TLS,” May 2000.) [RFC2818] for subscription requests enables
- simple subscribers to receive authenticated notifications from hubs
- without the need for subscribers to run an HTTPS server.
-
-
Please note however that this signature only ensures that the payload
- was not forged. Since the notification also includes headers, these should
- not be considered as safe by the subscriber, unless of course the subscriber
- uses HTTPS (Rescorla, E., “HTTP Over TLS,” May 2000.) [RFC2818] callbacks.
-
Feedback on this specification is welcomed via the
- PubSubHubbub W3C Community Group. For
- more information, see the
- W3C PubSubHubbub Community Group.
-
-
Unsubscribing works in the same way, except with a single parameter changed to indicate the desire to unsubscribe. Also, the Hub will not validate unsubscription requests with the publisher.
Subscription is initiated by the subscriber making an HTTPS [RFC2616] or HTTP [RFC2616] POST request to the hub URL. This request has a Content-Type of application/x-www-form-urlencoded (described in Section 17.13.4 of [W3C.REC-html401-19991224]) and the following parameters in its body:
+
+
+
+
hub.callback
+
REQUIRED. The subscriber's callback URL where notifications should be delivered. It is considered good practice to use a unique callback URL for each subscription.
+
hub.mode
+
REQUIRED. The literal string "subscribe" or "unsubscribe", depending on the goal of the request.
+
hub.topic
+
REQUIRED. The topic URL that the subscriber wishes to subscribe to or unsubscribe from.
+
hub.lease_seconds
+
OPTIONAL. Number of seconds for which the subscriber would like to have the subscription active. Hubs MAY choose to respect this value or not, depending on their own policies. This parameter MAY be present for unsubscription requests and MUST be ignored by the hub in that case.
+
hub.secret
+
OPTIONAL. A subscriber-provided secret string that will be used to compute an HMAC digest for authorized content distribution [authednotify]. If not supplied, the HMAC digest will not be present for content distribution requests. This parameter SHOULD only be specified when the request was made over HTTPS [RFC2818]. This parameter MUST be less than 200 bytes in length.
+
+
Subscribers MAY also include additional HTTP [RFC2616] request parameters, as well as HTTP [RFC2616] Headers if they are required by the hub. In the context of social web applications, it is considered good practice to include a From HTTP [RFC2616] header (as described in section 14.22 of Hypertext Transfer Protocol [RFC2616]) to indicate on behalf of which user the subscription is being performed.
+
Hubs MUST ignore additional request parameters they do not understand.
+
Hubs MUST allow subscribers to re-request subscriptions that are already activated. Each subsequent request to a hub to subscribe or unsubscribe MUST override the previous subscription state for a specific topic URL and callback URL combination once the action is verified. Any failures to confirm the subscription action MUST leave the subscription state unchanged. This is required so subscribers can renew their subscriptions before the lease seconds period is over without any interruption.
The topic and callback URLs MAY use HTTP [RFC2616] or HTTPS [RFC2818] schemes. The topic URL MUST be the one advertised by the publisher in a Self Link Header during the discovery phase. (See Section 4). Hubs MAY refuse subscriptions if the topic URL does not correspond to the one advertised by the publisher. The topic URL can otherwise be free-form following the URI spec [RFC3986]. Hubs MUST always decode non-reserved characters for these URL parameters; see section 2.4 on "When to Encode or Decode" in the URI spec [RFC3986].
+
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. For event notification, the callback URL will be POSTed to including any query-string parameters in the URL portion of the request, not as POST body parameters.
The hub MUST respond to a subscription request with an HTTP [RFC2616] 202 "Accepted" response to indicate that the request was received and will now be verified (Section 5.3) and validated (Section 5.2) by the hub. The hub SHOULD perform the verification and validation of intent as soon as possible.
+
If a hub finds any errors in the subscription request, an appropriate HTTP [RFC2616] 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. Hubs MAY decide to reject some callback URLs or topic URLs based on their own policies (e.g., domain authorization, topic URL port numbers).
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 [verifysub] of the subscriber.
+
If (and when), the subscription is denied, the hub MUST inform the subscriber by sending an HTTP [RFC2616] 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 17.13.4 of [W3C.REC-html401-19991224]):
+
+
+
+
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.
+
+
Hubs may provide an additional HTTP [RFC2616] Location header (as described in section 14.30 of Hypertext Transfer Protocol [RFC2616]) to indicate that the subscriber may retry subscribing to a different hub.topic. This allows for limited distribution to specific groups or users in the context of social web applications.
+
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.
In order to prevent an attacker from creating unwanted subscriptions on behalf of a subscriber (or unsubscribing desired ones), a hub must ensure that the subscriber did indeed send the subscription request.
+
The hub verifies a subscription request by sending an HTTP [RFC2616] 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 17.13.4 of [W3C.REC-html401-19991224]):
+
+
+
+
hub.mode
+
REQUIRED. The literal string "subscribe" or "unsubscribe", which matches the original request to the hub from the subscriber.
+
hub.topic
+
REQUIRED. The topic URL given in the corresponding subscription request.
+
hub.challenge
+
REQUIRED. A hub-generated, random string that MUST be echoed by the subscriber to verify the subscription.
+
hub.lease_seconds
+
REQUIRED/OPTIONAL. The hub-determined number of seconds that the subscription will stay active before expiring, measured from the time the verification request was made from the hub to the subscriber. Hubs MUST supply this parameter for subscription requests. This parameter MAY be present for unsubscribe requests and MUST be ignored by subscribers during unsubscription.
The subscriber MUST confirm that the hub.topic corresponds to a pending subscription or unsubscription that it wishes to carry out. If so, the subscriber MUST respond with an HTTP success (2xx) code with a response body equal to the hub.challenge parameter. If the subscriber does not agree with the action, the subscriber MUST respond with a 404 "Not Found" response.
+
The hub MUST consider other server response codes (3xx, 4xx, 5xx) to mean that the verification request has failed. If the subscriber returns an HTTP [RFC2616] success (2xx) but the content body does not match the hub.challenge parameter, the hub MUST also consider verification to have failed.
+
Hubs MAY make the hub.lease_seconds equal to the value the subscriber passed in their subscription request but MAY change the value depending on the hub's policies. To sustain a subscription, the subscriber MUST re-request the subscription on the hub before hub.lease_seconds seconds has elapsed.
The publisher MUST inform the hubs it previously designated when a topic has been updated. The hub and the publisher can agree on any mechanism, as long as the hub is eventually able send the updated payload to the subscribers.
A content distribution request is an HTTP [RFC2616] POST request from hub to the subscriber's callback URL with the payload of the notification. This request MUST have a Content-Type corresponding to the type of the topic. The hub MAY reduce the payload to a diff between two consecutive versions if its format allows it.
+
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. The Hub SHOULD combine both headers into a single Link Header [RFC5988].
+
The successful response from the subscriber's callback URL MUST be an HTTP [RFC2616] success (2xx) code. The hub MUST consider all other subscriber response codes as failures; that means subscribers MUST NOT use HTTP redirects for moving subscriptions. The response body from the subscriber MUST be ignored by the hub. Hubs SHOULD retry notifications repeatedly until successful (up to some reasonable maximum over a reasonable time period). Subscribers SHOULD respond to notifications 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.
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 sha1=signature where signature is a 40-byte, hexadecimal representation of a SHA1 signature [RFC3174]. The signature MUST be computed using the HMAC algorithm [RFC2104] with the request body as the data and the hub.secret as the key.
+
When subscribers receive a content distribution request with the X-Hub-Signature header specified, they SHOULD recompute the SHA1 signature with the shared secret using the same method as the hub. If the signature does not match, subscribers MUST still return a 2xx success response to acknowledge receipt, but locally ignore the message as invalid. Using this technique along with HTTPS [RFC2818] for subscription requests enables simple subscribers to receive authenticated notifications from hubs without the need for subscribers to run an HTTPS [RFC2818] server.
+
Please note however that this signature only ensures that the payload was not forged. Since the notification also includes headers, these should not be considered as safe by the subscriber, unless of course the subscriber uses HTTPS [RFC2818] callbacks.