Open Stack

So do we just use whatever name we want instead? Can we use 'referrer'? ;-)

On Tue, Feb 3, 2015 at 5:43 AM, Jay Pipes <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>> 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: ComputeFeatureUnsupportedOnInstanceType,
>>>>>      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
>>>>
>>>> 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>.
>>>>
>>>
>>> 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
>>
>
> 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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150203/2b8bc293/attachment.html>