[mdx] GH issue 1: error code in response when metadata would be invalid

[Ian Young]

In https://github.com/iay/md-query/issues/1, Leif said:

> The text currently sais "If the responder can not create a valid document it MUST respond with a 500 status code." To me it feels more sensible to use 400 (Bad Request) for that error to distinguish it from any other server-related problem, crash etc.

The part of the text we're looking at here currently says this:

> If the responder can not create a valid document it MUST
> respond with a 500 status code.  An example of such an error would be
> the case where the result of the query is metadata for multiple
> entities but the request content type does not support returning
> multiple results in a single document.


This doesn't apply to SAML, of course, which mandates a different document element in the 1-result case than the >1-result case. That's now documented in the md-query-saml spec.

So I'm not sure if this is a hypothetical or not. I'd guess that JSON-based metadata is also capable of returning multiple values, for example. But let's say there's a metadata type which is intrinsically single-result; what should the status code be?

The HTTP RFC has this to say about status codes:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

> 400 Bad Request
> 
> The request could not be understood by the server due to malformed syntax.

This isn't right; the request syntax is fine and the server understands it, it's just impossible to construct a document to return the result in.

> 500 Internal Server Error
> 
> The server encountered an unexpected condition which prevented it from fulfilling the request.

This seems incorrect too, though. It's not like the server has fallen over in some way. I think it's less obviously wrong, but it's not right either.

So I waded through the rest of the codes in the HTTP spec and found this one:

> 406 Not Acceptable
> 
> The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request.


This seems pretty much exactly what we want, so I propose we resolve this by changing the text accordingly.

Any comments? Leif in particular?

	-- Ian



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5943 bytes
Desc: not available
URL: <http://lists.iay.org.uk/pipermail/mdx-iay.org.uk/attachments/20131126/76135335/smime-0001.p7s>