-
Notifications
You must be signed in to change notification settings - Fork 50
Description
The following sections of the spec appear to bring one to the conclusion that renewals are to be avoided, despite being supported. Emphasis mine:
1. Definitions:
A subscription's unique key is the tuple (Topic URL, Subscriber Callback URL).
5.1 Subscriber Sends Subscription Request:
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, but only once the action is verified (Section 4.3). If verification fails, the subscription state MUST be left unchanged. This is required so subscribers can renew their subscriptions before the lease seconds period is over without any interruption.
5.1.1 Subscription Parameter Details
Additionally, the callback SHOULD be unique (not re-used for multiple hubs) and changed when subscriptions are renewed.
B.4:
Recommend not reusing callback URLs on subscription renewals
How are subscribers supposed to change the callback URL of a subscription to follow the recommendation of 5.1.1 when there is no parameter in 5.1 that informs the hub how to identify the subscription being renewed (topic, old callback)
? The spec says that hubs must accept re-requests that renew existing subscriptions (with a particular callback), but the recommendation of 5.1.1 says to not reuse callbacks when renewing. Unless I have missed something, it does not seem possible to change the callback in a renewal request.