Hi all, one of the topics we discussed in London but after discussing with Brett I'm not sure we have complete consensus on was that of subscription status. There are basically four valid response codes that a hub can offer a subscriber in response to a hub.mode=subscribe request:
202: "I've accepted your request, it's not yet verified and definitely not active. Do not expect to receive updates." 204: "I've verified your request." 409: "Your request was rejected." 400/401/403 (implied): "Your request failed due to a temporary verification error and is pending." Notably missing is a response code that means "Your subscription is active and you should be receiving updates," something I hinted at with my hub.mode=query approach[1] The proposal Alexis made in London was to adopt the following semantics: 202 should always mean "I heard your request" 204 should always mean "I have enacted your request" and drop any indication of verification state – in this approach, 202 means "maybe verified, definitely not active", whereas 204 means "definitely active." I think no matter what approach is used, the fundamental need here is real; it becomes more important when considering policy-based subscription approval that is distinct from simple callback verification. For example, a hub's policy may be to have a human manually verify each subscription. A strict reading of the current v0.3 revision would dictate that the hub must return 204 to a functional subscriber; that subscriber now reasonably expects to receive updates where there are none, and when they don't, will proceed with any number of troubleshooting steps (inevitably leading to frustration on the part of the developer). There are a few approaches to fixing this: - A header, e.g., X-Subscription-State, to accompany 204 responses (valid values: none, pending, subscribed). - A hub.mode=query request (requires an extra round trip, may be less cacheable). - An alternate response code (e.g., 200 or 201) to indicate "Subscription is verified and active." - Alexis' approach, a simplified semantic replacing the "verified" state (204) with "subscribed". - Other? In all cases, subscription (re-)requests are idempotent so long as the subscription is active or pending. That is to say, requests can be made by the subscriber as many times as the subscriber pleases (or as many times as the publisher allows before getting grumpy ;-) ) in order to discover the current state of the subscription. b. [1] http://groups.google.com/group/pubsubhubbub/browse_thread/thread/99448039268a4fb5/c5a91c2a2b9d0a7e?lnk=gst
