Hey Jay, Sounds like we're in agreement and the language here could be more clear. I've filed this issue to track your concerns: http://code.google.com/p/pubsubhubbub/issues/detail?id=91
Thanks for the feedback! -Brett On Thu, Oct 15, 2009 at 10:26 PM, Jay Rossiter <[email protected]> wrote: > On 10/15/2009 5:11 PM, Pádraic Brady wrote: > > >6.1.2 of the spec says "In synchronous mode, the verification (Section 6.2 > (Hub Verifies Intent of the Subscriber)) MUST be completed > >before the hub returns a response." > > It's important to note, as I noticed elsewhere recently, that we should > avoid the assumption that synchronous and asynchronous support by > Subscribers is a simple decision of one or the other. Subscribers may > actually support both, and if so, should include the hub.verify parameter in > their subscription request twice (one with a value of "sync", the other with > a value of "async" - the order determines a soft preference). In this event, > a Hub may soften the above rule so that even if they first attempt a > synchronous verification which fails, if the Subscriber has a secondary > asynchronous preference they can allow the request to complete successfully > (as in async mode) and then attempt the application of 6.2.1. > > Note, this is not made clear in the specification but I think it's a solid > approach. The final decision on what mode to persue is determined by the Hub > - the Subscriber merely advertises a preference. This is another issue not > highlighted in the specification. Superfeedr, for example, will return an > error on any subscription request where the sole hub.verify parameter sent > by a Subscriber equals "async" - Superfeedr do not support asynchronous > verification. A bug fixed just recently will ignore the Subscriber's > preference for asynchronous verification if they also include a synchronous > preference (doesn't matter if it's first or second - just that it is > supported). > > > This is already how I'm handling things - I just wanted to tighten up > the language in the spec so that it was clear. I support both verify > methods, together, and individually. What I was specifically referring to > was the case where sync was specified, and async was not. In that > situation, I believe that it behaves as I outlined in the original email > (unless anyone has a reason that it shouldn't). The two portions of the > spec contradict each other on this point. The retry portion of 6.2.1, by > definition, can only apply to async if the request "*MUST be completed > before the hub returns a response*". > > > >Also, a 200 reply with an incorrect challenge response should be > considered immediately fatal and treated as if it was a 404 (in *any*verify > >mode), correct? (To help prevent DoS/spamming.) > > Absolutely. Discard it immediately. In returning the invalid challenge, > technically the Subscriber probably also sent a 200 code as a definitive > verification. They are therefore not expected to respond to a second > verification request (from an implementation standpoint - it's probably moot > but could be deliberately prevented to block duplicate requests of this > kind). Since their final response is invalid you can simply abandon it. This > is a bit tricky since it's possible it was simple error by a valid > Subscriber - but since it is a security measure no further action should be > required. It's the Subscriber's responsibility to run a bug free Subscriber. > > > Again - already how I'm handling it. Just want to make sure that the > spec documents these situations, because they're currently left open to the > reader. > > Even though the spec says that all 3xx, 4xx, and 5xx responses (except > 404) should be treated as retries, I'm questioning this more and more. I > don't have an answer in my head, yet, but I don't see anything that prevents > a(/many) hub(s) from being utilized in a DoS against a server that has a > known page which returns these values. > > I think there needs to be a more refined definition of "reasonable > number of times over the course of a longer time period (e.g., 6 hours)", > and perhaps the minimum polling period. e.g. One retry per hour would > severely limit the impact a single server could have against a targeted > host. > > I haven't yet, but likely will, also add subscription rate limiting > against a single hostname/callback until at least one subscription request > has been verified. i.e. if I receive 1000 requests with a callback pointing > to "target.example.com", I will either refuse or queue them until at least > one has been accepted. > > -- > > Jay Rossiter | Software Engineer/System Administrator > Pioneering RSS Advertising Solutions > > [email protected] | Phone: 503.896.6187 | Fax: 503.235.2216 > Website: www.pheedo.com | RSS: www.pheedo.info/index.xml >
<<pheedo.gif>>
