Currently the HttpActionContext.ActionArguments uses the default dictionary initializer, which means that the keys are looked up using a case-sensitive comparer.
This conflicts with the stated design of Web APIs parameter binding which is supposed to be case-insensitive. In fact, WebAPI's route parameters are case-insensitive.
Having ActionArguments be case-sensitive means that it's more difficult than necessary to write code that can correctly retrieve values. For example, say I have an "id" action argument. The routing behavior means that I can have any casing for the parameter and things will still work regardless of the casing in the route configuration. I can have public TResult Get(int ID) or public TResult Get(int id), and they'll get routed either way.
But if I want to write a filter that inspects those action arguments, I cannot just write actionContext.ActionArguments["Id"] since the lookup is case sensitive.
While this would technically be a breaking change, I think it's one worth taking since it brings the behavior more inline with the rest of routing as well as the general case-aware (but case-insensitive) behavior when it comes to method parameters.
This conflicts with the stated design of Web APIs parameter binding which is supposed to be case-insensitive. In fact, WebAPI's route parameters are case-insensitive.
Having ActionArguments be case-sensitive means that it's more difficult than necessary to write code that can correctly retrieve values. For example, say I have an "id" action argument. The routing behavior means that I can have any casing for the parameter and things will still work regardless of the casing in the route configuration. I can have public TResult Get(int ID) or public TResult Get(int id), and they'll get routed either way.
But if I want to write a filter that inspects those action arguments, I cannot just write actionContext.ActionArguments["Id"] since the lookup is case sensitive.
While this would technically be a breaking change, I think it's one worth taking since it brings the behavior more inline with the rest of routing as well as the general case-aware (but case-insensitive) behavior when it comes to method parameters.