yahoo-eng-team team mailing list archive

[Hongbin Lu <1749820@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

Problem
=======
If users provide different kinds of invalid query parameters, the behavior of neutron server looks unpredictable. Sometimes, it tolerates the invalid inputs and return a successful response. Sometimes, it invalidates the inputs and return an error response. In addition, the error type is unpredictable and the format of the error message is inconsistent.

1. Invalid sort_key and/or sort_dir:

Neutron returns at least two error types: BadRequest [1] [2], HTTPBadRequest [3] [4][5]. In addition, the format of error message looks inconsistent. For example, it has the following forms:
* Bad networks request: Attribute '...' references another resource and cannot be used to sort '...' resources. [1]
* Bad networks request: '...' is an invalid attribute for sort key. [2]
* [u'...'] is invalid attribute for sort_keys [3]

2. Invalid limit and/or marker:

Sometimes, neutron returns error with one of the following types:
BadRequest [6], NetworkNotFound [7]. Sometimes, neutron doesn't return
error [8].

3. Invalid filter

Sometimes, neutron returns error with one of the following types:
InvalidInput [9], NotImplementedError [10]. Sometimes, neutron doesn't
return error [11]

4. Invalid fields

Neutron always returns a successful response [12] regardless of validity
of the inputs.

Proposal
========
Improve the predictability of neutron server by handling invalid query parameters consistently. Optimally, neutron server behaves as following:
* Always returns error (i.e. 400 response) on invalid user inputs. IMHO, ignoring invalid inputs (like [8][11][12]) is bad.
* Make error type predictable. There are several options to achieve this. One option is to group different kinds of invalid inputs and define a specific error type for each group (i.e. InvalidSorting for #1, InvalidPagination for #2, InvalidFilter for #3, etc.).
* Make the format of error message consistent. For example, the format of error messages [1][2][3] can be consolidated into one.

Referred examples
=================

[1] GET "/v2.0/networks?sort_dir=desc&sort_key=segments"
{"NeutronError": {"message": "Bad networks request: Attribute 'segments' references another resource and cannot be used to sort 'networks' resources.", "type": "BadRequest", "detail": ""}}

[2] GET "/v2.0/networks?sort_dir=desc&sort_key=provider:physical_network"
{"NeutronError": {"message": "Bad networks request: 'provider:physical_network' is an invalid attribute for sort key.", "type": "BadRequest", "detail": ""}}

[3] GET "/v2.0/networks?sort_dir=desc&sort_key=xxx"
{"NeutronError": {"message": "[u'xxx'] is invalid attribute for sort_keys", "type": "HTTPBadRequest", "detail": ""}}

[4] GET "/v2.0/networks?sort_dir=xxx"
{"NeutronError": {"message": "The number of sort_keys and sort_dirs must be same", "type": "HTTPBadRequest", "detail": ""}}

[5] GET "/v2.0/networks?sort_dir=xxx&sort_key=id"
{"NeutronError": {"message": "[u'xxx'] is invalid value for sort_dirs, valid value is 'asc' and 'desc'", "type": "HTTPBadRequest", "detail": ""}}

[6] GET "/v2.0/networks?limit=-1"
{"NeutronError": {"message": "Bad limit request: Limit must be an integer 0 or greater and not '-1'.", "type": "BadRequest", "detail": ""}}

[7] GET "/v2.0/networks?limit=1&marker=xxx"
{"NeutronError": {"message": "Network xxx could not be found.", "type": "NetworkNotFound", "detail": ""}}

[8] GET "/v2.0/networks?marker=xxx"
{"networks":...}

[9] GET "/v2.0/networks?admin_state_up=xxx"
{"NeutronError": {"message": "Invalid input for operation: 'xxx' cannot be converted to boolean.", "type": "InvalidInput", "detail": ""}}

[10] GET "/v2.0/networks?subnets=11"
{"NotImplementedError": {"message": "in_() not yet supported for relationships.  For a simple many-to-one, use in_() against the set of foreign key values.", "type": "NotImplementedError", "detail": ""}}

[11] GET "/v2.0/networks?xxx=11"
{"networks":...}

[12] GET "/v2.0/networks?fields=xxx"
{"networks":...}

** Affects: neutron
     Importance: Undecided
     Assignee: Hongbin Lu (hongbin.lu)
         Status: New

** Description changed:

  Problem
  =======
  
  If users provide different kinds of invalid query parameters, the
  behavior of neutron server looks unpredictable. Sometimes, it tolerates
  the invalid inputs and return a successful response. Sometimes, it
  invalidates the inputs and return an error response. In addition, the
  error type is unpredictable and the format of the error message is
  inconsistent.
  
  1. Invalid sort_key and/or sort_dir:
  
  Neutron returns at least three error types: BadRequest [1] [2], HTTPBadRequest [3], HTTPBadRequest [4][5]. In addition, the format of error message looks inconsistent. For example, it has the following forms:
  * Bad networks request: Attribute '...' references another resource and cannot be used to sort '...' resources. [1]
  * Bad networks request: '...' is an invalid attribute for sort key. [2]
  * [u'...'] is invalid attribute for sort_keys [3]
  
  2. Invalid limit and/or marker:
  
  Sometimes, neutron returns error with one of the following types:
  BadRequest [6], NetworkNotFound [7]. Sometimes, neutron doesn't return
  error [8].
  
  3. Invalid filter
  
  Sometimes, neutron returns error with one of the following types:
  InvalidInput [9], NotImplementedError [10]. Sometimes, neutron doesn't
  return error [11]
  
  4. Invalid fields
  
  Neutron always returns a successful response [12] regardless of validity
  of the inputs.
  
  Proposal
  ========
  Improve the predictability of neutron server on handling invalid query parameters. Optimally, neutron server behaves as following:
  * Always returns error (i.e. 400 response) on invalid user inputs. IMHO, ignoring invalid inputs (like [8][11][12]) is bad.
  * Make error type predictable. There are several options to achieve this. One option is to group different kinds of invalid inputs and define a specify error type for each group (i.e. InvalidSortKey, InvalidLimit, InvalidFilter, etc.). Another option is to define a generic error type (i.e. BadRequest) for all.
  * Make format of error message consistent. For example, the format of error messages [1][2][3] can be consolidated into one.
  
+ Referred examples
+ =================
+ 
  [1] GET "/v2.0/networks?sort_dir=desc&sort_key=segments"
  {"NeutronError": {"message": "Bad networks request: Attribute 'segments' references another resource and cannot be used to sort 'networks' resources.", "type": "BadRequest", "detail": ""}}
  
  [2] GET "/v2.0/networks?sort_dir=desc&sort_key=provider:physical_network"
  {"NeutronError": {"message": "Bad networks request: 'provider:physical_network' is an invalid attribute for sort key.", "type": "BadRequest", "detail": ""}}
  
  [3] GET "/v2.0/networks?sort_dir=desc&sort_key=xxx"
  {"NeutronError": {"message": "[u'xxx'] is invalid attribute for sort_keys", "type": "HTTPBadRequest", "detail": ""}}
  
  [4] GET "/v2.0/networks?sort_dir=xxx"
  {"NeutronError": {"message": "The number of sort_keys and sort_dirs must be same", "type": "HTTPBadRequest", "detail": ""}}
  
  [5] GET "/v2.0/networks?sort_dir=xxx&sort_key=id"
  {"NeutronError": {"message": "[u'xxx'] is invalid value for sort_dirs, valid value is 'asc' and 'desc'", "type": "HTTPBadRequest", "detail": ""}}
  
  [6] GET "/v2.0/networks?limit=-1"
  {"NeutronError": {"message": "Bad limit request: Limit must be an integer 0 or greater and not '-1'.", "type": "BadRequest", "detail": ""}}
  
  [7] GET "/v2.0/networks?limit=1&marker=xxx"
  {"NeutronError": {"message": "Network xxx could not be found.", "type": "NetworkNotFound", "detail": ""}}
  
  [8] GET "/v2.0/networks?marker=xxx"
  {"networks":...}
  
  [9] GET "/v2.0/networks?admin_state_up=xxx"
  {"NeutronError": {"message": "Invalid input for operation: 'xxx' cannot be converted to boolean.", "type": "InvalidInput", "detail": ""}}
  
  [10] GET "/v2.0/networks?subnets=11"
  {"NotImplementedError": {"message": "in_() not yet supported for relationships.  For a simple many-to-one, use in_() against the set of foreign key values.", "type": "NotImplementedError", "detail": ""}}
  
  [11] GET "/v2.0/networks?xxx=11"
  {"networks":...}
  
  [12] GET "/v2.0/networks?fields=xxx"
  {"networks":...}

** Description changed:

  Problem
  =======
- 
- If users provide different kinds of invalid query parameters, the
- behavior of neutron server looks unpredictable. Sometimes, it tolerates
- the invalid inputs and return a successful response. Sometimes, it
- invalidates the inputs and return an error response. In addition, the
- error type is unpredictable and the format of the error message is
- inconsistent.
+ If users provide different kinds of invalid query parameters, the behavior of neutron server looks unpredictable. Sometimes, it tolerates the invalid inputs and return a successful response. Sometimes, it invalidates the inputs and return an error response. In addition, the error type is unpredictable and the format of the error message is inconsistent.
  
  1. Invalid sort_key and/or sort_dir:
  
  Neutron returns at least three error types: BadRequest [1] [2], HTTPBadRequest [3], HTTPBadRequest [4][5]. In addition, the format of error message looks inconsistent. For example, it has the following forms:
  * Bad networks request: Attribute '...' references another resource and cannot be used to sort '...' resources. [1]
  * Bad networks request: '...' is an invalid attribute for sort key. [2]
  * [u'...'] is invalid attribute for sort_keys [3]
  
  2. Invalid limit and/or marker:
  
  Sometimes, neutron returns error with one of the following types:
  BadRequest [6], NetworkNotFound [7]. Sometimes, neutron doesn't return
  error [8].
  
  3. Invalid filter
  
  Sometimes, neutron returns error with one of the following types:
  InvalidInput [9], NotImplementedError [10]. Sometimes, neutron doesn't
  return error [11]
  
  4. Invalid fields
  
  Neutron always returns a successful response [12] regardless of validity
  of the inputs.
  
  Proposal
  ========
  Improve the predictability of neutron server on handling invalid query parameters. Optimally, neutron server behaves as following:
  * Always returns error (i.e. 400 response) on invalid user inputs. IMHO, ignoring invalid inputs (like [8][11][12]) is bad.
  * Make error type predictable. There are several options to achieve this. One option is to group different kinds of invalid inputs and define a specify error type for each group (i.e. InvalidSortKey, InvalidLimit, InvalidFilter, etc.). Another option is to define a generic error type (i.e. BadRequest) for all.
  * Make format of error message consistent. For example, the format of error messages [1][2][3] can be consolidated into one.
  
  Referred examples
  =================
  
  [1] GET "/v2.0/networks?sort_dir=desc&sort_key=segments"
  {"NeutronError": {"message": "Bad networks request: Attribute 'segments' references another resource and cannot be used to sort 'networks' resources.", "type": "BadRequest", "detail": ""}}
  
  [2] GET "/v2.0/networks?sort_dir=desc&sort_key=provider:physical_network"
  {"NeutronError": {"message": "Bad networks request: 'provider:physical_network' is an invalid attribute for sort key.", "type": "BadRequest", "detail": ""}}
  
  [3] GET "/v2.0/networks?sort_dir=desc&sort_key=xxx"
  {"NeutronError": {"message": "[u'xxx'] is invalid attribute for sort_keys", "type": "HTTPBadRequest", "detail": ""}}
  
  [4] GET "/v2.0/networks?sort_dir=xxx"
  {"NeutronError": {"message": "The number of sort_keys and sort_dirs must be same", "type": "HTTPBadRequest", "detail": ""}}
  
  [5] GET "/v2.0/networks?sort_dir=xxx&sort_key=id"
  {"NeutronError": {"message": "[u'xxx'] is invalid value for sort_dirs, valid value is 'asc' and 'desc'", "type": "HTTPBadRequest", "detail": ""}}
  
  [6] GET "/v2.0/networks?limit=-1"
  {"NeutronError": {"message": "Bad limit request: Limit must be an integer 0 or greater and not '-1'.", "type": "BadRequest", "detail": ""}}
  
  [7] GET "/v2.0/networks?limit=1&marker=xxx"
  {"NeutronError": {"message": "Network xxx could not be found.", "type": "NetworkNotFound", "detail": ""}}
  
  [8] GET "/v2.0/networks?marker=xxx"
  {"networks":...}
  
  [9] GET "/v2.0/networks?admin_state_up=xxx"
  {"NeutronError": {"message": "Invalid input for operation: 'xxx' cannot be converted to boolean.", "type": "InvalidInput", "detail": ""}}
  
  [10] GET "/v2.0/networks?subnets=11"
  {"NotImplementedError": {"message": "in_() not yet supported for relationships.  For a simple many-to-one, use in_() against the set of foreign key values.", "type": "NotImplementedError", "detail": ""}}
  
  [11] GET "/v2.0/networks?xxx=11"
  {"networks":...}
  
  [12] GET "/v2.0/networks?fields=xxx"
  {"networks":...}

** Description changed:

  Problem
  =======
  If users provide different kinds of invalid query parameters, the behavior of neutron server looks unpredictable. Sometimes, it tolerates the invalid inputs and return a successful response. Sometimes, it invalidates the inputs and return an error response. In addition, the error type is unpredictable and the format of the error message is inconsistent.
  
  1. Invalid sort_key and/or sort_dir:
  
- Neutron returns at least three error types: BadRequest [1] [2], HTTPBadRequest [3], HTTPBadRequest [4][5]. In addition, the format of error message looks inconsistent. For example, it has the following forms:
+ Neutron returns at least two error types: BadRequest [1] [2], HTTPBadRequest [3] [4][5]. In addition, the format of error message looks inconsistent. For example, it has the following forms:
  * Bad networks request: Attribute '...' references another resource and cannot be used to sort '...' resources. [1]
  * Bad networks request: '...' is an invalid attribute for sort key. [2]
  * [u'...'] is invalid attribute for sort_keys [3]
  
  2. Invalid limit and/or marker:
  
  Sometimes, neutron returns error with one of the following types:
  BadRequest [6], NetworkNotFound [7]. Sometimes, neutron doesn't return
  error [8].
  
  3. Invalid filter
  
  Sometimes, neutron returns error with one of the following types:
  InvalidInput [9], NotImplementedError [10]. Sometimes, neutron doesn't
  return error [11]
  
  4. Invalid fields
  
  Neutron always returns a successful response [12] regardless of validity
  of the inputs.
  
  Proposal
  ========
  Improve the predictability of neutron server on handling invalid query parameters. Optimally, neutron server behaves as following:
  * Always returns error (i.e. 400 response) on invalid user inputs. IMHO, ignoring invalid inputs (like [8][11][12]) is bad.
  * Make error type predictable. There are several options to achieve this. One option is to group different kinds of invalid inputs and define a specify error type for each group (i.e. InvalidSortKey, InvalidLimit, InvalidFilter, etc.). Another option is to define a generic error type (i.e. BadRequest) for all.
  * Make format of error message consistent. For example, the format of error messages [1][2][3] can be consolidated into one.
  
  Referred examples
  =================
  
  [1] GET "/v2.0/networks?sort_dir=desc&sort_key=segments"
  {"NeutronError": {"message": "Bad networks request: Attribute 'segments' references another resource and cannot be used to sort 'networks' resources.", "type": "BadRequest", "detail": ""}}
  
  [2] GET "/v2.0/networks?sort_dir=desc&sort_key=provider:physical_network"
  {"NeutronError": {"message": "Bad networks request: 'provider:physical_network' is an invalid attribute for sort key.", "type": "BadRequest", "detail": ""}}
  
  [3] GET "/v2.0/networks?sort_dir=desc&sort_key=xxx"
  {"NeutronError": {"message": "[u'xxx'] is invalid attribute for sort_keys", "type": "HTTPBadRequest", "detail": ""}}
  
  [4] GET "/v2.0/networks?sort_dir=xxx"
  {"NeutronError": {"message": "The number of sort_keys and sort_dirs must be same", "type": "HTTPBadRequest", "detail": ""}}
  
  [5] GET "/v2.0/networks?sort_dir=xxx&sort_key=id"
  {"NeutronError": {"message": "[u'xxx'] is invalid value for sort_dirs, valid value is 'asc' and 'desc'", "type": "HTTPBadRequest", "detail": ""}}
  
  [6] GET "/v2.0/networks?limit=-1"
  {"NeutronError": {"message": "Bad limit request: Limit must be an integer 0 or greater and not '-1'.", "type": "BadRequest", "detail": ""}}
  
  [7] GET "/v2.0/networks?limit=1&marker=xxx"
  {"NeutronError": {"message": "Network xxx could not be found.", "type": "NetworkNotFound", "detail": ""}}
  
  [8] GET "/v2.0/networks?marker=xxx"
  {"networks":...}
  
  [9] GET "/v2.0/networks?admin_state_up=xxx"
  {"NeutronError": {"message": "Invalid input for operation: 'xxx' cannot be converted to boolean.", "type": "InvalidInput", "detail": ""}}
  
  [10] GET "/v2.0/networks?subnets=11"
  {"NotImplementedError": {"message": "in_() not yet supported for relationships.  For a simple many-to-one, use in_() against the set of foreign key values.", "type": "NotImplementedError", "detail": ""}}
  
  [11] GET "/v2.0/networks?xxx=11"
  {"networks":...}
  
  [12] GET "/v2.0/networks?fields=xxx"
  {"networks":...}

** Description changed:

  Problem
  =======
  If users provide different kinds of invalid query parameters, the behavior of neutron server looks unpredictable. Sometimes, it tolerates the invalid inputs and return a successful response. Sometimes, it invalidates the inputs and return an error response. In addition, the error type is unpredictable and the format of the error message is inconsistent.
  
  1. Invalid sort_key and/or sort_dir:
  
  Neutron returns at least two error types: BadRequest [1] [2], HTTPBadRequest [3] [4][5]. In addition, the format of error message looks inconsistent. For example, it has the following forms:
  * Bad networks request: Attribute '...' references another resource and cannot be used to sort '...' resources. [1]
  * Bad networks request: '...' is an invalid attribute for sort key. [2]
  * [u'...'] is invalid attribute for sort_keys [3]
  
  2. Invalid limit and/or marker:
  
  Sometimes, neutron returns error with one of the following types:
  BadRequest [6], NetworkNotFound [7]. Sometimes, neutron doesn't return
  error [8].
  
  3. Invalid filter
  
  Sometimes, neutron returns error with one of the following types:
  InvalidInput [9], NotImplementedError [10]. Sometimes, neutron doesn't
  return error [11]
  
  4. Invalid fields
  
  Neutron always returns a successful response [12] regardless of validity
  of the inputs.
  
  Proposal
  ========
- Improve the predictability of neutron server on handling invalid query parameters. Optimally, neutron server behaves as following:
+ Improve the predictability of neutron server by handling invalid query parameters inconsistently. Optimally, neutron server behaves as following:
  * Always returns error (i.e. 400 response) on invalid user inputs. IMHO, ignoring invalid inputs (like [8][11][12]) is bad.
  * Make error type predictable. There are several options to achieve this. One option is to group different kinds of invalid inputs and define a specify error type for each group (i.e. InvalidSortKey, InvalidLimit, InvalidFilter, etc.). Another option is to define a generic error type (i.e. BadRequest) for all.
  * Make format of error message consistent. For example, the format of error messages [1][2][3] can be consolidated into one.
  
  Referred examples
  =================
  
  [1] GET "/v2.0/networks?sort_dir=desc&sort_key=segments"
  {"NeutronError": {"message": "Bad networks request: Attribute 'segments' references another resource and cannot be used to sort 'networks' resources.", "type": "BadRequest", "detail": ""}}
  
  [2] GET "/v2.0/networks?sort_dir=desc&sort_key=provider:physical_network"
  {"NeutronError": {"message": "Bad networks request: 'provider:physical_network' is an invalid attribute for sort key.", "type": "BadRequest", "detail": ""}}
  
  [3] GET "/v2.0/networks?sort_dir=desc&sort_key=xxx"
  {"NeutronError": {"message": "[u'xxx'] is invalid attribute for sort_keys", "type": "HTTPBadRequest", "detail": ""}}
  
  [4] GET "/v2.0/networks?sort_dir=xxx"
  {"NeutronError": {"message": "The number of sort_keys and sort_dirs must be same", "type": "HTTPBadRequest", "detail": ""}}
  
  [5] GET "/v2.0/networks?sort_dir=xxx&sort_key=id"
  {"NeutronError": {"message": "[u'xxx'] is invalid value for sort_dirs, valid value is 'asc' and 'desc'", "type": "HTTPBadRequest", "detail": ""}}
  
  [6] GET "/v2.0/networks?limit=-1"
  {"NeutronError": {"message": "Bad limit request: Limit must be an integer 0 or greater and not '-1'.", "type": "BadRequest", "detail": ""}}
  
  [7] GET "/v2.0/networks?limit=1&marker=xxx"
  {"NeutronError": {"message": "Network xxx could not be found.", "type": "NetworkNotFound", "detail": ""}}
  
  [8] GET "/v2.0/networks?marker=xxx"
  {"networks":...}
  
  [9] GET "/v2.0/networks?admin_state_up=xxx"
  {"NeutronError": {"message": "Invalid input for operation: 'xxx' cannot be converted to boolean.", "type": "InvalidInput", "detail": ""}}
  
  [10] GET "/v2.0/networks?subnets=11"
  {"NotImplementedError": {"message": "in_() not yet supported for relationships.  For a simple many-to-one, use in_() against the set of foreign key values.", "type": "NotImplementedError", "detail": ""}}
  
  [11] GET "/v2.0/networks?xxx=11"
  {"networks":...}
  
  [12] GET "/v2.0/networks?fields=xxx"
  {"networks":...}

** Description changed:

  Problem
  =======
  If users provide different kinds of invalid query parameters, the behavior of neutron server looks unpredictable. Sometimes, it tolerates the invalid inputs and return a successful response. Sometimes, it invalidates the inputs and return an error response. In addition, the error type is unpredictable and the format of the error message is inconsistent.
  
  1. Invalid sort_key and/or sort_dir:
  
  Neutron returns at least two error types: BadRequest [1] [2], HTTPBadRequest [3] [4][5]. In addition, the format of error message looks inconsistent. For example, it has the following forms:
  * Bad networks request: Attribute '...' references another resource and cannot be used to sort '...' resources. [1]
  * Bad networks request: '...' is an invalid attribute for sort key. [2]
  * [u'...'] is invalid attribute for sort_keys [3]
  
  2. Invalid limit and/or marker:
  
  Sometimes, neutron returns error with one of the following types:
  BadRequest [6], NetworkNotFound [7]. Sometimes, neutron doesn't return
  error [8].
  
  3. Invalid filter
  
  Sometimes, neutron returns error with one of the following types:
  InvalidInput [9], NotImplementedError [10]. Sometimes, neutron doesn't
  return error [11]
  
  4. Invalid fields
  
  Neutron always returns a successful response [12] regardless of validity
  of the inputs.
  
  Proposal
  ========
- Improve the predictability of neutron server by handling invalid query parameters inconsistently. Optimally, neutron server behaves as following:
+ Improve the predictability of neutron server by handling invalid query parameters consistently. Optimally, neutron server behaves as following:
  * Always returns error (i.e. 400 response) on invalid user inputs. IMHO, ignoring invalid inputs (like [8][11][12]) is bad.
  * Make error type predictable. There are several options to achieve this. One option is to group different kinds of invalid inputs and define a specify error type for each group (i.e. InvalidSortKey, InvalidLimit, InvalidFilter, etc.). Another option is to define a generic error type (i.e. BadRequest) for all.
  * Make format of error message consistent. For example, the format of error messages [1][2][3] can be consolidated into one.
  
  Referred examples
  =================
  
  [1] GET "/v2.0/networks?sort_dir=desc&sort_key=segments"
  {"NeutronError": {"message": "Bad networks request: Attribute 'segments' references another resource and cannot be used to sort 'networks' resources.", "type": "BadRequest", "detail": ""}}
  
  [2] GET "/v2.0/networks?sort_dir=desc&sort_key=provider:physical_network"
  {"NeutronError": {"message": "Bad networks request: 'provider:physical_network' is an invalid attribute for sort key.", "type": "BadRequest", "detail": ""}}
  
  [3] GET "/v2.0/networks?sort_dir=desc&sort_key=xxx"
  {"NeutronError": {"message": "[u'xxx'] is invalid attribute for sort_keys", "type": "HTTPBadRequest", "detail": ""}}
  
  [4] GET "/v2.0/networks?sort_dir=xxx"
  {"NeutronError": {"message": "The number of sort_keys and sort_dirs must be same", "type": "HTTPBadRequest", "detail": ""}}
  
  [5] GET "/v2.0/networks?sort_dir=xxx&sort_key=id"
  {"NeutronError": {"message": "[u'xxx'] is invalid value for sort_dirs, valid value is 'asc' and 'desc'", "type": "HTTPBadRequest", "detail": ""}}
  
  [6] GET "/v2.0/networks?limit=-1"
  {"NeutronError": {"message": "Bad limit request: Limit must be an integer 0 or greater and not '-1'.", "type": "BadRequest", "detail": ""}}
  
  [7] GET "/v2.0/networks?limit=1&marker=xxx"
  {"NeutronError": {"message": "Network xxx could not be found.", "type": "NetworkNotFound", "detail": ""}}
  
  [8] GET "/v2.0/networks?marker=xxx"
  {"networks":...}
  
  [9] GET "/v2.0/networks?admin_state_up=xxx"
  {"NeutronError": {"message": "Invalid input for operation: 'xxx' cannot be converted to boolean.", "type": "InvalidInput", "detail": ""}}
  
  [10] GET "/v2.0/networks?subnets=11"
  {"NotImplementedError": {"message": "in_() not yet supported for relationships.  For a simple many-to-one, use in_() against the set of foreign key values.", "type": "NotImplementedError", "detail": ""}}
  
  [11] GET "/v2.0/networks?xxx=11"
  {"networks":...}
  
  [12] GET "/v2.0/networks?fields=xxx"
  {"networks":...}

** Description changed:

  Problem
  =======
  If users provide different kinds of invalid query parameters, the behavior of neutron server looks unpredictable. Sometimes, it tolerates the invalid inputs and return a successful response. Sometimes, it invalidates the inputs and return an error response. In addition, the error type is unpredictable and the format of the error message is inconsistent.
  
  1. Invalid sort_key and/or sort_dir:
  
  Neutron returns at least two error types: BadRequest [1] [2], HTTPBadRequest [3] [4][5]. In addition, the format of error message looks inconsistent. For example, it has the following forms:
  * Bad networks request: Attribute '...' references another resource and cannot be used to sort '...' resources. [1]
  * Bad networks request: '...' is an invalid attribute for sort key. [2]
  * [u'...'] is invalid attribute for sort_keys [3]
  
  2. Invalid limit and/or marker:
  
  Sometimes, neutron returns error with one of the following types:
  BadRequest [6], NetworkNotFound [7]. Sometimes, neutron doesn't return
  error [8].
  
  3. Invalid filter
  
  Sometimes, neutron returns error with one of the following types:
  InvalidInput [9], NotImplementedError [10]. Sometimes, neutron doesn't
  return error [11]
  
  4. Invalid fields
  
  Neutron always returns a successful response [12] regardless of validity
  of the inputs.
  
  Proposal
  ========
  Improve the predictability of neutron server by handling invalid query parameters consistently. Optimally, neutron server behaves as following:
  * Always returns error (i.e. 400 response) on invalid user inputs. IMHO, ignoring invalid inputs (like [8][11][12]) is bad.
- * Make error type predictable. There are several options to achieve this. One option is to group different kinds of invalid inputs and define a specify error type for each group (i.e. InvalidSortKey, InvalidLimit, InvalidFilter, etc.). Another option is to define a generic error type (i.e. BadRequest) for all.
+ * Make error type predictable. There are several options to achieve this. One option is to group different kinds of invalid inputs and define a specific error type for each group (i.e. InvalidSortKey, InvalidLimit, InvalidFilter, etc.). Another option is to define a generic error type (i.e. BadRequest) for all.
  * Make format of error message consistent. For example, the format of error messages [1][2][3] can be consolidated into one.
  
  Referred examples
  =================
  
  [1] GET "/v2.0/networks?sort_dir=desc&sort_key=segments"
  {"NeutronError": {"message": "Bad networks request: Attribute 'segments' references another resource and cannot be used to sort 'networks' resources.", "type": "BadRequest", "detail": ""}}
  
  [2] GET "/v2.0/networks?sort_dir=desc&sort_key=provider:physical_network"
  {"NeutronError": {"message": "Bad networks request: 'provider:physical_network' is an invalid attribute for sort key.", "type": "BadRequest", "detail": ""}}
  
  [3] GET "/v2.0/networks?sort_dir=desc&sort_key=xxx"
  {"NeutronError": {"message": "[u'xxx'] is invalid attribute for sort_keys", "type": "HTTPBadRequest", "detail": ""}}
  
  [4] GET "/v2.0/networks?sort_dir=xxx"
  {"NeutronError": {"message": "The number of sort_keys and sort_dirs must be same", "type": "HTTPBadRequest", "detail": ""}}
  
  [5] GET "/v2.0/networks?sort_dir=xxx&sort_key=id"
  {"NeutronError": {"message": "[u'xxx'] is invalid value for sort_dirs, valid value is 'asc' and 'desc'", "type": "HTTPBadRequest", "detail": ""}}
  
  [6] GET "/v2.0/networks?limit=-1"
  {"NeutronError": {"message": "Bad limit request: Limit must be an integer 0 or greater and not '-1'.", "type": "BadRequest", "detail": ""}}
  
  [7] GET "/v2.0/networks?limit=1&marker=xxx"
  {"NeutronError": {"message": "Network xxx could not be found.", "type": "NetworkNotFound", "detail": ""}}
  
  [8] GET "/v2.0/networks?marker=xxx"
  {"networks":...}
  
  [9] GET "/v2.0/networks?admin_state_up=xxx"
  {"NeutronError": {"message": "Invalid input for operation: 'xxx' cannot be converted to boolean.", "type": "InvalidInput", "detail": ""}}
  
  [10] GET "/v2.0/networks?subnets=11"
  {"NotImplementedError": {"message": "in_() not yet supported for relationships.  For a simple many-to-one, use in_() against the set of foreign key values.", "type": "NotImplementedError", "detail": ""}}
  
  [11] GET "/v2.0/networks?xxx=11"
  {"networks":...}
  
  [12] GET "/v2.0/networks?fields=xxx"
  {"networks":...}

** Description changed:

  Problem
  =======
  If users provide different kinds of invalid query parameters, the behavior of neutron server looks unpredictable. Sometimes, it tolerates the invalid inputs and return a successful response. Sometimes, it invalidates the inputs and return an error response. In addition, the error type is unpredictable and the format of the error message is inconsistent.
  
  1. Invalid sort_key and/or sort_dir:
  
  Neutron returns at least two error types: BadRequest [1] [2], HTTPBadRequest [3] [4][5]. In addition, the format of error message looks inconsistent. For example, it has the following forms:
  * Bad networks request: Attribute '...' references another resource and cannot be used to sort '...' resources. [1]
  * Bad networks request: '...' is an invalid attribute for sort key. [2]
  * [u'...'] is invalid attribute for sort_keys [3]
  
  2. Invalid limit and/or marker:
  
  Sometimes, neutron returns error with one of the following types:
  BadRequest [6], NetworkNotFound [7]. Sometimes, neutron doesn't return
  error [8].
  
  3. Invalid filter
  
  Sometimes, neutron returns error with one of the following types:
  InvalidInput [9], NotImplementedError [10]. Sometimes, neutron doesn't
  return error [11]
  
  4. Invalid fields
  
  Neutron always returns a successful response [12] regardless of validity
  of the inputs.
  
  Proposal
  ========
  Improve the predictability of neutron server by handling invalid query parameters consistently. Optimally, neutron server behaves as following:
  * Always returns error (i.e. 400 response) on invalid user inputs. IMHO, ignoring invalid inputs (like [8][11][12]) is bad.
- * Make error type predictable. There are several options to achieve this. One option is to group different kinds of invalid inputs and define a specific error type for each group (i.e. InvalidSortKey, InvalidLimit, InvalidFilter, etc.). Another option is to define a generic error type (i.e. BadRequest) for all.
+ * Make error type predictable. There are several options to achieve this. One option is to group different kinds of invalid inputs and define a specific error type for each group (i.e. InvalidSorting for #1, InvalidPagination for #2, InvalidFilter for #3, etc.). Another option is to define a generic error type (i.e. BadRequest) for all.
  * Make format of error message consistent. For example, the format of error messages [1][2][3] can be consolidated into one.
  
  Referred examples
  =================
  
  [1] GET "/v2.0/networks?sort_dir=desc&sort_key=segments"
  {"NeutronError": {"message": "Bad networks request: Attribute 'segments' references another resource and cannot be used to sort 'networks' resources.", "type": "BadRequest", "detail": ""}}
  
  [2] GET "/v2.0/networks?sort_dir=desc&sort_key=provider:physical_network"
  {"NeutronError": {"message": "Bad networks request: 'provider:physical_network' is an invalid attribute for sort key.", "type": "BadRequest", "detail": ""}}
  
  [3] GET "/v2.0/networks?sort_dir=desc&sort_key=xxx"
  {"NeutronError": {"message": "[u'xxx'] is invalid attribute for sort_keys", "type": "HTTPBadRequest", "detail": ""}}
  
  [4] GET "/v2.0/networks?sort_dir=xxx"
  {"NeutronError": {"message": "The number of sort_keys and sort_dirs must be same", "type": "HTTPBadRequest", "detail": ""}}
  
  [5] GET "/v2.0/networks?sort_dir=xxx&sort_key=id"
  {"NeutronError": {"message": "[u'xxx'] is invalid value for sort_dirs, valid value is 'asc' and 'desc'", "type": "HTTPBadRequest", "detail": ""}}
  
  [6] GET "/v2.0/networks?limit=-1"
  {"NeutronError": {"message": "Bad limit request: Limit must be an integer 0 or greater and not '-1'.", "type": "BadRequest", "detail": ""}}
  
  [7] GET "/v2.0/networks?limit=1&marker=xxx"
  {"NeutronError": {"message": "Network xxx could not be found.", "type": "NetworkNotFound", "detail": ""}}
  
  [8] GET "/v2.0/networks?marker=xxx"
  {"networks":...}
  
  [9] GET "/v2.0/networks?admin_state_up=xxx"
  {"NeutronError": {"message": "Invalid input for operation: 'xxx' cannot be converted to boolean.", "type": "InvalidInput", "detail": ""}}
  
  [10] GET "/v2.0/networks?subnets=11"
  {"NotImplementedError": {"message": "in_() not yet supported for relationships.  For a simple many-to-one, use in_() against the set of foreign key values.", "type": "NotImplementedError", "detail": ""}}
  
  [11] GET "/v2.0/networks?xxx=11"
  {"networks":...}
  
  [12] GET "/v2.0/networks?fields=xxx"
  {"networks":...}

** Description changed:

  Problem
  =======
  If users provide different kinds of invalid query parameters, the behavior of neutron server looks unpredictable. Sometimes, it tolerates the invalid inputs and return a successful response. Sometimes, it invalidates the inputs and return an error response. In addition, the error type is unpredictable and the format of the error message is inconsistent.
  
  1. Invalid sort_key and/or sort_dir:
  
  Neutron returns at least two error types: BadRequest [1] [2], HTTPBadRequest [3] [4][5]. In addition, the format of error message looks inconsistent. For example, it has the following forms:
  * Bad networks request: Attribute '...' references another resource and cannot be used to sort '...' resources. [1]
  * Bad networks request: '...' is an invalid attribute for sort key. [2]
  * [u'...'] is invalid attribute for sort_keys [3]
  
  2. Invalid limit and/or marker:
  
  Sometimes, neutron returns error with one of the following types:
  BadRequest [6], NetworkNotFound [7]. Sometimes, neutron doesn't return
  error [8].
  
  3. Invalid filter
  
  Sometimes, neutron returns error with one of the following types:
  InvalidInput [9], NotImplementedError [10]. Sometimes, neutron doesn't
  return error [11]
  
  4. Invalid fields
  
  Neutron always returns a successful response [12] regardless of validity
  of the inputs.
  
  Proposal
  ========
  Improve the predictability of neutron server by handling invalid query parameters consistently. Optimally, neutron server behaves as following:
  * Always returns error (i.e. 400 response) on invalid user inputs. IMHO, ignoring invalid inputs (like [8][11][12]) is bad.
- * Make error type predictable. There are several options to achieve this. One option is to group different kinds of invalid inputs and define a specific error type for each group (i.e. InvalidSorting for #1, InvalidPagination for #2, InvalidFilter for #3, etc.). Another option is to define a generic error type (i.e. BadRequest) for all.
+ * Make error type predictable. There are several options to achieve this. One option is to group different kinds of invalid inputs and define a specific error type for each group (i.e. InvalidSorting for #1, InvalidPagination for #2, InvalidFilter for #3, etc.).
  * Make format of error message consistent. For example, the format of error messages [1][2][3] can be consolidated into one.
  
  Referred examples
  =================
  
  [1] GET "/v2.0/networks?sort_dir=desc&sort_key=segments"
  {"NeutronError": {"message": "Bad networks request: Attribute 'segments' references another resource and cannot be used to sort 'networks' resources.", "type": "BadRequest", "detail": ""}}
  
  [2] GET "/v2.0/networks?sort_dir=desc&sort_key=provider:physical_network"
  {"NeutronError": {"message": "Bad networks request: 'provider:physical_network' is an invalid attribute for sort key.", "type": "BadRequest", "detail": ""}}
  
  [3] GET "/v2.0/networks?sort_dir=desc&sort_key=xxx"
  {"NeutronError": {"message": "[u'xxx'] is invalid attribute for sort_keys", "type": "HTTPBadRequest", "detail": ""}}
  
  [4] GET "/v2.0/networks?sort_dir=xxx"
  {"NeutronError": {"message": "The number of sort_keys and sort_dirs must be same", "type": "HTTPBadRequest", "detail": ""}}
  
  [5] GET "/v2.0/networks?sort_dir=xxx&sort_key=id"
  {"NeutronError": {"message": "[u'xxx'] is invalid value for sort_dirs, valid value is 'asc' and 'desc'", "type": "HTTPBadRequest", "detail": ""}}
  
  [6] GET "/v2.0/networks?limit=-1"
  {"NeutronError": {"message": "Bad limit request: Limit must be an integer 0 or greater and not '-1'.", "type": "BadRequest", "detail": ""}}
  
  [7] GET "/v2.0/networks?limit=1&marker=xxx"
  {"NeutronError": {"message": "Network xxx could not be found.", "type": "NetworkNotFound", "detail": ""}}
  
  [8] GET "/v2.0/networks?marker=xxx"
  {"networks":...}
  
  [9] GET "/v2.0/networks?admin_state_up=xxx"
  {"NeutronError": {"message": "Invalid input for operation: 'xxx' cannot be converted to boolean.", "type": "InvalidInput", "detail": ""}}
  
  [10] GET "/v2.0/networks?subnets=11"
  {"NotImplementedError": {"message": "in_() not yet supported for relationships.  For a simple many-to-one, use in_() against the set of foreign key values.", "type": "NotImplementedError", "detail": ""}}
  
  [11] GET "/v2.0/networks?xxx=11"
  {"networks":...}
  
  [12] GET "/v2.0/networks?fields=xxx"
  {"networks":...}

** Description changed:

  Problem
  =======
  If users provide different kinds of invalid query parameters, the behavior of neutron server looks unpredictable. Sometimes, it tolerates the invalid inputs and return a successful response. Sometimes, it invalidates the inputs and return an error response. In addition, the error type is unpredictable and the format of the error message is inconsistent.
  
  1. Invalid sort_key and/or sort_dir:
  
  Neutron returns at least two error types: BadRequest [1] [2], HTTPBadRequest [3] [4][5]. In addition, the format of error message looks inconsistent. For example, it has the following forms:
  * Bad networks request: Attribute '...' references another resource and cannot be used to sort '...' resources. [1]
  * Bad networks request: '...' is an invalid attribute for sort key. [2]
  * [u'...'] is invalid attribute for sort_keys [3]
  
  2. Invalid limit and/or marker:
  
  Sometimes, neutron returns error with one of the following types:
  BadRequest [6], NetworkNotFound [7]. Sometimes, neutron doesn't return
  error [8].
  
  3. Invalid filter
  
  Sometimes, neutron returns error with one of the following types:
  InvalidInput [9], NotImplementedError [10]. Sometimes, neutron doesn't
  return error [11]
  
  4. Invalid fields
  
  Neutron always returns a successful response [12] regardless of validity
  of the inputs.
  
  Proposal
  ========
  Improve the predictability of neutron server by handling invalid query parameters consistently. Optimally, neutron server behaves as following:
  * Always returns error (i.e. 400 response) on invalid user inputs. IMHO, ignoring invalid inputs (like [8][11][12]) is bad.
  * Make error type predictable. There are several options to achieve this. One option is to group different kinds of invalid inputs and define a specific error type for each group (i.e. InvalidSorting for #1, InvalidPagination for #2, InvalidFilter for #3, etc.).
- * Make format of error message consistent. For example, the format of error messages [1][2][3] can be consolidated into one.
+ * Make the format of error message consistent. For example, the format of error messages [1][2][3] can be consolidated into one.
  
  Referred examples
  =================
  
  [1] GET "/v2.0/networks?sort_dir=desc&sort_key=segments"
  {"NeutronError": {"message": "Bad networks request: Attribute 'segments' references another resource and cannot be used to sort 'networks' resources.", "type": "BadRequest", "detail": ""}}
  
  [2] GET "/v2.0/networks?sort_dir=desc&sort_key=provider:physical_network"
  {"NeutronError": {"message": "Bad networks request: 'provider:physical_network' is an invalid attribute for sort key.", "type": "BadRequest", "detail": ""}}
  
  [3] GET "/v2.0/networks?sort_dir=desc&sort_key=xxx"
  {"NeutronError": {"message": "[u'xxx'] is invalid attribute for sort_keys", "type": "HTTPBadRequest", "detail": ""}}
  
  [4] GET "/v2.0/networks?sort_dir=xxx"
  {"NeutronError": {"message": "The number of sort_keys and sort_dirs must be same", "type": "HTTPBadRequest", "detail": ""}}
  
  [5] GET "/v2.0/networks?sort_dir=xxx&sort_key=id"
  {"NeutronError": {"message": "[u'xxx'] is invalid value for sort_dirs, valid value is 'asc' and 'desc'", "type": "HTTPBadRequest", "detail": ""}}
  
  [6] GET "/v2.0/networks?limit=-1"
  {"NeutronError": {"message": "Bad limit request: Limit must be an integer 0 or greater and not '-1'.", "type": "BadRequest", "detail": ""}}
  
  [7] GET "/v2.0/networks?limit=1&marker=xxx"
  {"NeutronError": {"message": "Network xxx could not be found.", "type": "NetworkNotFound", "detail": ""}}
  
  [8] GET "/v2.0/networks?marker=xxx"
  {"networks":...}
  
  [9] GET "/v2.0/networks?admin_state_up=xxx"
  {"NeutronError": {"message": "Invalid input for operation: 'xxx' cannot be converted to boolean.", "type": "InvalidInput", "detail": ""}}
  
  [10] GET "/v2.0/networks?subnets=11"
  {"NotImplementedError": {"message": "in_() not yet supported for relationships.  For a simple many-to-one, use in_() against the set of foreign key values.", "type": "NotImplementedError", "detail": ""}}
  
  [11] GET "/v2.0/networks?xxx=11"
  {"networks":...}
  
  [12] GET "/v2.0/networks?fields=xxx"
  {"networks":...}

** Changed in: neutron
     Assignee: (unassigned) => Hongbin Lu (hongbin.lu)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1749820

Title:
  Unpredictable response on invalid query parameters

Status in neutron:
  New

Bug description:
  Problem
  =======
  If users provide different kinds of invalid query parameters, the behavior of neutron server looks unpredictable. Sometimes, it tolerates the invalid inputs and return a successful response. Sometimes, it invalidates the inputs and return an error response. In addition, the error type is unpredictable and the format of the error message is inconsistent.

  1. Invalid sort_key and/or sort_dir:

  Neutron returns at least two error types: BadRequest [1] [2], HTTPBadRequest [3] [4][5]. In addition, the format of error message looks inconsistent. For example, it has the following forms:
  * Bad networks request: Attribute '...' references another resource and cannot be used to sort '...' resources. [1]
  * Bad networks request: '...' is an invalid attribute for sort key. [2]
  * [u'...'] is invalid attribute for sort_keys [3]

  2. Invalid limit and/or marker:

  Sometimes, neutron returns error with one of the following types:
  BadRequest [6], NetworkNotFound [7]. Sometimes, neutron doesn't return
  error [8].

  3. Invalid filter

  Sometimes, neutron returns error with one of the following types:
  InvalidInput [9], NotImplementedError [10]. Sometimes, neutron doesn't
  return error [11]

  4. Invalid fields

  Neutron always returns a successful response [12] regardless of
  validity of the inputs.

  Proposal
  ========
  Improve the predictability of neutron server by handling invalid query parameters consistently. Optimally, neutron server behaves as following:
  * Always returns error (i.e. 400 response) on invalid user inputs. IMHO, ignoring invalid inputs (like [8][11][12]) is bad.
  * Make error type predictable. There are several options to achieve this. One option is to group different kinds of invalid inputs and define a specific error type for each group (i.e. InvalidSorting for #1, InvalidPagination for #2, InvalidFilter for #3, etc.).
  * Make the format of error message consistent. For example, the format of error messages [1][2][3] can be consolidated into one.

  Referred examples
  =================

  [1] GET "/v2.0/networks?sort_dir=desc&sort_key=segments"
  {"NeutronError": {"message": "Bad networks request: Attribute 'segments' references another resource and cannot be used to sort 'networks' resources.", "type": "BadRequest", "detail": ""}}

  [2] GET "/v2.0/networks?sort_dir=desc&sort_key=provider:physical_network"
  {"NeutronError": {"message": "Bad networks request: 'provider:physical_network' is an invalid attribute for sort key.", "type": "BadRequest", "detail": ""}}

  [3] GET "/v2.0/networks?sort_dir=desc&sort_key=xxx"
  {"NeutronError": {"message": "[u'xxx'] is invalid attribute for sort_keys", "type": "HTTPBadRequest", "detail": ""}}

  [4] GET "/v2.0/networks?sort_dir=xxx"
  {"NeutronError": {"message": "The number of sort_keys and sort_dirs must be same", "type": "HTTPBadRequest", "detail": ""}}

  [5] GET "/v2.0/networks?sort_dir=xxx&sort_key=id"
  {"NeutronError": {"message": "[u'xxx'] is invalid value for sort_dirs, valid value is 'asc' and 'desc'", "type": "HTTPBadRequest", "detail": ""}}

  [6] GET "/v2.0/networks?limit=-1"
  {"NeutronError": {"message": "Bad limit request: Limit must be an integer 0 or greater and not '-1'.", "type": "BadRequest", "detail": ""}}

  [7] GET "/v2.0/networks?limit=1&marker=xxx"
  {"NeutronError": {"message": "Network xxx could not be found.", "type": "NetworkNotFound", "detail": ""}}

  [8] GET "/v2.0/networks?marker=xxx"
  {"networks":...}

  [9] GET "/v2.0/networks?admin_state_up=xxx"
  {"NeutronError": {"message": "Invalid input for operation: 'xxx' cannot be converted to boolean.", "type": "InvalidInput", "detail": ""}}

  [10] GET "/v2.0/networks?subnets=11"
  {"NotImplementedError": {"message": "in_() not yet supported for relationships.  For a simple many-to-one, use in_() against the set of foreign key values.", "type": "NotImplementedError", "detail": ""}}

  [11] GET "/v2.0/networks?xxx=11"
  {"networks":...}

  [12] GET "/v2.0/networks?fields=xxx"
  {"networks":...}

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1749820/+subscriptions