asp.net-routing

Using the new Api Controller in MVC4, and I've found a problem. If I have the following methods: public IEnumberable<string> GetAll() public IEnumberable<string> GetSpecific(int i) This will work. However, if I want to retrieve some different data of a different type, it defaults to the GetAll method, even though the $.getJSON is set to the GetAllIntegers method: public IEnumberable<int> GetAllIntergers() (bad naming conventions) Is it possible for me to be able to do this? Can I only have a single GetAll method in the Web API controller? I think it's easier to visualise what I'm trying to

I'm creating a multi-tenancy web site which hosts pages for clients. The first segment of the URL will be a string which identifies the client, defined in Global.asax using the following URL routing scheme: "{client}/{controller}/{action}/{id}" This works fine, with URLs such as /foo/Home/Index. However, when using the [Authorize] attribute, I want to redirect to a login page which also uses the same mapping scheme. So if the client is foo, the login page would be /foo/Account/Login instead of the fixed /Account/Login redirect defined in web.config. MVC uses an HttpUnauthorizedResult to return

I have some REST services using plain old IHttpHandler s. I'd like to generate cleaner URLs, so that I don't have the .ashx in the path. Is there a way to use ASP.NET routing to create routes that map to ashx handlers? I've seen these types of routes previously: // Route to an aspx page RouteTable.Routes.MapPageRoute("route-name", "some/path/{arg}", "~/Pages/SomePage.aspx"); // Route for a WCF service RouteTable.Routes.Add(new ServiceRoute("Services/SomeService", new WebServiceHostFactory(), typeof(SomeService))); Trying to use RouteTable.Routes.MapPageRoute() generates an error (that the

The Scenario I have an application where we took the good old query string URL structure: ?x=1&y=2&z=3&a=4&b=5&c=6 and changed it into a path structure: /x/1/y/2/z/3/a/4/b/5/c/6 We're using ASP.NET MVC and (naturally) ASP.NET routing. The Problem The problem is that our parameters are dynamic, and there is (theoretically) no limit to the amount of parameters that we need to accommodate for. This is all fine until we got hit by the following train: HTTP Error 400.0 - Bad Request ASP.NET detected invalid characters in the URL. IIS would throw this error when our URL got past a certain length.