Not receiving notifications for TechCrunch

78 views
Skip to first unread message

Franco

unread,
Nov 21, 2013, 5:09:17 AM11/21/13
to pubsub...@googlegroups.com
I am not receiving notifications for http://feeds.feedburner.com/TechCrunch. My client has successfully subscribed and I verified my callback address is subscribed for this topic at https://pubsubhubbub.appspot.com/subscribe

I am successfully receiving notifications for several other subscriptions including feedburner feeds.

Julien Genestoux

unread,
Nov 21, 2013, 5:13:18 AM11/21/13
to Pubsubhubbub
Franco,

The TC is everyone's nightmare, mostly for up/low/camel-case issues :)
Basically, the spec is clear, you have to subscribe to the rel="self" url for feeds.

The feed http://feeds.feedburner.com/TechCrunch has a self url equal to http://feeds.feedburner.com/Techcrunch (the difference is in the C of crunch).
Try subscribing with the self url and you should be good...

Thanks,

PS: At Superfeedr, we're able to detect this kind of problem and we'll push you updates in realtime even if you subscribed to the wrong url!





--


On Thu, Nov 21, 2013 at 11:09 AM, Franco <ando...@gmail.com> wrote:
I am not receiving notifications for http://feeds.feedburner.com/TechCrunch. My client has successfully subscribed and I verified my callback address is subscribed for this topic at https://pubsubhubbub.appspot.com/subscribe

I am successfully receiving notifications for several other subscriptions including feedburner feeds.

--
 
---
You received this message because you are subscribed to the Google Groups "Pubsubhubbub" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pubsubhubbub...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Franco

unread,
Nov 22, 2013, 5:25:30 PM11/22/13
to pubsub...@googlegroups.com
Julien,

Thanks, that did the trick!

Would it make sense for the pshb spec to specify that hub's treat topic url's as case-insensitive? Actually just looked at the URI spec (RFC 3986) and it seems that resources after the domain are technically case-insensitive but really left up to the server to decide. So technically those two url's (TechCrunch vs Techcrunch) could serve up different resources, though I wonder how common that actually is in practice, particularly for a feed xml. 

Alternatively, would it make sense for the hub to check if there is actually a publisher registered send pings for that topic url and respond with failure to a client subscription attempt for such a topic url that's not registered? It looks like currently the hub successfully verifies a subscription to any random url http://www.google.com/blah/blah/blah for example. Is there a reason this is allowed by the protocol currently? 

Thanks!
Franco

Julien Genestoux

unread,
Nov 22, 2013, 5:47:44 PM11/22/13
to Pubsubhubbub
Franco,

I agree the case is a problem, but I don't think it can be fixed at the spec level. The spec indicates that the topic URL must be exactly the self url... In all honesty, I think Feedburner is being an jerk for not handling these things correctly.

How can the hub check that it *will* get a ping? What we do at Superfeedr (and what I think the Google Hub should probably do) is that we check when somebody subscribes that the topic url matches the self link. If it does not, then we refuse the subscription. If it does, it does not mean that the publisher will ping us, but I don't think there is a way to check that.

The protocol cannot say what should happen when any involved party does not respect it. It can only be 'positive' and specify what happens when certain conditions are matched. To take an extreme example, the protocol cannot state what should happen when you send a PUT request to a hub, because that's outside the spec. Using that rule, the protocol cannot specify what the hub should do when the subscriber does not behave by the protocol.
That being said, I'm convinced that a 'sensible' implementation should be as helpful as possible by providing context on obvious errors: http://en.wikipedia.org/wiki/Robustness_principle

I hope this makes sense.








--


--
Reply all
Reply to author
Forward
0 new messages