How will validation be implemented in the future?

What happens with the Router arguments fail validation? -- doesn't seem to do anything at the moment

What sort of validation are you talking about? Got an example?

 I'm trying to validate inputs into the Controller on form variables with the routing rule:

            RouteTable.Routes.Add(new Route
            {
                Url = "Clients/Search/[query]",
                Defaults = new { controller = "Clients", action = "Search" },
                Validation = new {query=@"\d{2}"},
                RouteHandler = typeof(MvcRouteHandler)
            });

 So the query param can only be a 2 digit number.

When I visit localhost:8080/Clients/Search/QUERY where QUERY is not a 2 digit number, the query parameter is nullified and passed into the controller. If QUERY is a 2 digit number, it's passed into the controller as is.

Seems like this validation should be doing more than just nullifying the input.

I'd prefer it if it actually did something, like pass a validation error into the controllerContext for the action to use. Controller level validation would be good first defense.

I find Regex a really good way of validating url parameters and i really like the fact MVC will  validate form variables too. It'd be cool if there was a virtual controller method for receiving validation problems. I can imagine creating Action attributes for specifying general bad input behavior.

Others have implemented validation in model objects ( http://www.dotnetkicks.com/aspnet/How_To_Validation_Using_ASP_NET_MVC) and let the action decide what to do, but I think the Regex's are there for a good reason, and allow for declarable error behavior.

You probably have a rule that is catching the route somewhere else.  The following test shows that no RouteData is found given your scenario.

[Test]
public virtual void GetRouteData_WithStringForQuery_ReturnsNullRouteData()
{
	MockRepository mocks = new MockRepository();
	RouteCollection routes = new RouteCollection();
	IHttpContext httpContext = mocks.DynamicMock();
	IHttpRequest httpRequest = mocks.DynamicMock();
	routes.Add(new Route
		{
			Url = "Clients/Search/[query]",
			Defaults = new { controller = "Clients", action = "Search" },
			Validation = new { query = @"\d{2}" } ,
			RouteHandler = typeof(MvcRouteHandler)
		});
	using(mocks.Record())
	{
		SetupResult.For(httpContext.Request).Return(httpRequest);
		SetupResult.For(httpRequest.AppRelativeCurrentExecutionFilePath).Return("~/Clients/Search/Goose");
	}
	using(mocks.Record())
	{
		Assert.That(routes.GetRouteData(httpContext), Is.Null);
	}
}

Oh, I see. because it fails the validation rules it gets passed onto the next route rule.

It will finally land on the default /[controller]/[action]/[id] rule which will pass query as null (cos it's not in query string).

That makes sense.

I misinterpreted what the validation rules were for.
 

 Absolutely.   You need to be careful with using rules without validation because more generic rules can unintentionally capture a route that you do not intend to.  Anytime you have a [parameter] without validation the RouteCollection will match anything.  Its almost like a ".*" regex.  Order that rules are added is important.  The first one in is the highest priority.  As I have been playing I try and be as explicit as possible so I do not have overlapping rules and my last rule is usually some type of catch all that I can use to send intelligent 404's and possible 302's.