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

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:julian.reschke@gmx.de]
Sent: Tuesday, July 29, 2008 3:11 PM
To: Jeff Currier
Cc: ietf-http-wg@w3.org
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
> 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

Received on Tuesday, 29 July 2008 22:51:52 UTC