I am unsure if my title was accurate enough. I am trying to make SEO URLs for my website which is developed in ASP.NET MVC. I configured my route to include:
routes.MapRoute(
"Default", // Route name
"{controller}/{action}/{id}/{seo}", // URL with parameters, SEO will up completely optional and used for strings to provide Search Engine Optimization.
new { controller = "Home", action = "Index", id = "", seo ="" } // Parameter defaults
);
On my development machine, a link like:
http://localhost:1048/Home/Post/96/Firefighting+ATV+Concept+Twin+Water+Cannons+Gull
works fine, but once I published to the server (Windows 2008 R2 IIS), it doesn't work. For example, the link:
http://www.otakuwire.net/Home/Post/96/Firefighting+ATV+Concept+Twin+Water+Cannons+Gull
gives me a 404.
Is this a routing issue, or some other issue?
This is an IIS issue, not routing. IIS7 is strict in how it deals with the plus symbol + in URLs. The easy fix is to use the dash - instead like everyone else, or be bold and use the space character (which, personal note, looks horrible in the IE address bar).
On ServerFault they present a configuration-based solution to allow + symbols:
https://serverfault.com/questions/76013/iis6-vs-iis7-and-iis7-5-handling-urls-with-plus-sign-in-base-not-querystri
Related
I have a Sitecore site and on 2 of my CD servers, Url.Action returns an empty string. This works locally and on 9 other servers ranging from dev to prod, CD and CM.
Deployment automation ensures that the exact same web.config is deployed to all environments; ditto for all other configs.
My controller inherits from SitecoreController properly. This is not isolated to a certain controller or action, this happens with all controllers and actions.
What would make Url.Action return an empty string in one environment and not others, with identical code?
What would make Url.Action return an empty string sometimes?
Specifically, route values that are derived from the current request.
Explanation
The Url.Action method is driven by the UrlHelper, which in turn is driven by routes. It uses route values to determine which route to use to build the URL. The routing framework attempts to match each route against the route values in the order they are registered until a match is found. If the routing framework reaches the end of the routing table and there is still no match, it returns an empty string (because there is no other reasonable default behavior).
On the other hand, if you call Url.Action and pass a route name, this narrows the possible matches to only 1 specific route (the named one). But the route values still need to match that route or you get the default empty string.
In general, all route values must match, but there are a couple of things that may make the behavior quirky:
Route values can be made optional. This means that the route value doesn't need to be present in order for the route to match.
If a route value is not supplied in the call to Url.Action, it may be supplied automatically if it exists in the current request.
This second quirk means that if Url.Action is put on a shared view and one request contains a route value to make it match a route, and another request doesn't contain that route value, in the latter case the URL may match another route or it may be an empty string.
Example
Say the routing configuration is setup like this:
public class RouteConfig
{
public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
routes.MapRoute(
name: "AboutWith4RouteValues",
url: "test/home/about/{foo}/{bar}",
defaults: new { controller = "Home", action = "About" });
routes.MapRoute(
name: "ContactWith4RouteValues",
url: "test/home/contact/{foo}/{bar}",
defaults: new { controller = "Home", action = "Contact", bar = UrlParameter.Optional });
routes.MapRoute(
name: "Home",
url: "",
defaults: new { controller = "Home", action = "Index" }
);
}
}
Also, let's say there is a link on the _Layout.cshtml page:
<a href='#Url.Action("About", "Home")'>About</a>
If you go to the home page in the browser (/), the resulting link URL will be:
<a>About</a>
This is because foo and bar are not present in the route values of the request so it doesn't match any of the registered routes.
Actually, Url.Action returns an empty string, but Razor optimizes away the empty href='' attribute.
On the other hand, if you put this URL in the browser:
/test/home/contact/arg1/arg2
The link URL is generated as:
<a href='/test/home/about/arg1/arg2'>About</a>
This is because both {foo} (with value arg1) and {bar} (with value arg2) are available in the current request. Note that the incoming request matches the ContactWith4RouteValues route, but when the link URL is generated it uses the AboutWith4RouteValues route. Since both foo and bar are present in the request, they are carried over to the generation of the URL.
Now, if the URL in the browser is changed to:
/test/home/contact/arg1
It still matches the ContactWith4RouteValues route because the last value is optional. However, the URL that is generated is now:
<a>About</a>
This is because foo has a value in the request, but bar has no value, the Url.Action generation request does not match AboutWith4RouteValues because bar is a required value in order to make it match. And since it also doesn't match the Home route, we have reached the end of the route table and the only logical thing to return is empty string.
Workaround
The simplest workaround to avoid these quirks of the current request is to manually specify the route values when calling Url.Action or other UrlHelper based methods (such as ActionLink, RedirectToRoute, etc).
<a href='#Url.Action("About", "Home", new { foo = Model.Foo, bar = Model.Bar })'>About</a>
This ensures those values are always present when building the URL even if they don't happen to be part of the current request.
I had this exact same issue and for me the issue had to do with Case-Sensitivity in my Routing.
Deploying the same site to two different Applications on the same IIS Web Server.
I used the same web-config and same VS Web Publish Settings.
Yet, my Url.Action was returning blanks (empty-strings) in Prod, but not in Dev.
After reviewing the code, something caught my eye.
I have an Area called WorkBench (upper-case "B").
In a few places (where Url.Action returned blank), I was passing in Workbench (lower-case "b").
I have some fancy logic in my RouteConfig.cs and Area Registration (i.e. WorkBenchAreaRegistration.cs).
In those files, I had Conditional Logic to determine what Environment the Application was running in.
I use the same Project to share code, but only want some Areas accessible in different Environments.
Even though Prod and Dev are different Environments, to debug this issue,
I altered them so they would temporarily appear the same.
The issue was fixed once I capitalized the "b" to "B" everywhere.
I still do not know why it would work on my local machine and in Dev, but not in Prod.
It should have behaved the same way in both Environments.
Again, same server, same publish, same web.config, same iis config, same application code, etc...
Sorry I don't have an explanation for this, but at least this is a possible fix you could try.
Hope this helps someone out there.
Update 02/08/2019: I had this problem again with a different link and for this one I realized I had an option set to access all Actions within an Area when one of my Debug variables was set to true, or when running in Prod. I removed this conditional logic in my AreaRegistration.cs file and it fixed the problem when running in a Staging envrionment.
The Lesson Learned here is that anytime you see a blank Href, you gotta check those Route Configs.
I have the following problem with an Asp.net MVC application when running on IIS (tested with version 7.0 and 8.5) : if the path in the URL has no more than 3 components (for example http://myhost.com/a/b/c, it gets correctly handled by the application code. But when an additional component is added in the path (http://myhost.com/a/b/c/d), it will be sent directly to the static file handler. As the path is not used for a physical file, I get a 404 (with the error page coming from the static file handler, not the custon 404 page configured in web.config)
I don't have this problem on my dev station running IIS Express.
I use runAllManagedModulesForAllRequests="true" in web.config, disabling it doesn't solve the issue.
Disabling the static file handler doesn't help, I still get a 404 but this time the error message says "Handler Not yet determined".
I really looks this is something happening very early in IIS processing, because if I recycle the application pool and try to access to this URL, the response comes immediately, without the usual delay that I get when the application needs to start.
What am I missing? Why is IIS not forwarding such requests to my application?
It's your routes!!
The default route in MVC only takes over controller, action & ID. You're trying to use a fourth which you haven't defined. Just add another url parameter to your route collection.
routes.MapRoute(
name: "Default",
url: "{controller}/{action}/{id}/{another}",
defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional, another= UrlParameter.Optional }
);
Hope this helps.
I think I found something: the long url was not handled by an MVC route, but by an OWIN middleware. Somehow, it seems that for IIS, if no route is configured for an URL, then the request pipeline is completely ignored, including any OWIN middlewares (and also custom page for 404).
By adding another parameter in a route like suggested by heymega, I was able to work around the problem, the OWIN middlewares were executed. I added the following route:
routes.MapRoute("CatchLongUrls", "{a}/{b}/{c}/{*d}",
new {controller = "Invalid", action = "Nothing"});
My MVC web application generates an activation link that can include any character (%,+,/,etc.). I URL encode the string and generate link:
new UrlHelper(HttpContext.Current.Request.RequestContext)
.RouteUrl("AccountActivation",
new { id = HttpContext.Current.Server.UrlEncode(activationString) };
then add the domain and it looks like:
http://localhost/AccountActivation/asdlkj223%25asd%2Basw3fgasdme
The URL is then passed to the user.
The route in this case is:
routes.MapRoute(
"ActivateAccount",
"AccountActivation/{id}",
new { controller = "Account", action = "Activate", id = ""});
It seem fine to me, but the ASP.NET development server and IIS give me HTTP Error 400 - Bad request. Which means there's a problem with the URL that I can't see.
When get rid of the {id} in the route description (I also tried {*id} with no success):
routes.MapRoute(
"ActivateAccount",
"AccountActivation",
new { controller = "Account", action = "Activate"});
the URLs look like:
http://AccountActivation?id=asdlkj223%25asd%2Basw3fgasdme
and they work just fine...
I though those 2 approaches do exactly the same thing. What is the difference between them? Is it the MVC engine that performs something more for me or I miss something with the URL encoding.
Try UrlPathEncode instead of UrlEncode - some characters are illegal in the path that are legal in a query string.
That said - I believe the analysis of whether a character is 'bad' is performed after path-decoding occurs; and is done by IIS. It will reject some characters because of the possibility that the URL maps to the physical file-system and therefore could allow a user access to things they really shouldn't have access to. Equally it's done to prevent requests from sending data that really shouldn't be sent.
Generally if there's operationally no benefit from having a parameter mapped as a route parameter, then don't try too hard to map it - especially in this case where the string could be anything.
By the way - if that's an encoding of binary data; you can instead consider hex-encoding it or using modified base-64 for URLs instead - which will not cause errors if mapped as a route parameter.
Consider the following route:
routes.MapRoute(
"Service", // Route name
"service/", // URL with parameters
new {controller = "CustomerService", action = "Index"} // Parameter defaults
);
Using Url.Action("Service", "CustomerService") produces an url of /service instead of the expected /service/
Is there any way to get this to work, or do I have to resort to implementing my own routing deriving from RouteBase?
Legenden - there is no immediate solution to the problem. You may have run across Jason Young's blog post about the issue, which is very informative. Scott Hanselmann posted a reply to it here, basically stating that he didn't think it was a big deal, and if it is, you can leverage the new IIS7 rewrite module to solve it.
Ultimately though, you might want to look at a solution that was posted by murad on a similar question on StackOverflow: Trailing slash on an ASP.NET MVC route
In your page load event add:
Dim rawUrl As String = HttpContext.Current.ApplicationInstance.Request.RawUrl
If Not rawUrl.EndsWith("/") Then
HttpContext.Current.ApplicationInstance.Response.RedirectPermanent(String.Format("~{0}/", rawUrl))
End If
I'm trying to plan for future (months away) localization of a new ASP.NET MVC site.
Trying to decide what makes most sense to do, as far as constructing the URLs and routing.
For instance should I start off immediately with this :
http://www.example.com/en/Products/1001
http://www.example.com/es/Products/1001
or just
http://www.example.com/Products/1001
and then add other languages later
http://www.example.com/en/Products/1001
Thats my basic main issue right now, trying to get the routing correct. I want my URLs to be indexable by a search engine correctly. I'm not even sure if I want language in the URL but I dont think there is a good alternative that wouldn't confuse a search engine.
It leads to all kinds of other questions like 'shouldnt I localize the word products' but for right now I just want to get the routing in place before I launch the english site.
I have exactly the same URL_mapping like you. My route also uses a constraint.
Works for me.
routes.MapRoute(
// Route name
"LocalizedController",
// URL with parameters
"{language}/{controller}/{action}",
// Parameter defaults
new {
controller = "Home", action = "Index",
language = "de"
},
//Parameter constraints
new { language = #"de|en" }
I would use a different URL scheme like so :
en.mysite.com (English)
mysite.com (default language)
ro.mysite.com (Romanian)
etc.
Then I would create a custom route like in this answer.