- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 29 Oct 2010 11:33:10 +1100
- To: Karl Dubost <karl+w3c@la-grange.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
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 UTC