Open Stack

On 30 January 2015 at 09:04, John Dickinson <me at not.mn> wrote:
> I think there are two points. First, the original requirement (in the first email on this thread) is not what's wanted:
>
> "...looking at the response body and HTTP response code an external system can’t understand what exactly went wrong. And parsing of error messages here is not the way we’d like to solve this problem."
>
> So adding a response body to parse doesn't solve the problem. The request as I read it is to have a set of well-defined error codes to know what happens.
>
> Second, my response is a little tongue-in-cheek, because I think the IIS response codes are a perfect example of extending a common, well-known protocol with custom extensions that breaks existing clients. I would hate to see us do that.
>
> So if we can't subtly break http, and we can't have error response documents, then we're left with custom error codes in the particular response-code class. eg 461 SecurityGroupNotFound or 462 InvalidKeyName (from the original examples)

http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-26#section-6

I'm quite certain IIS isn't putting 401.1 in the status code - it
would fail on every client everywhere - I think they may include an
extra header though.

I don't understand your objection to a body: AIUI the original
complaint it was that parsing a free-form text field was bad.
Structured data (e.g. JSON) is a whole different kettle of fish, as it
could have a freeform field but also a machine understood field (be
that numeric, an enumeration or whatever).

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud