On Jan 8, 5:49 pm, Jeff Lindsay <[email protected]> wrote: > Think of your callback URL like a webpage ... you can't really control how > hard it's hit (hence slashdot effect, etc). You can add rate limiting in > front of it if you're really worried. So a) don't subscribe to publishers > you don't trust to not flood you, b) deal with it appropriately as HTTP if > they do and you still want to subscribe to them. > > I don't think it's the hub's responsibility.
I have to disagree. I think this is very much the hub's responsibility. A typical PuSH subscriber could be a web-based feed reader like Google Reader or Bloglines. The choice of who to subscribe to is made by users of the service, not the service itself. The service basically has to trust every feed that a user might want to subscribe to, so (a) is not really an option. For PuSH to be usable, a subscriber must be able to rely on the hub not to flood it. >From a legal point of view I'm kind of curious who would be liable if a hub flooded a server off the internet (perhaps resulting in loss of business) as a result of unwanted pings. For the sake of argument, assume that the pings were from a feed that the client *hadn't* subscribed to (i.e. a deliberate attack propagated through the hub). It seems to me that the hub is responsible for the loss of business suffered by the subscriber. The hub could in turn try and sue the attacker (assuming they could be traced), but the initial liability still lies with the hub IMO. Obviously the law will differ from country to country, but if I were running a hub, and one of my servers took someone's site out by flooding them with pings, I would hope I had a better defence than just shrugging and saying "not my responsibility". This is not the same as the slashdot effect, which is a legitimate (if unexpected) flood of connections from multiple sources. Regards James
