Open Stack

On Thu, Mar 8, 2018 at 6:12 AM, Chris Dent <cdent+os at anticdent.org> wrote:
> On Wed, 7 Mar 2018, Hongbin Lu wrote:
>
>> As a brief recap, we were discussing how Neutron API server should behave
>> if invalid query parameters were inputted. Per my understanding, the general
>> consensus is to make Neutron API server behave consistently with other
>> OpenStack projects. The question for API-WG is if there is any guideline to
>> clarify how OpenStack projects should handle invalid query parameters. Query
>> parameters are various across different projects but it seems most projects
>> support these four categories of query parameters: sorting, pagination,
>> filtering, and fields selection. I saw API-WG provided a guideline to define
>> how to handle valid parameters of these categories [2], but it doesn’t seem
>> to define how to handle invalid parameters.
>>
>> I wonder if API-WG could clarify it. For example, if users provide an
>> invalid filter on listing the resources, should the API server ignore the
>> invalid filter and return a successful response? Or it should return an
>> error response? Below is a list of specific scenarios and examples to
>> consider:
>
>
> It's hard to find, but there's existing guidance that touches on
> this. From
> http://specs.openstack.org/openstack/api-wg/guidelines/http.html#failure-code-clarifications
> :
>
>     [I]f the API supports query parameters and a request contains an
>     unknown or unsupported parameter, the server should return a 400
>     Bad Request response. Invalid values in the request URL should
>     never be silently ignored, as the response may not match the
>     client’s expectation. For example, consider the case where an
>     API allows filtering on name by specifying ‘?name=foo’ in the
>     query string, and in one such request there is a typo, such as
>     ‘?nmae=foo’. If this error were silently ignored, the user would
>     get back all resources instead of just the ones named ‘foo’,
>     which would not be correct.  The error message that is returned
>     should clearly indicate the problem so that the user could
>     correct it and re-submit.
>
> This same logic can be applied to invalid fields used in parameters
> which can only accept a limited number of inputs (such as sort_key)
> so in the examples you give a 400 would be the way to ensure that
> the user agent is actually made aware that their request had issues.

+1. Nova also implemented query parameters validation using JSON
Schema [1] and 400 for few sorting param which were mainly joined
table and ignore others. We had to leave and ignore the unsupported
parameter as of now due to backward compatibility. But with newly
introduced API, we follow the above guidelines and 400 on any
additional or wrong parameter. Example [2].

>
> I hope this helps. Please let the api-sig know if you think we
> should adjust the guidelines to make this more explicit somehow.
>

..1 https://github.com/openstack/nova/blob/c7b54a80ac25f6a01d0a150c546532f5ae2592ce/nova/api/openstack/compute/schemas/servers.py#L334
..2 https://github.com/openstack/nova/blob/c7b54a80ac25f6a01d0a150c546532f5ae2592ce/nova/api/openstack/compute/schemas/migrations.py#L43

> --
> Chris Dent                      (⊙＿⊙')         https://anticdent.org/
> freenode: cdent                                         tw: @anticdent
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>