You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we use case-insensitive string comparisons around DisableQueryAttribute, which works with the default camel case convention, but breaks when switching to kebab casing.
We should have a test that uses a custom query string parameter that consists of multiple words.
The text was updated successfully, but these errors were encountered:
After discussion, @maurei and I decided to not apply casing conventions on custom parameter names. Because the API developer is in full control here: he/she chooses the casing convention and is then responsible to apply the same casing for custom parameters.
However, keeping this open to remove the case-insensitive comparisons for built-in parameters such as sort/filter/page etc.
Currently we use case-insensitive string comparisons around DisableQueryAttribute, which works with the default camel case convention, but breaks when switching to kebab casing.
We should have a test that uses a custom query string parameter that consists of multiple words.
The text was updated successfully, but these errors were encountered: