Suggestion: Use HTTP 410 Gone
Alkarex opened this issue · 9 comments
An idea for your consideration: there are cases when an unsubscribe process does not work well (either due to client, or server, or both), and the subscriber continues to receive updates.
In this case, the subscriber might try to re-unsubscribe after receiving such updates, if the needed information to do so is available.
In FreshRSS, we return an HTTP/1.1 410 Gone status when we receive updates for which we have no subscription anymore, and would expect the publisher to cancel our subscription after receiving such a code.
https://github.com/FreshRSS/FreshRSS/blob/0bc59ba140b19d8e0a1762e5ffed66b0c61bd322/p/api/pshb.php#L57-L59
https://github.com/FreshRSS/FreshRSS/blob/0bc59ba140b19d8e0a1762e5ffed66b0c61bd322/p/api/pshb.php#L155-L157
Ah, I can see that there has just been a related discussion, which I had missed #103
This one is a bit more precise
More points:
- Sending a new unsubscribe request for each (unwanted) notification does not seem to scale well. (Risks of DOS?)
- From the subscriber side (e.g. FreshRSS), we erase the subscription information (e.g. keys) after an unsubscription. If we still receive an update after that, we know whether the request looks like something legitimate, but we cannot be sure, and therefore cannot blindly use the
hubandselfprovided in the update to unsubscribe again (security risks?).
That's interesting that you independently decided to return HTTP 410 in that situation.
and therefore cannot blindly use the hub and self provided in the update to unsubscribe again
That's a great point. It would definitely be a security hole for the subscriber to make an unsubscription request in that situation.
For now, there is nothing wrong with returning HTTP 410 (thanks to #102), and perhaps we will see hubs start respecting that. fwiw I just updated my hub, Switchboard, to deactivate the subscription if a subscriber returns 410.
Here is some proposed text to add this to the spec.
Before:
The successful response from the subscriber's callback URL MUST be an HTTP [[!RFC7231]] 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.
After:
The subscriber's callback URL MUST return an HTTP [[!RFC7231]] 2xx response code to indicate a success. The subscriber's callback URL MAY return an HTTP 410 code to indicate that the subscription has been deleted, and the hub SHOULD terminate the subscription if it receives that code as a response. The hub MUST consider all other subscriber response codes as failures; that means subscribers MUST NOT use HTTP redirects for moving subscriptions.
I am worried about "the hub SHOULD terminate" which I would replace by "the hub MAY terminate".
I'm okay with a "MAY" here.
Ok good, then let's do it!
This has been added! https://w3c.github.io/websub/#content-distribution
@Alkarex please close the issue if this addresses it for you!