You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
I ran into more or less the same quandary while implementing renewal in a Subscriber. If callback URLs are not reused on renewals, there's no way for the Hub to know that the new subscription overrides the old.
A subscriber could avoid reusing a callback URL by explicitly unsubscribing the old callback URL when the new one is verified, but that potentially leaves a period of overlap, which seems wrong. And it's not technically the same thing as a renewal.
I'm going to ignore "callback SHOULD be [...] changed when subscriptions are renewed" for my Subscriber until this is clarified somehow.
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:
5.1 Subscriber Sends Subscription Request:
5.1.1 Subscription Parameter Details
B.4:
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.The text was updated successfully, but these errors were encountered: