On May 6, 2015, at 1:58 PM, David Kranz
dkr...@redhat.commailto:dkr...@redhat.com wrote:
+1
The basic problem is we are trying to fit a square (generic api) peg in a round
(HTTP request/response) hole.
But if we do say we are recognizing sub-error-codes, it might be good to
actually give them
On 05/06/2015 02:07 PM, Jay Pipes wrote:
Adding [api] topic. API WG members, please do comment.
On 05/06/2015 08:01 AM, Sean Dague wrote:
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
On 05/06/2015 02:07 PM, Jay Pipes wrote:
Adding [api] topic. API WG members, please do comment.
On 05/06/2015 08:01 AM, Sean Dague wrote:
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
On Wed, 6 May 2015, Jay Pipes wrote:
I think Sean makes an excellent point that if you have 1 condition that
results in a 403 Forbidden, it actually does not make things more expressive.
It actually just means both humans and clients need to now delve deeper into
the error context to
On 05/06/2015 03:15 PM, Chris Dent wrote:
On Wed, 6 May 2015, Jay Pipes wrote:
I think Sean makes an excellent point that if you have 1 condition
that results in a 403 Forbidden, it actually does not make things more
expressive. It actually just means both humans and clients need to now
Learn a lot again! ++ for sub-error-codes.
From: Everett Toews [mailto:everett.to...@rackspace.com]
Sent: Thursday, May 7, 2015 6:26 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [api] Changing 403 Forbidden to 400 Bad Request
for OverQuota
