On 30 January 2015 at 09:04, John Dickinson <m...@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)


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).


Robert Collins <rbtcoll...@hp.com>
Distinguished Technologist
HP Converged Cloud

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to