- 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>
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 UTC