Open Stack

We had extend discussions about the HTTP error code that we retuned for rate limiting while discussing the compute API.  The issue is that we allow users to discover and query their rate limits.  So an over-limit response should be in the 400 range because we see it as a client error.  None of the codes fit exactly right, but we felt 413 fit the best for that use case, because it provided for a RetryAfter header and if you think about it Request Entity Too Large makes sense because if you've been rate limited we'd allow 0 bytes on the request.  Still it was somewhat ambiguous. Services that don't provide queryable rate limits return an error in the 500 range (503), essentially saying "hey, I'm being overloaded right now, back off".

The nice thing about 429, is that it's a 400 level code specific for rate limiting that's completely unambiguous.  If there's even an effort to standardize around that code I think that we should support it in the next revision of our APIs.

-jOrGe W.

On Oct 20, 2011, at 11:35 AM, Caitlin Bestler wrote:

> Russel Bryant wrote:
> 
>>> We need to add these codes to maintain compliance.
>>> 
>>> https://tools.ietf.org/html/draft-nottingham-http-new-status-02
> 
>> To maintain compliance with what?  I ask since the linked document is a draft.
> 
> Waiting until a draft was an official RFC would be an excessive delay. The IETF process is thorough but far from fleet of foot.
> However, waiting for a draft to be a workgroup product before saying that a project SHOULD comply with it makes sense.
> Of course if we agree that it is a good idea then we MAY comply with it. I'm not enough of an HTTP/REST expert to have an opinion on that.
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

This email may include confidential information. If you received it in error, please delete it.