How SharePoint integrates with the ASP.NET Infrastructure

SharePoint is built on top of ASP.NET. There are several key classes/objects in the SharePoint infrastructure which customize the ASP.NET pipeline; or in the case of SharePoint 2010 the integrated ASP.NET/IIS pipeline. The abstract and base implementations for these classes, as well as important interfaces, are defined in the System.Web namespace. The SharePoint versions are all defined in the Microsoft.SharePoint.ApplicationRuntime namespace, in the Microsoft.SharePoint.dll assembly. Most of the information provided below comes from using .NET Reflector to inspect these classes, as well as inspecting the .config files on SharePoint servers.

SPHttpApplication

The first of these classes is SPHttpApplication. This class derives from System.Web.HttpApplication , and is associated with SharePoint Web Applications through a global.asax file in the root directory for each WebApp. Its responsibilities are minimal – it registers VaryByCustomString output cache profiles and registers a EventHandler for unhandled exceptions. In SharePoint 2010, it also provides a new SharePointEndRequest event which is fired in the EndRequest event of the HttpApplication. Presumably, developers could hook up to this event easily in the global.asax file.

SPHttpHandler

The next class is SPHttpHandler. It derives from System.Web.DefaultHttpHandler , which implements the IHttpHandler interface. SPHttpHandler is associated with all requests (well, GET, HEAD, and POST requests) via an <add /> element under <httpHandlers> in the web.config file for each SharePoint Web Application, at least in SharePoint 2007.

Most of the work is done by the base class. The SharePoint derivation adds an override for the OverrideExecuteUrlPath, which determines if this request should be handled by owssvr.dll. It also sets some headers and adds HttpOnly for cookies, though this method doesn’t seem like the proper place for that – which brings us to SharePoint 2010, where this handler is gone.

In SharePoint 2010, the handlers for all ASP.NET extensions are the default ones configured in applicationHost.config (under <location path=””>). So *.aspx is handled by System.Web.UI.PageHandlerFactory, *.asmx by System.Web.Services.Protocols.WebServiceHandlerFactory, etc., as they would be for a typical ASP.NET application. *.dll is handled by the ISAPI module in IIS7, which expects to load and execute a DLL in the Web Application’s directory.

owssvr.dll isn’t in the Web Application’s directory of course; it’s in 14\ISAPI. So a special entry is added for the /_vti_bin/owssvr.dll path, pointing it to this universal path. If you think about it, this is also why using a special HttpHandler to hand off to owssvr.dll won’t work anymore – we’re no longer passing all (*) requests to the same handler. Unless we override this, DLL extensions won’t be passed to the ASP.NET page handlers, and once we’re overriding it, might as well use the built-in configuration options to just pass the request straight to where it’s supposed to go.

SPRequestModule

The last, and probably most important, class is the SPRequestModule class. In 2007, this module is added to the ASP.NET pipeline via an <add /> element in the <system.web/httpModules> section in the web.config for each SharePoint Web Application. In 2010, the module is added to the integrated pipeline via the <system.webServer/modules> section, as you would expect.

SPRequestModule directly implements the IHttpModule interface and provides most of the additional configuration and processing needed for SharePoint pages. For example, the Init() method of SPRequestModule is responsible for registering SharePoint’s VirtualPathProvider, which allows pages to be retrieved from the database or file system, as appropriate. It provides other functions as well, which would make a good topic for another post some time.

The SharePoint14Module native module

On the topic of additional SharePoint modules, you’ll notice that a module named SharePoint14Module is also added in the <system.webServer/modules> section. No type is provided, because this is a reference to native module – our old friend owssvr.dll. Native modules must be declared in applicationHost.config in the <system.webServer/globalModules> section, then added to individual locations. You’ll find the SharePoint 14 module first declared there. I believe this indicates that owssvr.dll has now been re-written as an IIS7 native module (instead of an ISAPI filter), and is providing some functionality for each request.

That wraps up an overview of the SharePoint-ASP.NET integration points – SPHttpApplication, SPHttpHandler, and SPRequestModule. Enjoy!

Comments

• Anonymous
  July 14, 2013
  Great post, thank you so much.I have a question related to this: How can I inject something into any page content while keeping the original page content untouched?The scenario I am try to implement is:Inject "Before" and "After" to any page without changing master page or page layout.Users won't see the words when they edit the pages, and once they save the pages, the words will show up. Output cache will work fine Any help will be appreciated and thank you so much

• Anonymous
  June 25, 2014
  forums.iis.net/.../1184037.aspxI'm having issue of above describe linkWild card script mapping fails