In the beginning, there was an HTTP request. Prior to getting back that first glance of your new SharePoint 2010 Team site, you have to initiate a request to a web front end (WFE) that is hosting the site, but what actually happens during this request? Coming from the ASP.NET world into SharePoint, I always have had an elementary understanding of how the typically HTTP request worked. I recently decided to really study many of the aspects of how SharePoint 2010 work under the covers, and why not start at the beginning.

For those of you who have an understanding of how the HTTP request worked in SharePoint 2007 with IIS 6.0, you may be surprised to learn that there have been a few changes, but not all of these changes are actually being used my SharePoint 2010.

When you submit a HTTP request, the request is intercepted by the HTTP listener (HTTP.sys), this is true in both IIS 6.0 and 7.0. The HTTP listener is responsible for both receiving the response and sending it back to the requesting client. IIS 7.0 enables kernel-mode by authentication by default and runs under the machine account. Using kernel-mode has some benefits are far as caching and request queuing are concerned and can improve authentication performance. Kernel-mode also prevents authentication problems with application pools configured to use a custom identity.

In my SharePoint environment, I examined the SharePoint Central Administration Authentication settings. There you will notice that ASP.NET Impersonation and Windows Authentication are enabled. If you click on ‘Advanced Settings’ in the right pane, you will notice that by default ‘Enable Kernel-mode authentication’ is not selected by default.

According to Chun Liu, SharePoint 2010 does not use Kernel-mode for two primary reasons:

  1. There is an incompatibility between IIS7 kernel mode authentication and IE8 which is the level 1 browser for SharePoint 2010. IE8 uses a way so-called “pre-authentication” to avoid some authentication round trips. But when working with IIS7 kernel mode authentication, the IE8 user may experience separate authentication prompt for every single resource on the first request after IIS recycled. (BugID: Windows 7 628823)
  2. Kernel mode authentication does not support the new Nego2 authentication in IIS7.5.

One of the biggest changes from IIS 6.0 to IIS 7.0 is a change in how the HTTP listener works. In IIS 6.0, the WWW Service managed HTTP administration and configuration, process management, and performance monitoring. The worker process in IIS 7.0 has now moved to a new service called the Windows Process Activation Service (WAS). So this means that the WWW Services takes care of the administration and configuration part of the request and then notifies WAS when a request enters the request queue. The WAS allows you to use the same configuration and process model for HTTP and non-HTTP sites. According to a recent post by Pete Harris, you can run WAS without WWW Service if you don’t need HTTP functionality. Both the WAS and WWW Service run as LocalSystem in the same Svchost.exe process and share the same binaries:

Another difference between IIS 6 and IIS 7, is that IIS now keeps the majority of the functionality in modules, which are components that you can added and removed. This allows you to trim down the HTTP request by only using what SharePoint needs.

So let’s take a deeper look at the modules used by SharePoint 2010. If you open the web.config of your Central Administration site and search for the modules section inside <system.webServer> tag. IIS 7.0 has two types of modules. We have the native module and the managed module. Native modules are the ones that come with IIS, while the managed modules are used to extend IIS functionality. Some of the common native modules include: CustomErrorModule, HTTPRedirectionModule, FileAuthorization, AnonymousIdentification, Profile, etc.

Here are a list of the caching modules that are native to IIS 7.0:

Module Name




Provides user mode caching for files and file handles.



Provides kernel mode and user mode caching in HTTP.sys.



Provides user mode caching of user name and token pairs for modules that produce Windows user principals.



Provides user mode caching of URL information.



I mention these here, as later we will list out the steps in the HTTP request. Since these are native IIS, they will be present in the HTTP pipeline unless they are removed. If we examine the web.config file, we will notice the following modules either being removed or added.

















For a list of native modules, you can use the IIS 7.0 Manager.  Simply select the web application in the left pane, and then double click ‘Modules’ in the center pane.


“In a worker process, an HTTP request passes through several ordered steps, called events, in the Web Server Core. At each event, a native module processes part of the request, such as authenticating the user or adding information to the event log. If a request requires a managed module, the native ManagedEngine module creates an AppDomain, where the managed module can perform the necessary processing, such as authenticating a user with Forms authentication. When the request passes through all of the events in the Web Server Core, the response is returned to HTTP.sys. Figure 2, below, shows an HTTP request entering the worker process.”


So armed with this information, we should be able to put the SharePoint HTTP request together:

HTTP Request

  • User issues a request over the internet
  • The HTTP Protocol Stack (HTTP.sys) intercept the request and passes it to the Svchost.exe
  • Svchost.exe contains the Windows Activation Services (WAS) and the WorldWide Web Publishing Service (WWW Service)
  • WAS requests configuration information from the configuration store, applicationHost.config. This will map virtual directories to physical directories.
  • WWW Service receives configuration information, such as application pool and site configuration
  • WWW Service uses the configuration information to configure HTTP.sys
  • WAS starts a worker process for the application pool to which the request was made
  • Authentication is handled.
  • Request comes in for an ASP.NET Page.
  • The request is given to the SharePoint14Module.
  • The page handler is unable to find a precompiled version of the page class on disk, so it must grab the file and give it to the ASP.NET engine for parsing.
  • The SharePoint14Module will contact either the file system or the content database for the appropriate page class information.
  • The ASP.NET Page engine parses the file and generates a page class.
  • The page class is compiled into a .NET assembly and cached on the disk.
  • An instance of the requested page’s class is created.
  • The response generated from the requested page class is sent back to the original caller.


Subsequent Requests not Using Output Caching

  • Request comes in for an ASP.NET Page.
  • The page handler finds a cached version of the class and creates an instance.
  • The response generated from the requested page class is sent back to the caller.


Requests Using Output Caching

  • Request comes in for an ASP.NET Page.
  • Steps 1-16 are repeated for the first request.
  • The generated response is added to the ASP.NET Cache.
  • The response is sent back to the caller.


Subsequent Requests Using Output Caching

  • Request comes in for an ASP.NET Page.
  • When the request is processed by the Http Modules, the Cache module is passed through. If the page response is found within the ASP.NET Cache, the response is copied from the Cache API and sent straight back to the caller.








3 thoughts on “In the Beginning: SharePoint 2010 and the HTTP Request

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s