Document basic backoff protocol. #323
Conversation
|
Why don't 429s get any docs in the Backoff section? They are similar to the 503 case, but it would be nice to mention them. |
|
|
||
| ``` | ||
| HTTP/1.1 200 OK | ||
| Backoff: 20 |
There was a problem hiding this comment.
- Do we really need to support this, i.e., make it simpler? Presumably we can shoot a 429 or 503 when we need to. This would just make some edge cases (maybe) better.
- If we really do need it, should it be X-Backoff?
There was a problem hiding this comment.
I'm open to removing it in this case, since the client should not be sending lots of background traffic to the server. One place where it might be useful is when polling for verification state, but then we don't plan to poll for that in future anyway.
There was a problem hiding this comment.
- If we really do need it, should it be X-Backoff?
https://tools.ietf.org/html/rfc6648
But I don't really care either way.
There was a problem hiding this comment.
Let's not do Backoff in 200 unless you think we really need it. Would it have helped in the past Sync meltdowns?
There was a problem hiding this comment.
Would it have helped in the past Sync meltdowns?
Yes, but I think that's particular to the way sync behaves. It does lots of background activity that can profitably be delayed upon request. It also gets a lot of value out of allowing clients to complete a sync, no matter how slowly, as this tends to decrease load on the DB due to future retries.
I'm happy to remove it here as its value would be marginal at best.
|
Comments addressed, @ckarlof r? |
|
r+. I agree that 200 w/Backoff might be appropriate in Sync or when there are more chatty background ops. Implementation issue opened: #331. |
Document basic backoff protocol.
Here is a super-basic backoff protocol to go along with the 429/503 error responses. It only does retry-after, no proof-of-work shortcuts allowed. We can expand with a PoW thing later, but let's get the basics into the protocol so clients can bake in support as early as possible.
It's not clear how much value we'll get out of the
Backoffheader for this service, since FxA clients wont tend to be doing lots of background requests to the server. But I think it's better to have a consistent mechanism across all services, so we might as well start by including it in here.@ckarlof r?