Open Stack

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 <jaypipes at gmail.com
> <mailto:jaypipes at gmail.com>> wrote:
>
>     On 02/02/2015 09:07 PM, Everett Toews wrote:
>
>         On Feb 2, 2015, at 7:24 PM, Sean Dague <sean at dague.net
>         <mailto:sean at dague.net>
>         <mailto:sean at dague.net <mailto:sean at 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 at lists.__openstack.org?subject:__unsubscribe
>     <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>