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
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
