When an action contained an attribute derived from HttpMethodAttribute,
doesn't specify an attribute route and there is also another attribute
extending HttpMethodAttribute that has a route defined on it; we ignored
the HttpMethodAttribute attribute without a defined route when building
the set of action selectors for the method.
This caused the resulting action to be unbounded and to accept requests
for other verbs not associated with it. The root cause of the problem was
that attributes override equality and do a field by field comparison but
ignore fields in the base classes of the type, so if an attribute is part
of a class hierarchy (like Http*Attributes) there might be two different
attributes that get considered equal.
The fix for the problem has been to change using Contains on a couple of
collections (that uses the equals method on the underlying object) and
check for the existence of the attribute on the collection directly by
using reference equality.
I recently consolidated some code in routing that made the behavior for
attribute routes and conventional routes more consistent. So now, a
catch-all will add a null value to the RVD if it doesn't capture any text,
but will NOT trounce an existing value in the RVD.
This test depended on the behavior where attribute routes didn't ever add
a null value for a catch-all. The fix is to just add a default to the
catch-all.
- #EngineeringDay
- license present but incorrect in just a few files
- skip generated files such as Resources.Designer.cs and files under
test\Microsoft.AspNet.Mvc.Razor.Host.Test\TestFiles\Output
- #EngineeringDay
- VS does not yet format auto-properties nicely; reverted what it did
Also revert changes under
- test/Microsoft.AspNet.Mvc.Razor.Host.Test/TestFiles
This change enables some compatibility scenarios with MVC 5 by expanding
the set of legal ways to configure attribute routing. Most promiently, the
following example is now legal:
[HttpPost]
[Route("Products")]
public void MyAction() { }
This will define a single action that accepts POST on route "Products".
See the comments in #1194 for a more detailed description of what changed
with more examples.
1. Support multiple [Http*] attributes on an action.
2. Support multiple [Route] attributes on a controller and on an action.
3. Support creating multiple attribute routes using [AcceptVerbs("...", Route = "...")]
4. Detect attribute routed actions during action discovery and return one action per [Http*],
[Route] or [AcceptVerbs] attribute found on the method when there is at least one valid attribute route.
5. Merge all the HTTP methods of [Http*] and [AcceptVerbs] attributes in a method during
action discovery when there are no valid attribute routes defined on the action.
6. Build one action descriptor per controller [Route] + action [Http*], [AcceptVerbs]
or [Route] combination in an action.
7. Disallow the use of attributes that do not implement IActionHttpMethodProvider and
IRouteTemplateProvider simultaneously in methods that define attribute routed
actions and throw an exception during startup.
8. Disallow mixing attribute routed and non attribute routed actions on the same method
and throw an exception during startup.
1. Changed attribute usage on RouteAttribute.
2. Added a test on action discovery to ensure that actions with [Route] get discovered as
attribute routed actions.
3. Added a test on reflected action descriptor provider to ensure that an action with [Route] on
the controller and [Route] on the action results in an action that allows any Http method.
1. Added support for Name in attribute routing. Name can be defined using [RouteAttribute]
and the different Http*Attributes, for example [HttpGet].
2. Names defined on actions always override names defined on the controller.
3. Actions with a non empty template don't inherit the name from the controller. The name
is only inherited from the controller when the action template is null or empty.
4. Multiple attribute routes with different templates and the same name are not allowed.
1. Added an Order property to IRouteTemplateProvider, ReflectedAttributeRouteModel,
AttributeRouteInfo, AttributeRouteLinkGenerationEntry and AttributeRouteMatchingEntry.
2. Changed the implementation of AttributeRoute to take the order into account when routing
incomming requests and generating links.
3. Ensured a stable ordering of route entries with the same order and precedence for route
matching and link generation based on the template text.
4. Added tests to validate that the precedence gets respected in route matching and link generation.
5. Added tests to validate that the order gets respected in route matching and link generation.
6. Added tests to validate that the order gets respected over the precedence for route matching
and link generation.
7. Added tests to validate that routes with the same order and precedence expose a stable ordering
for route matching and link generation.
1. Unsealed the Http*Attributes so that they can be extended and customized.
2. Added the same constructors as HttpGet to the rest of the Http*Attributes.
3. Added unit tests to validate the implementations for the IActionHttpMethodProvider.
4. Added functional tests to cover extra attribute routing scenarios like a test for an
action with an HttpDeleteAttribute on it and action with AcceptVerbsAttribute and an
action with a custom HttpMergeAttribute implemented.
This change allows a user to override a route prefix set using
[Route("...")] on the controller by providing a route template
on the action that starts with "~/" or "/". For example,
[HttpGet("~/...")] or [HttpGet("/...")]
If the user specifies a template in [Route] that starts with "~/"
or "/", we will just strip the prefix from the template and use
the remaining part of the template.
The reason to do this is that there's a reasonable extensibility
scenario where a user can implement a global prefix for routes as
a convention (using IReflectedApplicationModelConvention), and use
~/ to escape that prefix (just like we support with action-level routes).