SharePoint 2013 - Handling page request in IIS

Today, we will discuss about the basic architecture of SharePoint 2013 and its working with IIS.

The SharePoint 2013 Architecture
Unlike Asp.net, a SharePoint website is distributed among 3 logical parts, namely:-
1) IIS - Where website are create for each web application.
2) 15 Hive - Store configuration files, templates and other components for supporting SharePoint 2013.
3) Content Database - Back end server for each web application.

Lets take an example of the Web Application named "http://sp2013home:10001/" to verify these logical sections.

In central admin you can see the web application named "SharePoint : 10001"

Now lets verify this web application on each of the logical sections.

1) The IIS (inetmgr.exe)

Just like a normal asp.net website, virtual directories are created for each web application in sharePoint. This directories consists of the .aspx pages, web.config, short-cuts to 15 hive folders like _layouts, _vti_bin etc. In the following figure you can see a virtual site named "SharePoint : 10001" has been created.

2) The 15 Hive ("C:\Program Files\Common files\Microsoft Shared\Web Server Extensions\15")

All the configuration files like web.config, feature.xml, etc reside in 15 Hive. It also consist of all the in-built SharePoint master-pages, styles, site definitions, etc. Any custom developed component like webparts, user controls, application pages etc is deployed in 15 hive.
The files in hive are accessed by IIS through shortcuts configured by SharePoint inside the virtual directories.
None of the web application related folders are created in 15 hive.

3) The Content Database

This is back-end database base where all the SharePoint data is stored. List Items, Document library contents, site pages etc are stored in the content database. In the following figure you can see a database named "WSS_Content_10001" exclusively created for "SharePoint : 10001" web application.

How does IIS handle a SharePoint request

1) A request for SharePoint page is sent through browser arrives at HTTP.sys in IIS. The HTTP.sys determines if the request is valid. If the request is not valid, it sends a code for an invalid request back to the client.

2) An IIS website monitors for incoming requests through a particular port, and it checks for a particular host header or IP address, or both. Every SharePoint Foundation web application is hosted in an IIS website that has the same name as the web application.

3) The request is passed through a pipeline of units including authenticating the user, verifying the user’s authorization, building the response, sending the response, and finally, logging the request.

4) The response to any request is produced by an HTTP handler object. Requests are assigned to one or another HTTP handler object depending on the resource requested and the HTTP verb in the request.

5) The request pipeline also contains HTTP modules. Modules are assemblies that typically contain one or more event handlers or define new events that other modules can handle. An HTTP module can register for one or more events in the life cycle of the request.

6) The processing of a request by HTTP modules and an HTTP handler is governed by an HttpApplication object or an object derived from that class. SharePoint installs a global.asax file in the root of each web application (IIS website) that identifies SPHttpApplication as the class from which an HTTP application object is created.

7) SharePoint also modifies the pipeline with a custom HTTP module (SPRequestModule), and with changes to the default applicationhost.config file.

8) SPRequest module eventually request the location of the SharePoint configuration database from the registry. Connection string for the SharePoint configuration database is set using DSN key at  HKLM\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\15.0\Secure\ConfigDB.
So, this is the registry value, you need to change, if you ever need to move configuration database.

9) When an HTTP request is received by a front-end web server, a special driver, HTTP.SYS, detects the request and routes it to the application pool that is handling requests for the targeted IIS website, and thus, the targeted SharePoint web application. Every application pool has an IIS worker process (w3wp.exe) in which the request pipeline for each request is executed.

10) After processing the request, the worker process sends the response back to HTTP.sys which in turn sends the response back to the client and logs the request, if configured to do so.