On 02/03/2015 06:54 PM, Kevin Benton wrote:
So do we just use whatever name we want instead? Can we use 'referrer'? ;-)
:) How about Content-Length? -jay
On Tue, Feb 3, 2015 at 5:43 AM, Jay Pipes <jaypi...@gmail.com <mailto:jaypi...@gmail.com>> wrote: On 02/02/2015 09:07 PM, Everett Toews wrote: On Feb 2, 2015, at 7:24 PM, Sean Dague <s...@dague.net <mailto:s...@dague.net> <mailto:s...@dague.net <mailto:s...@dague.net>>> wrote: On 02/02/2015 05:35 PM, Jay Pipes wrote: On 01/29/2015 12:41 PM, Sean Dague wrote: Correct. This actually came up at the Nova mid cycle in a side conversation with Ironic and Neutron folks. HTTP error codes are not sufficiently granular to describe what happens when a REST service goes wrong, especially if it goes wrong in a way that would let the client do something other than blindly try the same request, or fail. Having a standard json error payload would be really nice. { fault: ComputeFeatureUnsupportedOnIns__tanceType, messsage: "This compute feature is not supported on this kind of instance type. If you need this feature please use a different instance type. See your cloud provider for options." } That would let us surface more specific errors. <snip> Standardization here from the API WG would be really great. What about having a separate HTTP header that indicates the "OpenStack Error Code", along with a generated URI for finding more information about the error? Something like: X-OpenStack-Error-Code: 1234 X-OpenStack-Error-Help-URI: http://errors.openstack.org/__1234 <http://errors.openstack.org/1234> That way is completely backwards compatible (since we wouldn't be changing response payloads) and we could handle i18n entirely via the HTTP help service running on errors.openstack.org <http://errors.openstack.org> <http://errors.openstack.org>. That could definitely be implemented in the short term, but if we're talking about API WG long term evolution, I'm not sure why a standard error payload body wouldn't be better. Agreed. And using the “X-“ prefix in headers has been deprecated for over 2 years now [1]. I don’t think we should be using it for new things. Everett [1] https://tools.ietf.org/html/__rfc6648 <https://tools.ietf.org/html/rfc6648> Ha! Good to know about the X- stuff :) Duly noted! -jay ______________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request@lists.__openstack.org?subject:__unsubscribe <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> -- Kevin Benton __________________________________________________________________________ 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
