HTTP response codes to content distribution attempts

[Tony Garnock-Jones]

In the draft of 20 Oct 2016, section 6 contains:

The successful response from the subscriber's callback URL MUST be an HTTP [RFC7231] success (2xx) code. The hub MUST consider all other subscriber response codes as failures [...]

and recommends that after some unspecified amount of time, enough repeated failures should cause cessation of retry. (Issue #15 discusses what that might mean.)

However, some HTTP codes could be worth treating specially. In particular,

• 4xx should cause immediate deletion of the subscription
  • except, arguably, 408, 413, and possibly 411
• 5xx should probably be a strong signal that the subscription is probably broken; if not immediate unsubscription, then probably after a smaller number of retries than usual
  • except 503, which is explicitly a temporary condition, including an optional retry-after

For simplicity, perhaps it'd be OK to have

• 2xx: success!
• 3xx: failure, retry
• 4xx: failure, delete the subscription
• 5xx: failure, retry (taking into account retry-after if supplied and code is 503)

Or, is this getting too far into the weeds of setting policy? Perhaps just clearing up #15 is enough?

[Erik Wilde]

i like these thoughts but i think this should all go into an informal appendix. thinking about this will be required for a reasonable hub implementation. as suggested in #15, hub should document their behavior so that it is predictable (to some degree) how they will behave. but i would refrain from making these rules part of the normative text.

[Aaron Parecki]

In my hub implementation, it was easier to do exactly what the spec recommends, treating everything that wasn't a 2xx response as an error, and retrying delivery with some limits. I'm not sure my implementation would really benefit from additional logic to immediately delete on 4xx.

[Tony Garnock-Jones]

OK, that all sounds good. Thanks!