I see where you're going with this, but I have concerns. I just checked my own code and realized that I only check 'subscribe' verification requests against my database. For 'unsubscribe' verification requests, I always echo back the challenge token. The theory here is that I only expect 'subscribe' to come unsolicited. And since I use special URLs with signatures, I know that 'unsubscribe' verification requests come only when I request them.
Waleed On Wed, Oct 20, 2010 at 12:34 PM, Julien Genestoux < [email protected]> wrote: > Waleed, > > Sorry if it wasn't clear. yes, the problem is that there is a doubt between > the fact that the user doesn't want the feed anymore, or that he simply > cannot confirm again. By asking if he wants to unsusbcribe, you then, > either confirm that he doesn't want the feed, or that he wasn't able to > confirm this either =) > And you can just do a request with hub.mode=unsubscribe (the hub is > supposed to check unsub requests anyway). > > Julien > > > On Wed, Oct 20, 2010 at 9:28 PM, Waleed Abdulla <[email protected]> wrote: > >> I've noticed that some PubSubHubbub users are not implementing >>> the "Automatic Subscription Refreshing" as we expect and do not echo the >>> challenge again once a subscription has been confirmed for a long time. They >>> may even not keep track of the past subscriptions on their end... or even >>> return 404 in case of downtime. >>> Unfortunately, that's not their intent. >>> >> >> Or it could be that they don't want to renew the subscription, which seems >> more likely. Unless I'm missing something! >> >> >> >>> A simple fix (that we implemented) is to actually check the subscription >>> first, and in case of non-confirmation, check that the callback wants to >>> unsubscribe. If subscribe is not confirmed and unsubscribe is confirmed, >>> then, the hub can safely delete the subscription. If not, it should keep >>> checking both. >>> >> >> How do you check that the callback wants to unsubscribe? >> >> >> Waleed >> >> >
