Fully document redirect behaviors

[GoogleCodeExporter]

Discussion from email:

> 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?

Original issue reported on code.google.com by bslatkin on 20 Jul 2009 at 5:12

[GoogleCodeExporter]

Been looking at this some.  It's not a huge deal, but Section 6.2.1 of the 0.2. 
draft PSHB spec should probably not 
imply the implementer SHOULD retry on all 4xx other than 404, as it really 
depends on the particular 4xx.  
Maybe the spec should say hubs SHOULD retry on all 5xx, and 4xx SHOULD each be 
interpreted according to 
HTTP: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html.  One should not 
retry on a 403, for example, 
and maybe send cash before retrying on a 402.  On the other hand, 408 seems 
worth retrying in almost all 
cases.  403, though, is definitely worth respecting-- it might even make for a 
better explicit rejection code than 
404.

Original comment by mason....@gmail.com on 2 Oct 2009 at 11:46

[GoogleCodeExporter]

Picking this one up again. My case against 403 is basically I've seen 403s 
served 
when someone misconfigured a reverse HTTP proxy and accidentally shut off their 
own URLs for a period of time. I want to avoid these small-window 
misconfigurations 
from causing someone to lose all of their subscriptions due to automatic 
refreshing 
doing the retries during this failure window. Thus I think retrying on *all* 
errors and 
then only giving up after some number of hours is appropriate because it has 
the 
most error tolerance. Losing a sub and not knowing it is really bad!

Otherwise, I'll indicate that redirects are not honored for subscriber URLs-- I 
think 
that's consistent with peoples' expectations. It's also easy to resubscribe in 
multiple 
places, which makes this a non-issue. Redirect on POST while preserving the 
verb is 
hard to get right so we should avoid it.

Original comment by bslatkin on 9 Feb 2010 at 3:18

• Added labels: spec0.3

[GoogleCodeExporter]

Addressed in 0.3 draft spec

Original comment by bslatkin on 9 Feb 2010 at 6:05

• Changed state: Fixed