On 05/06/2015 07:11 AM, Chris Dent wrote:
> On Wed, 6 May 2015, Sean Dague wrote:
>
>> All other client errors, just be a 400. And use the emerging error
>> reporting json to actually tell the client what's going on.
>
> Please do not do this. Please use the 4xx codes as best as you
> possibly ca
On Wed, 6 May 2015, Sean Dague wrote:
All other client errors, just be a 400. And use the emerging error
reporting json to actually tell the client what's going on.
Please do not do this. Please use the 4xx codes as best as you
possibly can. Yes, they don't always match, but there are several
It does, however I looked through the history of that repo, and that's
just in one of Jay's documents that predates the group. I'm a little
cautious to give it a lot of weight without rationale.
Honestly, there is this obsession of assuming that there *are* good fits
for HTTP status codes for non
>From API-WG guideline, exceed quota should be 403
https://github.com/openstack/api-wg/blob/master/guidelines/http.rst
2015-05-06 3:30 GMT+08:00 Chen CH Ji :
> In doing patch [1], A suggestion is submitted that we should return 400
> (bad Request) instead of 403 (Forbidden)
> I take a look at [2
On Tue, 2015-05-05 at 21:30 +0200, Chen CH Ji wrote:
> In doing patch [1], A suggestion is submitted that we should return
> 400 (bad Request) instead of 403 (Forbidden)
> I take a look at [2], seems 400 is not a good candidate because
> 'The request could not be understood by the server due to ma
In doing patch [1], A suggestion is submitted that we should return 400
(bad Request) instead of 403 (Forbidden)
I take a look at [2], seems 400 is not a good candidate because
'The request could not be understood by the server due to malformed syntax.
The client SHOULD NOT repeat the request with
