How Request Management Works in SharePoint 2013

Spence Harbar has a great 3-part blog here on how to configure request management.  It however does not go into the deep level of what is occurring in the code.  This blog will take you a bit deeper into how Request Management works.

 What is Request Management?  It is a Reverse Proxy implemented in SharePoint 2013.  It is defined by the SPRoutingReverseProxy class.  As Spence points out, Request Management is implemented in the Http Module of SharePoint (Microsoft.SharePoint.ApplicationRuntime.SPRequestModule).  Internally it works like this:

  • An HTTP request is received by a SharePoint Web
  • As part of the ASP.NET pipeline, the SPRequestModule
    is passed the HTTP request for processing
  • The module will check if Request Management
    settings are present for the respective web application
  • If settings are present, the module will then
    check to see if Routing or Throttling has been enabled and if the request management
    service is started.  The module will also
    check to see if the request routing has already been cached as part of any previous requests for the client by
    an internal reverse proxy called the SPRoutingReverseProxy
  • Request Management will then check to see if the
    client has been assigned an affinity to a particular machine via the SPRoutingAffinity
  • If the request does have affinity, Request
    Management will check that the target server is available, if it doesn’t, then
    the next Routing Target will be selected
  • Once a target has been selected, the HTTP
    context will have a “SPRequestManagementRouted” item added to it for future
  • Lastly, the request will then be routed to the
    target, the response will be proxied back to the client as long as it responds
    before the Request Execution Timeout in the Request Management Settings
    • The request is sent using basic HttpRequest classes and it is basically copying the request from the SharePoint server to the target server, so as long as the target server is a part of the SharePoint farm, technically any applications running on the SharePoint server can be routed too (not just SharePoint ones).

I'm actually very excited about having this reverse proxy in SharePoint.  There have been a number of things I have been wanting to do on the ACS network but just couldn't do with both SharePoint and my other apps running.  This gives me the ability to route the http requests to other applications on my internal network, not just SharePoint ones!

Even though Request Management is implemented as a reverse
proxy, it is lacking some common features of a full reverse proxy such as:

  • URL Rewriting
  • Static and Dynamic Content Caching
  • Response manipulation (adding or removing JavaScript,

The process of determining the final target host is as follows:


  • The request is passed to the SP Routing Rule
  • The routing rules are evaluated and a pool of
    targets will be returned.  The first routing
    rule to have targets wins.
  • Each target is pinged to determine if they are
    available, only targets that are available are considered
  • For each available target, the throttling rules
    are applied, if a target fails it is removed from the routing list
  • The remaining targets, if more than one, are
    evaluated based on their weighting, the machine with the lowest weighting is
  • Lastly, and not performant-ly by the way, if there is an affinity machine, it is
    selected and returned (this should have been done first before analyzing the weighting, this is a design flaw in the code)

The last point about this new feature is the APIs are all set as internal.  This is LAME.  It keeps people like me and the real MVPs(the ones that could build these tools whether Microsoft MVP or not) from building GUI tools for it.  Maybe they will open it up in the future?

To learn even more about how Request management works, buy our book when it comes out!



Leave a Reply