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

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  
403 just says the action is forbidden.  The body of the response says  

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.


Received on Tuesday, 29 July 2008 23:27:20 UTC