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)
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 <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 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
