Invalid parameters in list image requests return inconsistent responses

[Anna Eilering]

Using glance v2, most recent commit is 6dc5477a12b9b904332ac6fe7932abbc7a0275a7.

I see that GET(list image) requests with different invalid parameters return different response codes. I would expect that invalid parameters would be treated consistently. In other words I would expect invalid parameters to always return a 400 or ignore invalid parameters and return a 200.

Examples:

An invalid parameter of 'id=invalid' returns a 200
------------
REQUEST SENT
------------
request method..: GET
request url.....: <ENDPOINT>/v2/images
request params..: id=invalid
request headers.: {'Accept-Encoding': 'gzip, deflate', 'Accept': 'application/json', 'User-Agent': 'python-requests/2.7.0 CPython/2.7.8 Linux/2.6.32-431.29.2.el6.x86_64', 'Connection': 'keep-alive', 'X-Auth-Token': u'<TOKEN>', 'Content-Type': 'application/json'}
request body....: None

-----------------
RESPONSE RECEIVED
-----------------
response status..: <Response [200]>
response time....: 0.236920833588
response headers.: {'content-length': '80', 'via': '1.1 Repose (Repose/2.12)', 'server': 'Jetty(8.0.y.z-SNAPSHOT)', 'date': 'Mon, 20 Jul 2015 15:17:43 GMT', 'content-type': 'application/json; charset=UTF-8', 'x-openstack-request-id': 'req-req-093b3157-451e-4266-8297-fa42c0605c2f'}
response body....: {"images": [], "schema": "/v2/schemas/images", "first": "/v2/images?id=invalid"}
-------------------------------------------------------------------------------

An invalid parameter of 'limit=invalid' returns a 400

------------
REQUEST SENT
------------
request method..: GET
request url.....:<ENDPOINT>/v2/images
request params..: limit=invalid
request headers.: {'Accept-Encoding': 'gzip, deflate', 'Accept': 'application/json', 'User-Agent': 'python-requests/2.7.0 CPython/2.7.8 Linux/2.6.32-431.29.2.el6.x86_64', 'Connection': 'keep-alive', 'X-Auth-Token': u'<TOKEN>', 'Content-Type': 'application/json'}
request body....: None

-----------------
RESPONSE RECEIVED
-----------------
response status..: <Response [400]>
response time....: 0.143214941025
response headers.: {'content-length': '52', 'via': '1.1 Repose (Repose/2.12)', 'server': 'Jetty(8.0.y.z-SNAPSHOT)', 'date': 'Mon, 20 Jul 2015 15:17:43 GMT', 'content-type': 'text/plain;charset=UTF-8', 'x-openstack-request-id': 'req-req-5067dcf8-a765-4336-88d5-3a85a3d50910'}
response body....: 400 Bad Request

limit param must be an integer

Here are the different invalid params I have attempted and their results:

Returns a 200:
request params..: auto_disk_config=invalid
request params..: checksum=invalid
request params..: container_format=invalid
request params..: created_at=invalid
request params..: disk_format=invalid
request params..: id=invalid
request params..: image_type=invalid
request params..: min_disk=invalid
request params..: min_ram=invalid
request params..: name=invalid
request params..: os_type=invalid
request params..: owner=invalid
request params..: protected=invalid
request params..: size=invalid
request params..: status=invalid
request params..: tag=invalid
request params..: updated_at=invalid

Returns a 400:
request params..: limit=invalid
request params..: marker=invalid
request params..: member_status=invalid&visibility=invalid
request params..: size_max=invalid
request params..: size_min=invalid
request params..: sort_dir=invalid
request params..: sort_key=invalid
request params..: visibility=invalid

[Nikhil Komawar (nikhil-komawar)]

I think we need to validate at least the filtering on base properties, not all filters can be validated on value so we should check the type of the request param for that key to validate the request. 400 should be returned on incorrect type of request param key(s).

[Vishakha Agarwal (vishakha.agarwal)]

Hi all,

Is anyone working on it??

Thanks

[Vishakha Agarwal (vishakha.agarwal)]

Whenever passing invalid parameter/value the responses are
http://paste.openstack.org/show/724826/
As per my understanding the error is handled by the python parser and not the glance client. Also no request goes to the server. Thus the bug seems invalid.