Re: [openstack-dev] [nova] Which error code should we return when OverQuota
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 of them for reasons™ and it is usually possible to find one that sort of fits. Using just 400 is bad for a healthy HTTP ecosystem. Sure, for the most part people are talking to OpenStack through official clients but a) what happens when they aren't, b) is that the kind of world we want? I certainly don't. I want a world where the HTTP APIs that OpenStack and other services present actually use HTTP and allow a diversity of clients (machine and human). Using response codes effectively makes it easier to write client code that is either simple or is able to use generic libraries effectively. Let's be honest: OpenStack doesn't have a great record of using HTTP effectively or correctly. Let's not make it worse. In the case of quota, 403 is fairly reasonable because you are in fact Forbidden from doing the thing you want to do. Yes, with the passage of time you may very well not be forbidden so the semantics are not strictly matching but it is more immediately expressive yet not quite as troubling as 409 (which has a more specific meaning). 400 is useful fallback for when nothing else will do. -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Which error code should we return when OverQuota
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 can. Yes, they don't always match, but there are several of them for reasons™ and it is usually possible to find one that sort of fits. Using just 400 is bad for a healthy HTTP ecosystem. Sure, for the most part people are talking to OpenStack through official clients but a) what happens when they aren't, b) is that the kind of world we want? I certainly don't. I want a world where the HTTP APIs that OpenStack and other services present actually use HTTP and allow a diversity of clients (machine and human). Absolutely. And the problem is there is not enough namespace in the HTTP error codes to accurately reflect the error conditions we hit. So the current model means the following: If you get any error code, it means multiple failure conditions. Throw it away, grep the return string to decide if you can recover. My proposal is to be *extremely* specific for the use of anything besides 400, so there is only 1 situation that causes that to arise. So 403 means a thing, only one thing, ever. Not 2 kinds of things that you need to then figure out what you need to do. If you get a 400, well, that's multiple kinds of errors, and you need to then go conditional. This should provide a better experience for all clients, human and machine. Using response codes effectively makes it easier to write client code that is either simple or is able to use generic libraries effectively. Let's be honest: OpenStack doesn't have a great record of using HTTP effectively or correctly. Let's not make it worse. In the case of quota, 403 is fairly reasonable because you are in fact Forbidden from doing the thing you want to do. Yes, with the passage of time you may very well not be forbidden so the semantics are not strictly matching but it is more immediately expressive yet not quite as troubling as 409 (which has a more specific meaning). Except it's not, because you are saying to use 403 for 2 issues (Don't have permissions and Out of quota). Turns out, we have APIs for adjusting quotas, which your user might have access to. So part of 403 space is something you might be able to code yourself around, and part isn't. Which means you should always ignore it and write custom logic client side. Using something beyond 400 is *not* more expressive if it has more than one possible meaning. Then it's just muddy. My point is that all errors besides 400 should have *exactly* one cause, so they are specific. -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Which error code should we return when OverQuota
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 webbrowser interaction patterns. There are not. The error code set was based around a specific expected web browser / website model from 20 years ago. I honestly think we'd be better served by limiting our use of non 200 or 400 codes to really narrow conditions (the ones that you'd expect from the browser interaction pattern). This would approach the whole problem from the least surprise perspective. 404 - resource doesn't exist (appropriate for GET /foo/ID_NUMBER where the thing isn't there) 403 - permissions error. Appropriate for a resource that exists, but you do not have enough permissions for it. I.e. it's an admin URL or someone else's resource. All other client errors, just be a 400. And use the emerging error reporting json to actually tell the client what's going on. -Sean On 05/05/2015 09:48 PM, Alex Xu wrote: 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 jiche...@cn.ibm.com mailto:jiche...@cn.ibm.com: 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 without modifications. //'/ may be a 409 (conflict) error if we really don't think 403 is a good one? Thanks [1] https://review.openstack.org/#/c/173985/ [2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html Best Regards! Kevin (Chen) Ji 纪 晨 Engineer, zVM Development, CSTL Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com mailto:jiche...@cn.ibm.com Phone: +86-10-82454158 tel:%2B86-10-82454158 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Which error code should we return when OverQuota
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 jiche...@cn.ibm.com: 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 without modifications. * *'* may be a 409 (conflict) error if we really don't think 403 is a good one? Thanks [1] https://review.openstack.org/#/c/173985/ [2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html Best Regards! Kevin (Chen) Ji 纪 晨 Engineer, zVM Development, CSTL Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com Phone: +86-10-82454158 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] Which error code should we return when OverQuota
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 without modifications. ' may be a 409 (conflict) error if we really don't think 403 is a good one? Thanks [1] https://review.openstack.org/#/c/173985/ [2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html Best Regards! Kevin (Chen) Ji 纪 晨 Engineer, zVM Development, CSTL Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com Phone: +86-10-82454158 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Which error code should we return when OverQuota
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 malformed syntax. The client SHOULD NOT repeat the request without modifications. ' may be a 409 (conflict) error if we really don't think 403 is a good one? Thanks [1] https://review.openstack.org/#/c/173985/ [2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html Looking through the HTTP spec you reference in [2], there isn't really a good match. You're right that 400 doesn't really make sense, but I don't really think that 409 is a good fit either. The only ones that would make sense to me would be 413 (Request Entity Too Large) and 403, the definition of which is wide enough to encompass the over-quota condition; and of those, 403 makes the most sense. (Note that I believe we use 413 for rate limiting, because of the Retry-After header…) -- Kevin L. Mitchell kevin.mitch...@rackspace.com Rackspace __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
