IIS don’t have such abstraction for validating client certificates, but it does provide the raw mechanism for performing the validation yourself. By default, IIS will do the validation for you during the BeginRequest pipeline event and will fail if any error is found. To perform the validation yourself you need listen the PreBeginRequest global event, stream the certificate from client and finally ignore the SSL Policy Errors (Flags) that you want.

The PreBeginRequest global event is not available (yet) for .NET code, you have to bring your C++ skills and write an IIS global module, no worries, there no too much code to write.

High level, you need:

1. Create a Visual C++ project following the walkthrough Creating a Global-Level HTTP Module By Using Native Code
2. Once you have the RegisterModule function that describes the walkthrough above, create Global-Level Module class as described in Designing Native-Code HTTP Modules. Override the virtual method OnGlobalPreBeginRequest and register for GL_PRE_BEGIN_REQUEST.
3. In the OnGlboalPreBeginRequest method, get a pointer to the IHttpRequest interface and call NegotiateClientCertificate synchronously. This method will ask the client to present its certificate.
4. Once you have the client certificate negotiated, get it by calling GetClientCertificate. The client certificate is represented by the structure HTTP_SSL_CLIENT_CERT_INFO.
5. Finally, just remove the SSL Policy error flags that you don’t care about from the field CertFlags. Set it to zero to ignore everything, including expired certificates.

The code that you need (at your own risk) is something like:

A small deployment suggestion, in the Visual C++ project, change the settings to statically link to all libraries, like STL/CRT/MFC so you don’t require to install the Microsoft Visual C++ Redistributable Package.

For opening { curly bracket you will always require to use the UrlDecode function to generate the { character from its encoded value %7B, that is:

{UrlDecode:%7B}

For closing } curly bracket you don’t have do anything if the character is not nested in a another URL Rewrite expression; otherwise you need to use UrlDecode with %7D.

{UrlDecode:%7D}

Examples

For generating “Products.aspx?Id={Guid}”, where the Guid comes from a map expression:

“Products.aspx?Id={UrlDecode:%7B}{GuidMap:{R:0}}}”

Note that the last closing curly bracket is written as it is, it doesn’t require to be encoded because there is no opening { bracket that matches, so it is handled as a regular character.

• {UrlDecode:%7B}
• {
• GuidMap:{R:0}
• }
• }

When a closing { bracket is nested in another expression you will need to encode it. NameFromGuidMap is a map that requires the input to be formatted as “{GUID}”.

“Products.aspx?Name={NameFromGuidMap:{UrlDecode:%7B}{R:0}{UrlDecode:%7D}}”

• {
• NameFromGuidMap:
• {UrlDecode:%7B}
• {R:0}
• {UrlDecode:%7D}
• }

In Win32 there is the concept of timer-queue timers, and in that APi set, when a timer is deleted by using DeleteTimerQueueTimer API, if INVALID_HANDLE_VALUE is passed to the CompletionEvent, the API automatically wait for any pending notification.

So, applying the same concept, I pass an “invalid” wait handle to Timer.Dispose and it works. Here is the invalid wait handle class:

internal sealed class InvalidWaitHandle : WaitHandle
{
    private readonly static InvalidWaitHandle instance = new InvalidWaitHandle();

    private InvalidWaitHandle() {}

    public static WaitHandle Instance {
        get {
            return instance;
        }
    }

    public override IntPtr Handle {
        get {
            return WaitHandle.InvalidHandle;
        }
        set {
            throw new InvalidOperationException();
        }
    }
}

And for disposing the Timer, just write:

this.timer.Dispose(InvalidWaitHandle.Instance);

My first Windows Phone 7 app is “Tiny Radio” and what it does is to simply tune the closest NPR (National Public Radio) station based on your geographical location. All Windows Phone devices have a built-in FM Radio, to use it, you need to plug your headphones as antenna.

I didn’t want to named “Tiny Radio” as “NPR Finder” or “Public Radio” because I saw those names were used somewhere else, so I decided to use the Tiny word because the app contains all NPR stations in the app itself, that is, it doesn’t require an Internet connection for listening NPR, it detects your location and quickly displays the available stations and the name gives me room if I want to extend it in the future.

To install it, search for “Tiny Radio” in the Marketplace hub in your phone (remember to use the physical Search button). It is free for Windows Phone users.

If you have Zune software, you can click the link https://social.zune.net/redirect?type=phoneApp&id=9dba32a4-fb13-e011-9264-00237de2db9e

It is handy if you are a www.npr.org fan and travel; or just if you want to listen NPR with one single tap.

No further comment.

Inbound Rules

URL Rewrite 1.1. and 2.0 implement an internal cache of rewritten URLs to avoid evaluating the rules every request.

For inbound rules, performance work is more about understanding the rewrite cache and how it works. There are many cache levels in IIS: Output User Mode Cache, Kernel Mode Cache and Rewrite Cache. Please note that application frameworks (e.g. ASP.NET and PHP) can use other caches.

Rewrite Cache Policy

The rewrite cache policy is based on how frequently an URL is hit. If the URL is requested once in a while, the Rewrite Engine will execute all the rules, otherwise it will take the final action from the rewrite cache. One easy way to know if a particular request was served from the cache, is by enabling tracing. For rules resolved from the rewrite cache, you will find events like REWRITE_FROM_CACHE_ACTION, REDIRECT_FROM_CACHE_ACTION, NO_ACTION_FROM_CACHE and NO_MATCH_FROM_CACHE.

IIS determinates if an URL is frequently hit by querying the properties frequentHitThreshold and frequentHitTimePeriod. If the values are 2 and 10 seconds it means that “if the URL is hit 2 times within 10 seconds” it will be marked as frequent hit and the Rewrite Engine will use the rewrite cache. If the time period is increased, the Rewrite Engine will cache more often, that could mean more memory usage, but probably less CPU cycles.

Kernel Mode Cache

The Kernel Mode Cache was introduced a while ago and it allows the Windows Operating System to cache objects without even reaching IIS. You can learn more at https://learn.iis.net/page.aspx/154/walkthrough-iis-70-output-caching/

If your application leverage the kernel mode cache, it is very important to be aware that the Rewrite Engine can potentially disable it and affect throughput. Take a moment to read the section “Interaction with IIS Output Caching” at https://learn.iis.net/page.aspx/465/url-rewrite-module-configuration-reference/

Starting from URL Rewrite 2.0, you can enable tracing and look for the event REWRITE_DISABLED_KERNEL_CACHE. If it is present, analyze the rules’ evaluation and avoid the use of headers and server variables that are not URL derived as described in the “Interaction with IIS Output Caching” section.

Global Rules

Global rules are executed in a very early stage, before the IIS Pipeline is executed indeed. Distributed rules (e.g. at Web Site level) are execute within the pipeline and if a rewrite action happens, it needs to create a child request to re-execute the pipeline with the new URL. Creating a child-request is an expensive operation by nature, thereby one benefit of global rules is that it do avoid the creation of a child request and can have better performance for some scenarios.

The downside of global rules is that they don’t have any rewrite cache at all and the cost of evaluating the rules will be paid every request. If you have just one rule that does a simple matching and rewrite or redirect, it is very likely that it will have better performance than a distributed rule, but if the rule or rules get more complex, it may be better to use distributed rules to leverage the rewrite cache.

For Global Rules is strongly recommended to use Wildcards matching instead of Regex (ECMAScript) since the matching will be done every request.

Linear Evaluation O(N)

Rewrite rules are evaluated linearly, that means that we can use some well known techniques for reducing the cost.

Reorder rules

When your rewrite rules don’t have any kind of workflow, or chaining between rules (i.e. output of Rule#1 is input of Rule#2), you can try to reorder the rules so the most likely to hit rule would be the first one. For example, if the URL “a” is most frequently hit than “x”, you could reorder the rules like:

Rule#1 match “a” rewrite “b” stopProcessing=true

Rule#2 match “x” rewrite “y” stopProcessing=true

Use Rewrite Maps

A rewrite map has almost a constant evaluation O(1). That can help to make quick matches for well known values or even partial values. Read more here: https://learn.iis.net/page.aspx/469/using-rewrite-maps-in-url-rewrite-module/

Using rewrite maps for some strings and substrings look ups can lead to have a really complex rule, make sure that you will have real benefits from it by testing it. For example, a rule set of 3-5 rules in distributed rules, will probably won’t benefit from rewrite maps, because distributed rules can use the rewrite cache that also has an efficient O(1) complexity, but if the rules are global, they may have a benefit.

In the other hand, if the cost of adding a new rule is higher than adding a rewrite map entry (like a rewrite map for user-agents or domain mapping), it may be better to use rewrite maps.

Keep in mind that URL Rewrite 2.0 supports .NET Extensibility in order to create new kind of map functions:

https://code.msdn.microsoft.com/rewriteextensibility

Outbound Rules

Outbound rules can be very expensive because you will be matching and rewriting high volume of data.

Reduce Regex use

Use ExactMatch matching instead of Regex (ECMAScript) whenever is possible. Regex are expensive.

For rules with HTML filters (“a”, “img”, etc.) you can also use Wildcards. For rules that try to match the entire response body you cannot use wildcards because the matching is greedy, instead try to use a simple ExactMatch.

Reduce Evaluation Groups

Evaluation groups is a concept used by URL Rewrite to group rules with HTML filters and without HTML filters. Having the following outbound rule set:

For that rule set, 3 evaluation groups will be created. The first one has both Rule#1 and Rule#2; the second one is just Rule#3 and the last one is Rule#4.

Each evaluation group is evaluated against the entire response and multiple evaluations require to buffer the entire response before sending it to the client. To minimize the number of evaluation groups, reorder the rules (if possible) to group the rules with and without filter:

Rules with filters are by default chained. The output of the Rule#1 will be the input for the Rule#2 and the output of Rule#2 the input of Rule#4. If that is not what you need, set the stop processing property to true.

URL Rewrite 2.0 RTW supports tracing for outbound rules, enable tracing to learn more.

Rewrite before do output caching

Rewrite Module can perform the rewriting of the response body before the IIS Output User Mode Cache saves the response, so next time the rewritten response body can be served from the cache without evaluating any outbound rule. Look for the rewriteBeforeCache property at https://learn.iis.net/page.aspx/665/url-rewrite-module-20-configuration-reference/

This is a huge optimization, but it won’t work for chunked-transfer encoding. The reason is that the entire response body must be available for doing the matching with accuracy.

If you need to know if your application send these response, download wfetch client and look if the response contains the Transfer-Encoding header set to chunked. You can also enable the “Raw View” checkbox to see how the actual response body is encoded.

Conclusion

Hope this information can give you a startup for improving performance of rewriting in high performance scenarios, remember that URL Rewrite is only one piece of your application and even with a highly optimized rewrite configuration, the gain could be marginal when you see the full picture.

After the application failed, look at the Windows Event Logs for an entry like this:

"Faulting application yourapp.exe, version 1.0.0.0, time stamp 0x49e0238, faulting module yourmodule.dll, version 1.1.0.0, time stamp 0x09ec5a57, exception code 0xc0000005, fault offset 0x000000000051000e, process id 0x00, application start time 0x00."

1. Load the module that faulted using windbg.exe -z c:\yourmodule.dll (make sure you have symbols!)
2. List the modules loaded (yourmodule.dll in this case)
   0:000> lm
   start             end                 module name
   00000000`00300000 00000000`00425000   yourmodule    (private pdb symbols)  c:\yourmodule.pdb
3. Find the line where it crashed by adding the 'fault offset' reported in the event viewer to the 'start' address of your module
0:000> ln 300000+5100e
c:\sources\myclass.cpp(130)+0x14

Here are the steps (that work for me):

1. Double click the [Local].testsettings file in the Solutions Items folder in the Solution Explorer window.
2. In the "Test Settings" dialog, choose the "Data and Diagnostics" item.
3. In the list of roles, select "Code Coverage" [Figure 1] and immediately click the '"Configure" button.
4. In the "Code Coverage Detail" [Figure 2] dialog select the assemblies to instrument for code coverage.
5. Run your test scenario and in the "Test Tools" toolbar, click the icon "Code Coverage Results".
6. Done.

Figure 1.

Figure 2.

All these values (DWORD) can be set under the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InetStp\Rewrite

MaxBackReferences – By default 31 (maximum value). Defines the maximum number of back-references that can be used. For example, if you set it to 9, administrator won’t be able to use {R:10} in their rewrite expressions.

RewriteCacheEnabled – By default 1 (true). Enables (1) or disables (0) the internal cache of rewritten URLs. Disabling it will have a negative performance impact.

RewriteCacheThreshold – By default 512. Change it to something smaller if the query string in your URLs varies too much and you are seeing too much memory consumption. The value represents the maximum of cached items per URL path. For example, ‘/cars?drive=0’ and ‘/cars?drive=1’ is one URL path ‘/cars’ that has two different query strings, this registry setting control how many variants of ‘/cars’ can be cached; but it doesn’t control how may URL paths can be cached (e.g. ‘/cars’, ‘/bikes’); that is controlled by how frequently hit is the URL path. Read frequentHitThreshold and frequentHitTimePeriod.

UrlDecodeAllowsDoubleEncoding – By default 1 (true). The module provides a UrlDecode built-in function that allows to decode strings like %25 into single characters. The function will fail by default if finds a double encoded string like %252E, where %25 is first decoded to (%) and in a second pass %2E is decoded to (.). Setting this registry value to 0 can be security problem.

InboundRewriteEnabled – By default 1 (true). Setting this value to 0 (false) will make URL Rewrite to stop listening the IIS notifications, even if you have inbound rules, it won’t process them.

OutboundRewriteEnabled – By default 1 (true). Setting this value to 0 (false) will make URL Rewrite to stop listening notifications for sending responses. This also affects the logRewrittenUrl feature, it will stop working because it relies on those IIS notifications.

LogRewrittenUrlEnabled – By default 1 (true). It can be used to disable the logRewrittenUrl feature.

All these values are read during startup, so you need to recycle your worker process if you change the values and as I said, use them at your own risk.

Add the System.ComponentModel.Composition.dll assembly to your project’s references.

Really simple, I think.