W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

Re: API Rate Limits and HTTP Code [#255]

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 29 Oct 2010 11:33:10 +1100
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <728A3F52-506F-47F1-9218-7BE13013488A@mnot.net>
To: Karl Dubost <karl+w3c@la-grange.net>
Hi Karl,

That's a very timely question; I've had similar discussions privately with a number of folks, and have created an issue to track it:
  http://trac.tools.ietf.org/wg/httpbis/trac/ticket/255

My personal feeling is that we should clarify one of the existing status codes to include this use case, allowing space for someone to define an additional header or two giving more information. I'm happy to be argued into a new status code, but don't think it's necessary at this point.

Based on the links below, it looks like common practice is to use either 403 or 503. 

The commonly cited case for 4xx codes (also explained in the blog you link to) is that it's a client error, not a server error. While I agree generally, it's important to keep in mind the effects on clients. 403 (and any 4xx error that a client doesn't recognise) will result in a conservative client believing that they're not allowed to resubmit the request, whereas 503 + Retry-After results in the correct client behaviour.

That said, I'm more interested in coming to an agreement and assuring that existing software doesn't get broken than in coming up with "perfect" semantics. To that end, it looks like our options are:

a) Clarify that 503 can be used for rate limiting, or

b) Clarify that 403 can be used for rate limiting, and allow Retry-After to appear there, or

c) Define a new status code (4xx or 5xx TBD).



Some other folks doing similar things:

Github uses 403:
  http://support.github.com/discussions/site/1151-api-returns-403-when-rate-limiting

BaseCamp uses 503:
  http://developer.37signals.com/basecamp/

Google seems to use 404:
  http://groups.google.com/group/google-base-data-api/browse_thread/thread/cb5752b43b030fed

Amazon appears to use 503:
  http://developer.amazonwebservices.com/connect/message.jspa?messageID=142896

Apache mod_limitipconn uses 503:
  http://dominia.org/djao/limit/contrib/sbarta/mod_limitipconn.c

Lighttpd mod_evasive uses 403:
  http://redmine.lighttpd.net/projects/lighttpd/repository/entry/trunk/src/mod_evasive.c

... as does Apache mod_evasive:
  http://www.zdziarski.com/blog/?page_id=442

Nginx uses 503:
  http://wiki.nginx.org/NginxHttpLimitZoneModule

Yahoo uses 403:
 http://developer.yahoo.com/search/rate.html

I see references to Facebook using 341, e.g.,:
  http://forum.developers.facebook.net/viewtopic.php?pid=245966

Mozilla Weave doesn't specify a status code, but re-specifies Retry-After:
  https://wiki.mozilla.org/Labs/Weave/Sync/1.0/API#X-Weave-Backoff


On 29/10/2010, at 7:50 AM, Karl Dubost wrote:

> Hi,
> 
> I have seen a few times blog post (example [1]) over API Rate Limits and HTTP response code. People designing APIs have difficulties it seems to find the appropriate HTTP response code. That led me a few weeks ago to look at what was done at a few services (not a complete survey, just curiosity)
> 
> There is no common practice around that. Should the HTTP specification have a specific code for this, or is there already everything appropriate?
> 
> 
> [1]: http://mehack.com/inventing-a-http-response-code-aka-seriously
> [2]: http://lists.w3.org/Archives/Public/www-archive/2010Oct/0000
> [3]: http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-12#section-8.4
> 
> -- 
> Karl Dubost
> Montréal, QC, Canada
> http://www.la-grange.net/karl/
> 
> 

--
Mark Nottingham   http://www.mnot.net/
Received on Friday, 29 October 2010 00:33:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:32 GMT