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

From: Jeff Currier <[email-masked]>
Date: Tue, 29 Jul 2008 13:39:01 -0700

Frank,

I think a new status code would likely be the best move.  We're attempting to enforce quota's around bandwidth, storage used, and some other application specific constraints.  Moreover, I think the notion of quota's as they apply to new services seems like a something many new services would use.

We also found that WebDav introduced some that would kind of work.  Specifically, 507(InsufficientStorage) comes to mind however this really isn't completely sufficient for our use cases.  Additionally, when I think of the other scenarios that have come up issuing too many requests within a specific period of time, etc it really doesn't map very well since there is a very specific meaning behind that status code.

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

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 Jul 2008 00:10:34 +0200

Jeff Currier wrote:
> 
> 
> Frank,
> 
>  
> 
> I think a new status code would likely be the best move.  We’re 
> attempting to enforce quota’s around bandwidth, storage used, and some 
> other application specific constraints.  Moreover, I think the notion of 
> quota’s as they apply to new services seems like a something many new 
> services would use. 
> 
>  
> 
> We also found that WebDav introduced some that would kind of work.  
> Specifically, 507(InsufficientStorage) comes to mind however this really 
> isn’t completely sufficient for our use cases.  Additionally, when I 
> think of the other scenarios that have come up issuing too many requests 
> within a specific period of time, etc it really doesn’t map very well 
> since there is a very specific meaning behind that status code.
> ...

See: <http://greenbytes.de/tech/webdav/rfc4331.html#rfc.section.6>

BR, Julian

---

From: Jeff Currier <[email-masked]>
Date: Tue, 29 Jul 2008 15:50:47 -0700

Julian,

After reading a bit more on the use 507 status code I'm still concerned that this is very much related to Storage and would not be broad enough to encompass all the of the scenarios that we have (bandwidth quota violations, storage violations, application object quota violations, etc).  It still seems that a more general status code is needed.

Now, to Robert's earlier mention of the use of 403.  The concern there again is still the idea that people will confuse this with the password issue.  I appreciate that the spec does call out that the request was correctly formed, the server understood the request and that the reissue of the request will have no effect but in practice most users, IMHO, will simply only check their passwords.  I think the fact that we see so many other services not using 403 for this sort of thing supports this conclusion.

Regards,

--Jeff--

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]]
Sent: Tuesday, July 29, 2008 3:11 PM
To: Jeff Currier
Cc: [email-masked]
Subject: Re: Quota Enforcement and the communication of violations of policy using HttpStatusCode's.

Jeff Currier wrote:
>
>
> Frank,
>
>
>
> I think a new status code would likely be the best move.  We're
> attempting to enforce quota's around bandwidth, storage used, and some
> quota's as they apply to new services seems like a something many new
> services would use.
>
>
>
> isn't completely sufficient for our use cases.  Additionally, when I
> within a specific period of time, etc it really doesn't map very well

BR, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 29 Jul 2008 16:26:39 -0700

On Jul 29, 2008, at 3:50 PM, Jeff Currier wrote:
> Julian,
>
> After reading a bit more on the use 507 status code I'm still  
> concerned that this is very much related to Storage and would not  
> be broad enough to encompass all the of the scenarios that we have  
> (bandwidth quota violations, storage violations, application object  
> quota violations, etc).  It still seems that a more general status  
> code is needed.
>
> Now, to Robert's earlier mention of the use of 403.  The concern  
> there again is still the idea that people will confuse this with  
> the password issue.  I appreciate that the spec does call out that  
> the request was correctly formed, the server understood the request  
> and that the reissue of the request will have no effect but in  
> practice most users, IMHO, will simply only check their passwords.   
> I think the fact that we see so many other services not using 403  
> for this sort of thing supports this conclusion.

403 has nothing to do with passwords (401 would indicate bad  
credentials).
403 just says the action is forbidden.  The body of the response says  
why.

The only time a new HTTP status code is needed is when there is a need
for a distinct automated reaction to that status.  I don't see that need
for this case.  What is the client supposed to do when it is informed of
this status?  If it needs to stop and wait for user intervention,  
then 403
is the appropriate code.  If it needs to wait until more resources are
available, then 507 (with possible retry-after header) is appropriate.

....Roy

---

From: Adrien de Croy <[email-masked]>
Date: Wed, 30 Jul 2008 11:31:07 +1200

Who is the intended recipient for any message containing a new code?  A 
UA, or a human?

If a human using a web browser, then you can print back any message you 
like in the body, and use any 4xx code to get it showing, and I don't 
see any need for any more codes.

If on the other hand you need the agent to be able to distinguish 
between quota/policy and other issues, then you'd need some extended 
protocol to communicate specifics, and some user agents that implement 
this as well.

As for 403, you only get a password popup if you add an WWW-Authenticate 
header, so just don't put in this header, and the UA won't pop (none 
I've seen will) a dialog, so no user confusion.  You also get to specify 
the content of the message displayed in the browser window.

Cheers

Adrien

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

---

From: Robert Collins <[email-masked]>
Date: Tue, 29 Jul 2008 21:32:33 +0000

On Tue, 2008-07-29 at 13:39 -0700, Jeff Currier wrote:
> other application specific constraints.  Moreover, I think the notion
> of quota’s as they apply to new services seems like a something many
> new services would use.  

400 is not a good fit as it claims a malformed request. 403 however
seems ideal - the description of 403 is very clear that authorization
will not help and that the request was correctly formed and
understandable but that the server is choosing not to honour it.

For instance
HTTP/1.1 403 Bandwidth quota exceeded
HTTP/1.1 403 Disk quota exceeded
etc

-Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.