Relationship between Application Request Routing and URL Rewrite modules

As most of you know by now, Application Request Routing (ARR) CTP1 was released in early July.  (Download x86 here and x64 here.  Support is available via this forum.)  ARR relies on the URL Rewrite module for inspecting the incoming HTTP requests and making the routing decisions based on the rewrite rules.  These two modules work together via an extensibility point in ARR and the same extensibility can be used for routing HTTP requests via other routing logic.

First, let me explain how ARR works with URL Rewrite module.  As the diagram below illustrates, both the URL Rewrite module and the ARR are invoked in the same request pipeline.  The key point to note is that the URL Rewrite module subscribes to a notification that comes before ARR. 

 

So as the request is being processed through the pipeline, URL Rewrite is applied first.  It inspects the HTTP request and tries to apply the rewrite rules and conditions.  If the rules for ARR match the request, then it calls a setURL API to rewrite the URL with the server group name as the destination (ie. http://<server group name>/{R:1})  As the rewritten URL makes its way through the pipeline, ARR is applied next.  ARR detects that the rewritten URL matches the server group name that has been defined.  Given what ARR knows about the server group, it applies the settings, including a load balance algorithm, for the server group and routes the request to one of the content servers defined in the server group.

That said, ARR relies on an external module to determine which server group to route the HTTP requests to.  The URL Rewrite module is one such external module that can be used to determine the destination server group based on URL rewrite rules.  Other modules can be written, for example, to route the HTTP requests based on the user profile or geo approximity to the requested content resources.  Below is an example of how requests from a user may be routed to an appropriate OWA (Outlook Web Access) server based on where the user's mailbox is located:

The setURL is a native API and unfortunately, there is no managed equivalent API.   This means that the module that interacts with ARR in above scenarios must be written in native code.

1 Comment

  • This is a great explanation. I'm having issues getting ARR and Federation Authentication to work together, and this is helpful to identify which events and what order those events occur for ARR. Once I turned ARR on and setup a proxy rule, the WSFederationModule stopped redirecting to the login page on the ADFS server. I am trying to authenticate before allowing the request to get proxied back to the server farm. The requirement is to keep older back end applications the same but require federated authentication prior to routing requests to the back end. I am looking at the order of the modules but based upon the events I would think that would not matter since the MSDN has this explanation of the events that the auth module subscribes to...

    "WSFederationAuthenticationModule is added to the ASP.NET pipeline by making an entry in the web.config file. It implements IHttpModule, and registers with the ASP.NET runtime to listen for the AuthenticateRequest event. This lets it monitor requests for authentication cookies, and when these cookies are present and valid, to create an instance of IClaimsPrincipal for the authenticated user."

    So I would think that the BeginRequest fires... the URL rewrite module should transform the URL to the server farm there... then the AuthenticateRequest event should fire and result in redirecting the user to the login form. This works without adding ARR so I am puzzled as to what I could be missing. Any feedback would be greatly appreciated.

Comments have been disabled for this content.