Waleed, If you do treat the subscribe correctly, and always echo on unsusbcribe then that's fine :)
If you do want to keep the feed : - we check with a 'subscribe' : you acknwoledge and it stops here. We renew subscription as expected. If you do NOT want to keep the feed : - we check with a 'subscribe' : you do not ack it, so we send an verif to check whether you want to unsubscribe. You echo the challenge, we take that as a confirmation and we delete the susbription, as expected. So I think you're safe :) Julien On Wed, Oct 20, 2010 at 9:49 PM, Waleed Abdulla <[email protected]> wrote: > 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 >>> >>> >> >
