Comment 3 for bug 1654084

We haven't formalized this yet for query strings (that I can find), but have discussed it and agree that 400 is the right response here as it is the only way of letting the client side know that something was less than correct about the query.

There's some related discussion in http://specs.openstack.org/openstack/api-wg/guidelines/http.html#failure-code-clarifications about incorrect object attributes in bodies which uses the same logic:

    ...the server should return a 400 Bad Request response. Do not handle the request as normal by ignoring the bad attribute. Returning an error allows the client side to know which attribute is wrong and have the potential to fix a bad request or bad code.

So I reckon there probably needs to be a generic guideline about this, and the filtering guideline should reference that when saying "return a 400 for bad filter params".

Originally I took the stance that the bad param should just be ignored (be liberal in what you accept), but it was exactly the case in this bug that convinced me otherwise.