(Enlarge)
|
- At the website level, after opening the section "URL Rewrite", you can add a rule. The one that I use the most is "Inbound rules" -> "Blank rule".
|
(Enlarge)
|
- The first type of rule that you may put in place is one which takes a web visitor to another website. In this case, we specify that "defg" should take web visitors to www.virtualsecrets.com. Think of "defg" as a "virtual folder" after the domain name. So, www.yoursite.com/defg will cause the server to redirect the web visitor to www.virtualsecrets.com.
|
(Enlarge)
|
- Another rule you may setup is a rewrite rule which actually masks the location of a file on your website so the web visitor never sees it (however, in using this rule, back-end programming may become more complex).
- In this example we specify that the "virtual folder" called "about" should actually return an image but the web visitor only sees the "virtual folder".
|
(Enlarge)
|
- Another rule you may setup is a redirect rule which redirects the web visitor to another location on your website (the web visitor would see the final location path).
- In this example we specify that the "virtual folder" called "about" should be the location of an image, which the web visitor will see the final location path of.
|
(Enlarge)
|
- There are other rules that you can put together as well using {QUERY_STRING}, {REQUEST_FILENAME} and others. This example shows one way to use {REQUEST_URI} - which is the data in a URL after the domain name - in order to perform a redirect to the main page of a website.
|
(Enlarge)
|
- Here's an example using {QUERY_STRING}. This looks for a specific query string and value; if it's value matches what is specified then it redirects to the main page of the website.
|
(Enlarge)
|
- This example uses {REQUEST_FILENAME} and {HTTPS} to see if a specific webpage is being accessed over https. If the webpage is not being requested over https then this rule will redirect the user back to the page over https.
|
(Enlarge)
|
- Let's talk about outbound rules for a moment. One of the most popular rules I've seen discussed is rewriting the source code of a webpage (to change links, for instance). What is interesting is that the activity seems to be discouraged citing processor overhead (the server has to parse a webpage before it sends that webpage to a website visitor). Depending on what you are doing, it may very well be processor intensive, so I'm going to show here some options you have to limit server processing since no other website I found discussed it.
- This outbound rewrite rule will rewrite (or parse) webpages for links they may contain. What I'm to also include here is how you can further limit what the server parses to help minimize processor overhead.
- This shows the typical declaration of an outbound rule (select blank rule).
|
(Enlarge)
|
- Under the precondition of the outbound rule you see that {RESPONSE_CONTENT_TYPE} is used along with {HTTPS} and {REQUEST_FILENAME}. Instead of parsing all outgoing content that is text/html, you can see, simply by adding additional conditions (which are AND'ed together), you can further limit what is parsed which saves server process time. In this case, the server is instructed to only parse response content (content going to a web visitor) when that content is text/html AND https AND a PHP page.
- I've included the outbound rewrite rule below for closer examination.
....
</rules>
<outboundRules rewrittenBeforeCache="true">
<rule name="linkParseSpecificContent" preCondition="IsHtml">
<!-- Look for links in the web page to change to ensure they are all secure -->
<match filterByTags="A, Area, Base, Form, Frame, Head, IFrame, Img, Input, Link, Script" pattern="(.*)www\.yoursite\.com(.*)" />
<action type="Rewrite" value="https://{HTTP_HOST}{R:2}" />
</rule>
<preConditions>
<preCondition name="IsHtml">
<!-- If content being served is a webpage -->
<add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
<!-- And IF content is being requested over https -->
<add input="{HTTPS}" pattern="^ON$" />
<!-- And IF content being served back is a PHP page -->
<add input="{REQUEST_FILENAME}" pattern="^.\php$" negate="true" />
</preCondition>
</preConditions>
</outboundRules>
</rewrite>
....
|
(Enlarge)
|
- If you are not using static or dynamic content compression you don't need to do anything else to use the outbound rule.
- Now, unfortunately, if you are using static content compression you cannot use the outbound rule.
- If you are using dynamic content compression, you can use the rule but there's a few extra hoops you have to jump through on Windows Server 2008, even in the year 2012. Maybe there will be no such hoop jumping with the next release of Windows Server.
- Okay, the first part of hoop jumping is to only check "dynamic content compression".
|
(Enlarge)
|
- Next, time to mess with the registry of the server! Nope, those days are not over yet.
- Execute the following from the prompt:
reg add HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InetStp\Rewrite /v LogRewrittenUrlEnabled /t REG_DWORD /d 0
|
(Enlarge)
|
- At the server level (in IIS), set dynamic compression as shown.
|
(Enlarge)
|
- At the server level (in IIS), re-arrange the load order of modules (be sure the select "ordered list" to see the load order).
- Here, ensure that "RewriteModule" shows up above "DynamicCompressionModule".
|
(Enlarge)
|
- At the site level (in IIS), locate the outbound rules section.
|
(Enlarge)
|
- Locate "rewriteBeforeCache" and ensure that it is set to "True".
- At this point you are done jumping through hoops for using the outbound rule with dynamic content compression!
|
(Enlarge)
|
- Another rule you may setup is being able to reformat the domain name in the URL. Commonly you would do this in order to do something like change "yoursite.com" to "www.yoursite.com".
- With the URL Rewrite open, add a new rule and select "Canonical domain name".
|
(Enlarge)
|
- Adjust the rule as needed (see example screenshot) and that's it!
|
