- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Tue, 29 Jul 2008 16:26:39 -0700
- To: Jeff Currier <Jeff.Currier@microsoft.com>
- Cc: Julian Reschke <julian.reschke@gmx.de>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, Jason Hunter <Jason.Hunter@microsoft.com>
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
Received on Tuesday, 29 July 2008 23:27:20 UTC