Notice: A non well formed numeric value encountered in C:\ClientSites\bestaspnethostingreview.com\httpdocs\wp-content\plugins\crayon-syntax-highlighter\crayon_formatter.class.php on line 118
Notice: A non well formed numeric value encountered in C:\ClientSites\bestaspnethostingreview.com\httpdocs\wp-content\plugins\crayon-syntax-highlighter\crayon_formatter.class.php on line 119
Notice: A non well formed numeric value encountered in C:\ClientSites\bestaspnethostingreview.com\httpdocs\wp-content\plugins\crayon-syntax-highlighter\crayon_formatter.class.php on line 118
Notice: A non well formed numeric value encountered in C:\ClientSites\bestaspnethostingreview.com\httpdocs\wp-content\plugins\crayon-syntax-highlighter\crayon_formatter.class.php on line 119
BestASPNETHostingReview.com | Best and cheap Sitefinity hosting. In this post we will learn about how to rewriting URLs to lowercase in sitefinity.
Enforcing Lowercase on URLs to Normalize URLs
In any web application, it is generally a good idea to make sure that all of your content has only one way to reach them via a user’s address bar in their browser. Whether you accomplish this by using canonical URLs, strict discipline/convention (i.e. “I will never capitalize any directory or filename”, very hard!), or rewriting URLs into lowercase ones, they all accomplish the same goal. Google only sees one URL for content, and your SEO doesn’t take a hit for “duplicate content” like what may happen if you can go to www.example.com/Foo as well as www.example.com/foo.
In IIS the incredibly useful and versatile URL Rewrite module lets you setup a myriad of rules for rewriting or redirecting for your site. In this instance we’re taking a look at the specific scenario of rewriting URLs so that if any come in with any form of capitalization, we instead issue a 301 redirect and take the user to the lowercase’d version of the same path they took. Google will only “see” a single destination (since it treats 301s as a permanent pass-through instead of a duplicate road to the same place), and all URLs will look nice and uniform in the browser/etc. to boot.
Rewriting URLs for Custom Web Applications
If you were building a completely customized ASP.NET Web Application, your rewrite rule might look something like this:
1 2 3 4 | rule name="Normalize URLs to Lowercase" enabled="true" stopProcessing="true"> <match url="[A-Z]" ignoreCase="false" /> <action type="Redirect" url="{ToLower:{URL}}" redirectType="Permanent" /> </rule> |
You may have some custom conditions if you have any references that require capitalization, but most likely this would suffice. The rule in a nutshell says “if an incoming URL has any capital letters in it, redirect the user to the all-lowercased version of the URL as a permanent redirect.” Pretty simple to write and to include in any application you write! It only takes seconds to include in your web.config.
Sitefinity: More than your Typical ASP.NET Web Site
But what about Sitefinity? If you included the same rule above in your Sitefinity application, would you be all set? Nope! As it turns out, there are many case sensitive URLs that Sitefinity uses internally throughout its implementation of an ASP.NET web application that cannot be redirected. If rewriting URLs is used in this case, then you’ll find components of your Sitefinity site breaking or mysteriously not working, due to a redirect killing off legitimate requests.
As such, we have to build in conditions into our rewrite rule so that Sitefinity doesn’t break down.
Complete Example of Rewriting URLs to Lowercase in Sitefinity
We’ll start off with the complete rule and all of the exceptions (“conditions”) required. I compiled these conditions through the course of developing a web site and making sure every aspect continued to work. There could be more added in the future, but this is a fairly complete list as it is for rewriting URLs to lowercase in Sitefinity.
1 2 3 4 5 6 7 8 9 10 11 12 13 | <rule name="Normalize URLs to Lowercase" enabled="true" stopProcessing="true"> <match url="[A-Z]" ignoreCase="false" /> <conditions> <add input="{REQUEST_URI}" pattern="^/.*Res/" negate="true" /> <add input="{REQUEST_URI}" pattern="^/docs/" negate="true" /> <add input="{REQUEST_URI}" pattern="^/Frontend-Assembly/" negate="true" /> <add input="{REQUEST_URI}" pattern="^/Images/" negate="true" /> <add input="{REQUEST_URI}" pattern="^/Sitefinity/" negate="true" /> <add input="{PATH_INFO}" pattern=".axd$" negate="true" /> <add input="{REQUEST_METHOD}" pattern="GET" ignoreCase="true" /> </conditions> <action type="Redirect" url="{ToLower:{URL}}" redirectType="Permanent" /> </rule> |
The general syntax for all these conditions is to match the pattern, then negate it. This way we instruct the rule “only rewrite URLs if this condition is false” (save for the last one which we are not matching on negation). If any of these conditions end up failing, the rule does not get applied.
Let’s break down the conditions and see why we have each of them.
Res and axd Requests
These refer to static resources and “.axd” requests to the server. Sitefinity uses both of these pretty liberally in order to render content and display things, and if they get lowercased via rewriting URLs they simply 404.
/docs, /Frontend-Assembly, and /Images Requests
These directories are used internally by Sitefinity and are not available for use by a developer. That is to say, if you put a /Images directory at the root of your Sitefinity web application you’re going to run into strange accessing errors, since Sitefinity’s internal routing uses it for something else. The same holds true for the others as well. Like with the first set of conditions, if any of these are lowercased, they break.
^/Sitefinity/ Requests
This basically tells the URL rewriting rule to ignore everything going on in the Sitefinity backend (while doubling as another guard against internal references Sitefinity makes). Google will never be in your Sitefinity backend since authentication (username/password) is required for entry. As this fixes a lot of potential failure cases, we just ignore everything going on back there.
GET Requests Only
Generally users only interact with your site via their browser by issuing GET requests (i.e. typing the URL into their browser and going there). Sitefinity POSTs/PUTs/DELETEs, as well as any custom MVC widget implementations reaching out to actions that start with a capital letter, are case sensitive and will break if they are modified. Sitefinity uses this a lot in the backend (and the URLs they use do not start with /Sitefinity, so the previous rule wouldn’t catch them) and any frontend POSTing you’re doing will also break here. As such, we instruct our rule to only look at HTTP GET requests, and ignore any and all others. (Here the “ignoreCase” parameter is saying to match any variety of “GET”, in case it comes back as “get” for example).
You’re all set!
As you can see, rewriting URLs to enforce lowercase rules is completely doable in Sitefinity. Since it is not an application you built yourself from scratch, however, there are obviously certain exceptions you have to make in order to preserve the functionality of the web site. Instead of using the rule I posted at the top of this post, simply use the second, and you will be good to go.