>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). >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. Hope this helps ;). Maybe someone else can chime in my interpretation of the first point. Paddy Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com OpenID Europe Foundation Irish Representative ________________________________ From: Jay Rossiter <[email protected]> To: [email protected] Sent: Fri, October 16, 2009 12:44:53 AM Subject: [pubsubhubbub] Subscription verification 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." 6.2.1 of the spec says "The hub MUST consider other server response codes (3xx, 4xx, and 5xx) to mean that the subscription action was not verified. The hub SHOULD retry verification a reasonable number of times over the course of a longer time period (e.g., 6 hours) until a definite acknowledgement (positive or negative) is received." One assumes that this section of 6.2.1 does not apply to synchronous requests, but it's left somewhat undefined. So, for clarification, any failure of verification in a synchronous request should be immediate and permanent - correct? If that's true, the text should read "For async verifications the hub SHOULD retry [...]" 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.) -- 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
