Comments on diffs between r123 and r165 of the spec

[Tony Garnock-Jones]

Hi all,

I'm just getting around to catching up with the spec changes since r123.

• hub.callback now "should not" contain query-string or fragment: no fragment makes sense (well, if my limited understanding of URL semantics is right), but why not permit query-strings? (I would, instead, require hubs to respect any potentially existing query-strings when adding parameters to the callback URL)
• hub.verify is now multiply-present rather than comma-separated: OK! I'll probably update the implementation to accept both.
• hub.lease_seconds: seems like a good idea. I'll have a go at that, too.
• "Hubs MUST ignore any verify modes they do not understand": this text mostly duplicates the sentence two sentences earlier :-)
• hub.challenge: good idea. More on this below.

Hub.challenge currently requires just the challenge string to be echoed in the body of the verification request response. I'd prefer it to be an application/x-www-form-urlencoded response body, with a single required parameter of "hub.challenge", because that gives a bit of room for experimentation with things like per-subscription session keys (for message authentication and encryption, etc).

I'm also not a fan of the "indefinite retry" verification procedure. Certainly for synchronous verification, I'd like it to try just the once. Asynchronous, however, is a bit different -- what's best there? I've been thinking about how to treat various 3xx/4xx/5xx response codes during publication, too -- perhaps there's some common behaviour we can exploit. Something like (pulling this out of the air) this: 3xx should be honoured and retried (up to N times, some hub-decided limit at which it gets bored of trying?), 4xx should be immediate failure (after all, it's a "client error" code!) and 5xx should probably be immediate failure (fail fast?). For subscriptions, I'd expect 3xx redirections to be followed as appropriate, 4xx to immediately cause subscription cancellation, and 5xx to maybe be retried later -- keeping the subscription, but suspending it temporarily to let the subscriber recover from their 5xx-producing failure, whatever it is. Does this seem reasonable?

Regards,
  Tony

P.S. Great demo the other day, BTW, Brett & Brad!

[Brett Slatkin]

Hey Tony!

Thanks for the great feedback and sorry for the delay.

> hub.callback now "should not" contain query-string or fragment: no fragment
> makes sense (well, if my limited understanding of URL semantics is right),
> but why not permit query-strings? (I would, instead, require hubs to respect
> any potentially existing query-strings when adding parameters to the
> callback URL)

Yeah you're right. I've filed this issue:
http://code.google.com/p/pubsubhubbub/issues/detail?id=25

> "Hubs MUST ignore any verify modes they do not understand": this text mostly
> duplicates the sentence two sentences earlier :-)

Whoops. Opened this issue:
http://code.google.com/p/pubsubhubbub/issues/detail?id=26

> Hub.challenge currently requires just the challenge string to be echoed in
> the body of the verification request response. I'd prefer it to be an
> application/x-www-form-urlencoded response body, with a single required
> parameter of "hub.challenge", because that gives a bit of room for
> experimentation with things like per-subscription session keys (for message
> authentication and encryption, etc).

> I'm also not a fan of the "indefinite retry" verification procedure.

This infinite retry stuff is wrong, definitely. I've opened this issue
to fix it: http://code.google.com/p/pubsubhubbub/issues/detail?id=24

> Certainly for synchronous verification, I'd like it to try just the once.
> Asynchronous, however, is a bit different -- what's best there? I've been
> thinking about how to treat various 3xx/4xx/5xx response codes during
> publication, too -- perhaps there's some common behaviour we can exploit.
> Something like (pulling this out of the air) this: 3xx should be honoured
> and retried (up to N times, some hub-decided limit at which it gets bored of
> trying?), 4xx should be immediate failure (after all, it's a "client error"
> code!) and 5xx should probably be immediate failure (fail fast?). For
> subscriptions, I'd expect 3xx redirections to be followed as appropriate,
> 4xx to immediately cause subscription cancellation, and 5xx to maybe be
> retried later -- keeping the subscription, but suspending it temporarily to
> let the subscriber recover from their 5xx-producing failure, whatever it is.
> Does this seem reasonable?

I agree that 404 means immediate cancellation, 5xx means to retry. I
think other 4xx errors should cause retries too, because sometimes
400s happen.

As for redirects, I'm not sure if we should allow the subscriber to
move itself at any time. But I do see use-cases. Some issues:

- On delivery notification (a POST) we could only allow redirection
through an HTTP 307 response, which should repeat the POST. That means
we can't issue a 301 redirect and have the method repeated, though.

- Allowing for redirection gives an attacker a pretty easy way to
launch a dos attack. Sign up for a ton of subscriptions, then when
they're delivered, redirect to some unhappy third-party. Granted, I as
the original subscriber would need to soak this load, so the risk is
mitigated.

I'm definitely up for documenting the 307 behavior properly. But that
really doesn't allow for full service moves of a subscriber. We'd need
some other way to indicate permanence. What do you think?

> P.S. Great demo the other day, BTW, Brett & Brad!

Thanks!

-Brett