hackermd
commented
5 years ago I figured out that the server is supposed to ignore unsupported query parameters according to the current standard. Therefore, the behavior is less unexpected.
However, CP1583 also states that a warning or error message should be included in the payload:
The origin server shall ignore any unsupported Query Parameters. The origin server shall process the request as if the unsupported parameters were not present, and should include a payload containing an appropriate warning or error message.
In addition, the server should return a 400 error response if the value of a supported query parameter is invalid:
If a supported Query Parameter has an invalid value, the origin server shall return a 400 (Bad Request) error response, and should include should include a payload containing an appropriate warning or error message.
A complicating factor is that the archive can be configured to support additional query parameters. From a client perspective, it would therefore be desirable to receive a warning when a query parameter has been ignored instead of having to entirely rely on the documentation in the conformance statement.
When I search for instances via QIDO-RS and filter based on instance attributes that are not supported according to the conformance statement, the response payload contains all available instance representations even though non of the instances matches the search criteria.
For example, when searching for instances with a specific
ImageTypethe service will simply ignore the query string and respond with a payload that contains the representations of all available instances.To me, this behavior is unexpected and highly problematic for clients.
I would either expect a 400 Client Error to indicate that this query is not supported or an empty payload and a 204 Empty Response to indicate that there are no matching results.