Subject: Quota Enforcement and the communication of violations of policy using HttpStatusCode's.

From: Jeff Currier <[email-masked]>
Date: Tue, 29 Jul 2008 16:30:31 +0000

Hey all,

I'm working on the SQL Server Data Services team at Microsoft and we've run into a bit of a dilemma with how best to communicate Quota violations for the service to our users.  We provide a REST service head so we, of course, want to leverage the existing set of Http status codes

The problem, and it's a general one, is that there is no clear mapping (IMHO) to use for this.  What's more when we survey what others have done in this space the results are quite varied.  I've observed the following usages

400 (BadRequest) - YouTube API for sending too many requests within a period of time or for exceeding the allowed # of items in a playlist.
503 (ServiceUnavailable) - Amazon's S3 for the sending too many requests within a period of time.
409 (Conflict) - Amazon's SimpleDB for sending too many requests within a period of time or for violating other application quotas enforced by the system.

The Http specification itself seems to suggest that a 403(Forbidden) would be the best mapping but we're concerned that this carries with it a lot of baggage as a lot of consumers will simply assume that they've mistyped a password to the system.  Additionally, with more services like our own, S3, SimpleDB, etc coming online I think they is likely a need for a general quota violation status code in the specification as other services will also have similar needs to our own.

Now, we don't really want to invent our own status code so the team thought it would be best if we brought our problem to the working group to discuss this issue so any input/advice the team could give here would be greatly appreciated.

Regards,

--Jeff--

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 29 Jul 2008 22:06:23 +0200

Jeff Currier wrote:

> we don't really want to invent our own status code so the
> team thought it would be best if we brought our problem to
> the working group to discuss this issue

You could stick to 403 for HTTP/1.0 (old clients) if that's
in any way relevant for your scenario, and pick another code
for HTTP/1.1 if it has a more desirable effect.  Could say
"402" do what you want, are you asking how to register a new
HTTP error code, or do you want a better documentation for
an existing code in 2616bis ?

 Frank