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

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

From: Willy Tarreau <w@1wt.eu>
Date: Fri, 29 Oct 2010 07:58:31 +0200
To: "Eric J. Bowman" <eric@bisonsystems.net>
Cc: Mark Nottingham <mnot@mnot.net>, Karl Dubost <karl+w3c@la-grange.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20101029055831.GC28406@1wt.eu>
On Thu, Oct 28, 2010 at 07:45:16PM -0600, Eric J. Bowman wrote:
> Mark Nottingham wrote:
> > 
> > a) Clarify that 503 can be used for rate limiting, or
> > 
> 
> +1
> 
> I just came across this issue, too, but didn't bookmark -- Twitter's
> Fail Whale is a 503; now cute rate-limit responses are proliferating,
> but not everybody agrees on what status code to use, which surprises me.
> I always assumed rate-limiting was kinda the whole point of 503.

I agree that 503 could match this purpose but I have a problem with using
503. It's commonly tracked in logs to look for service faults (eg: unavailable
server/service). Reusing it as a "normal error" can make this tracking a lot
more complex. In my opinion, 503 really means the service is down (possibly
for a limited time as reported with Retry-After) while here we're more likely
saying "I have a limited capacity, please take your ticket and wait a bit",
which is more about congestion control. Perhaps a new 5xx would fit ?

I'm even thinking we might also like an equivalent in the 1xx response codes,
with the connection remaining open, in the same vein we have 100 Continue.
We could imagine something like "102 please hold the line" once in a while,
indicating that the service is not dead, finally followed by the real
response. It would be really nice for traffic serialization.

Willy
Received on Friday, 29 October 2010 05:59:16 GMT

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