search

ericmckean / pubsubhubbub

Automatically exported from code.google.com/p/pubsubhubbub
Other
0 stars 0 forks source link

Automatically delete subscription when subscriber's callback returns 404 Not Found #121

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Unsubscribing is more complex than it could be. The hubs should consider 404 
reply from subscription URL as an unsubscribe request and delete the 
subscription rather than retrying the notification later.

It makes sense to retry 5xx errors, connection timeouts and the likes, but HTTP 
404 clearly suggests that the server is OK, it just does not want the 
notifications on this URL anymore.

When encountering 404 error, the hub could either delete all subscriptions for 
this url or just the current one. I think deleting all of them would be nicer. 
However, deleting only the current subscription would good enough for me (my 
callbacks are unique).

See also this thread for the reasons:
http://groups.google.com/group/pubsubhubbub/browse_thread/thread/e11824e0b6bbafd
b/412c3d82f7c70923?#412c3d82f7c70923

Original issue reported on code.google.com by Denis.Bi...@gmail.com on 30 Aug 2010 at 9:13

GoogleCodeExporter commented 9 years ago 
"but HTTP 404 clearly suggests that the server is OK, it just does not want the 
notifications on this URL anymore."

Totally disagree. You'll see 404s when a server's configuration is bad for some 
reason (say someone moves to a new hosting company and is still configuring 
their apache server), or when a reverse proxy cannot contact a backend server 
(often that's 502 as well). The separation of delivery verification from 
subscription verification is purposeful.

Original comment by bslatkin on 30 Aug 2010 at 3:38

GoogleCodeExporter commented 9 years ago 
Agree with bslatkin's comment regarding 404s. That can be solved by returning a 
different response instead. For example, a code that would not easily be 
returned by error. Or, say, the word "unsubscribe" in the body or the header. 
The format of the response is up for discussion; the important thing is that 
the subscriber needs a way to tell the hub to stop.

Original comment by ninuawal...@gmail.com on 30 Aug 2010 at 5:06

GoogleCodeExporter commented 9 years ago 
What about "410 Gone" reply? 
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.11
It seems unlikely to be used because of server misconfiguration.

Using a header or a message body would also work, although a reply code seems 
simpler.

Original comment by Denis.Bi...@gmail.com on 30 Aug 2010 at 5:22

GoogleCodeExporter commented 9 years ago 
I agree with the 410 response to unsubscribe all subscriptions with the 
callback URL. My server is being blasted despite unsubscribing properly.

Original comment by andrew.s...@gmail.com on 13 Sep 2010 at 6:49

GoogleCodeExporter commented 9 years ago 
I concur with all the above, simply because this is a huge issue with the 
system at current.  If you lose the URL you subscribed to, there's no 
reasonable way to unsubscribe, meaning your server is just bashed with 
information you have no way of saying you no longer want.

Original comment by caturne...@gmail.com on 16 Sep 2010 at 10:46

GoogleCodeExporter commented 9 years ago 
I get between 20,000 to 40,000 updates from hubs for blogs that I've 
unsubscribed from (or tried to) every single day. That adds up to about a 
million hits a month that are a total waste of bandwidth and resources, and 
simply just adds noise to the Internet. I'd say that I've spent a lot more time 
building the unsubscribe functionality than any other part of the PSHB specs, 
and I still get flooded with unwanted hits.

Original comment by ninuawal...@gmail.com on 17 Sep 2010 at 3:12

GoogleCodeExporter commented 9 years ago 
There's a separate problem with unsubscription in the Google hub right now that 
I'm investigating. I think you all have some valid points. We need to figure 
out the best balance of usability against accidental unsubscription.

Original comment by bslatkin on 22 Sep 2010 at 6:53

GoogleCodeExporter commented 9 years ago 
I believe I've mentioned using HTTP 410 on-list before.  I think that's an 
incredibly simple implementation with little to no downside.  Definite ++ from 
me.

Original comment by jrossi...@gmail.com on 23 Sep 2010 at 12:01

GoogleCodeExporter commented 9 years ago 
When I ran into problems unsubscribing, my immediate thought was to try and 
send 410 back to the hub - even before I read this thread.  It seemed most 
obvious to me, and it is something people may just do naturally.

Specs that you don't have to read, because they "just work" as expected, are 
the best.  :-)

Original comment by chris.r...@gmail.com on 3 Jan 2011 at 6:02

GoogleCodeExporter commented 9 years ago 
This issue was reported almost 2 years ago but I'm having the same 
un-superscription issue, even though my un-subscription is proper and I do 
verify the request I get from the Hub, but still I get pings when there are 
updates, as if my unsubscription request was ignored.
I add my voice to 410 response when the subscriber is not interested anymore in 
the ping from the hub. it's simple, straight forward and simplifies greatly the 
current specs. 
This should only affect the feed related to the incoming ping, not all feeds I 
subscribe to.

Original comment by tamer.yo...@gmail.com on 3 Dec 2012 at 8:42

GoogleCodeExporter commented 9 years ago 
I still get pings from 2-year old subscriptions that I don't want to receive 
and have tried to unsubscribe from hundreds of times. The unsubscribe flow is 
definitely broken.

Original comment by wal...@ninua.com on 3 Dec 2012 at 10:41