search

pubsubhubbub / PubSubHubbub

The PubSubHubbub protocol specification.
http://pubsubhubbub.github.io/PubSubHubbub
602 stars 122 forks source link

PubSubHubbub Core 0.4: Acceptance of a subscription request #29

Closed cweiske closed 9 years ago

cweiske commented 9 years ago

Does the client/subscriber have to see a subscription as being "accepted" until he gets a "denied" state on his callback URL?

Why is there no "subscription accepted" call to the callback URL?

Also, why does the callback not get the signature passed for requests with hub.mode=denied? Bad people could fake unsubscription confirmations without it.

julien51 commented 9 years ago

There's no need for a "subscription accepted" call for the subscriber for the exact same reason given in #27: the subscriber has the last word. If the subscriber accepts the verification of intent, the subscription should be considered successful (hence no need to inform him of the same thing twice).

Your second point may be valid though (I have to think more about it!). However, I think the subscriber should not consider the subscription successful until he's confirm the intent. So, if it gets a denial first, and then a verification of intent, the subscriber could/should(?) consider that his subscription has eventually been validated by the publisher.

cweiske commented 9 years ago

If the subscriber accepts the verification of intent, the subscription should be considered successful

This is only valid if there is no bug in the hub software :) The connection may drop, so that the hub does not receive the verification response from the subscriber. The proxy the subscriber is behind has a problem and fails to deliver the response... It's the internet.

julien51 commented 9 years ago

Well, yeah, but that's the spec :) This spec (like any other) is only intended to describe algorithm which are supposed to be implemented correctly.

cweiske commented 9 years ago

But the spec can make a technology susceptible against failures or not. In this case, the missing confirmation call adds a level of uncertainty.

julien51 commented 9 years ago

Sure... but I think that "bugs" in the hub can also happen if the hubs sends a extra "Acceptance of a subscription request".

julien51 commented 9 years ago

As for

The connection may drop, so that the hub does not receive the verification response from the subscriber. The proxy the subscriber is behind has a problem and fails to deliver the response... It's the internet.

If the hub does not get a 200 from the subscriber (+ echo of challenge), the hub will considered the subscription failed and the subscriber should also consider it not successful as long as it has not received a verification of intent to which it has responded 200 + echo-ed the challenge.

cweiske commented 9 years ago

Maybe the spec should have a sentence that a subscription has to be seen as "accepted" by the subscriber if the verification of intent has been answered successfully.