Add or Remove a Trailing Slash: Many developers use virtual url, which do not directly map to the file and directory layout on web server’s file system.
Example: An ASP.NET application with URL format similar to this: http://abc.com/questions/60857/modrewrite-7-0 or a PHP application with URL format that looks like this: http://xyz.net/questions/60857/url-rewrite/. If you try to request these URLs with or without trailing slash you will get a normal web page page. That is OK for human visitors, but may be a problem for search engine crawlers as well as for web analytics services.
Different URLs for the same page may cause crawlers to treat the same page as different pages, thus affecting the page ranking. Having or not having a trailing slash in the URL is a matter of taste, but once you’ve made a choice you can enforce the canonical URL format by using one of these rewrite rules:
Enforce Lower Case URLs: If you links to a web page by using different casing, e.g. http://xyz.net/2008/07/IISNET-Uses-Url-Rewrite-Module/ vs. http://xyz.net/2008/07/iisnet-uses-url-rewrite-module/. In this case again the search crawlers will treat the same page as two different pages and two different statistics sets will show up in Web Analytics reports.
What you want to do is to ensure that if somebody comes to your web site by using a non-canonical link, then you redirect them to the canonical URL that uses only lowercase characters:
Canonical Hostnames: Very often you may have one IIS web site that uses several different host names. The most common example is when a site can be accessed via http://www.yoursitename.com and via http://yoursitename.com. Or, perhaps, you have recently changed you domain name from oldsitename.com to newsitename.com and you want your visitors to use new domain name when bookmarking links to your site. A very simple redirect rule will take care of that:
Redirect to HTTPS: If you want your site to be easily discoverable and more user friendly, you probably would not want to return 403 response to visitors who came over unsecure HTTP connection. Instead you would want to redirect them to the secure equivalent of the URL they have requested.
Example: http://www.paypal.com. If you follow it you will see that browser gets redirected to https://www.paypal.com.
With URL Rewrite Module you can perform this kind of redirection by using the following rule:
Return HTTP 503 Status Code in Response: HTTP status code 503 means that the server is currently unable to handle the request due to maintenance. This status code implies that the outage is temporary, so when search engine crawler gets HTTP 503 response from your site, it will know not to index this response, but instead to come back later.
When you stop the IIS application pool for your web site, IIS will return HTTP 503 for all requests to that site. But what if you are doing maintenance to a certain location of the web site and you do not want to shut down the entire site because of that? With URL Rewrite Module you can return 503 response only when HTTP requests are made to a specific URL path:
Prevent Image Hotlinking: Image Hotlinking is the use of an image from one site into a web page belonging to a second site. Unauthorized image hotlinking from your site increases bandwidth use, even though the site is not being viewed as intended. There are other concerns with image hotlinking, for example copyrights or usage of images in an inappropriate context.
With URL Rewrite Module, it is very easy to prevent image hotlinking. For example the following rewrite rule prevents hotlinking to all images on a web site:
Reverse Proxy To Another Site/Server: By using URL Rewrite Module together with Application Request Routing module you can have IIS 7 act as a reverse proxy. For example, you have an intranet web server and you want to expose its content over internet. To enable that you will need to perform the following configuration steps on the server that will act as a proxy:
Step1: Check the “Enable proxy” checkbox located in Application Request Routing feature view is IIS Manager.
Step2: Add the following rule to the web site that will be used to proxy HTTP requests:
Preserve Protocol Prefix in Reverse Proxy: The rule in previous tip always uses non-secure connection to the internal content server. Even if the request came to the proxy server over HTTPS, the proxy server will pass that request to the content server over HTTP. In many cases this may be exactly what you want to do. But sometimes it may be necessary to preserve the secure connection all the way to the content server. In other words, if client connects to the server over HTTPS, then the proxy should use “https://” prefix when making requests to content server. Similarly, if client connected over HTTP, then proxy should use “http://” connection to content server.
This logic can be easily expressed by this rewrite rule:
Rewrite/Redirect Based on Query String Parameters: When rewriting/redirection decisions are being made by using values extracted from the query string, very often one cannot rely on having the query string parameters always listed in exact same order. So the rewrite rule must be written in such a way so that it can extract the query string parameters independently of their relative order in the query string.
The following rule shows an example of how two different query string parameters are extracted from the query string and then used in the rewritten URL:
No comments:
Post a Comment