W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2008

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

From: Jeff Currier <Jeff.Currier@microsoft.com>
Date: Tue, 29 Jul 2008 16:30:31 +0000
To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Cc: Jason Hunter <Jason.Hunter@microsoft.com>, Rick Negrin <Rick.Negrin@microsoft.com>, David Robinson <David.Robinson@microsoft.com>, Hari Sivaramakrishnan <harisiva@microsoft.com>
Message-ID: <EAFDEC03CDA5D644878904F4A8F0158A5ED7ADC904@NA-EXMSG-C103.redmond.corp.microsoft.com>
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.


Received on Tuesday, 29 July 2008 19:46:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:37 UTC