Monday, July 2, 2012

Sharepoint Page Request and ASP.Net Page Request

Before we compare life cycle of both the page request lets  first understand the application life cycle.

Stages of the ASP.NET application life cycle (IIS 7.0):
  1. Request is made for an application resource: When the integrated pipeline receives a request, the request passes through stages that are common to all requests. These stages are represented by the RequestNotification enumeration. All requests can be configured to take advantage of ASP.NET functionality, because that functionality is encapsulated in managed-code modules that have access to the request pipeline. For example, even though the .htm file-name extension is not explicitly mapped to ASP.NET, a request for an HTML page still invokes ASP.NET modules. This enables you to take advantage of ASP.NET authentication and authorization for all resources.
  2. The unified pipeline receives the first request for the application: When the unified pipeline receives the first request for any resource in an application, an instance of the ApplicationManager class is created, which is the application domain that the request is processed in. Application domains provide isolation between applications for global variables and enable each application to be unloaded separately. In the application domain, an instance of the HostingEnvironment class is created, which provides access to information about the application, such as the name of the folder where the application is stored. During the first request, top-level items in the application are compiled if required, which includes application code in the App_Code folder.
  3. Response objects are created for each request: After the application domain has been created and the HostingEnvironment object has been instantiated, application objects such as HttpContext, HttpRequest, and HttpResponse are created and initialized.

  4. An HttpApplication object is assigned to the request: After all application objects have been initialized, the application is started by creating an instance of the HttpApplication class. If the application has a Global.asax file, ASP.NET instead creates an instance of the Global.asax class that is derived from the HttpApplication class. It then uses the derived class to represent the application.
    Which ASP.NET modules are loaded (such as the SessionStateModule) depends on the managed-code modules that the application inherits from a parent application. It also depends on which modules are configured in the configuration section of the application's Web.config file. Modules are added or removed in the application's Web.config modules element in the system.webServer section.

  5. The request is processed by the HttpApplication pipeline: At this stage the request are processed and various events are called like ValidateRequest, URL Mapping, BeginRequest, AuthenticateRequest and so on. You can find more info over here. The events are useful for page developers who want to run code when key request pipeline events are raised. They are also useful if you are developing a custom module and you want the module to be invoked for all requests to the pipeline. Custom modules implement the IHttpModule interface. In Integrated mode in IIS 7.0, you must register event handlers in a module's Init method.
Stages of the Sharepoint Page Request:

The stages for the SharePoint page request are handled by the IIS in similar way. Except that there are custom handlers for the every sharepoint page request.
When you create a web application in sharepoint, WSS configures the IIS website by adding an IIS application map and creating several virtual directories. Windows SharePoint Services also copies a global.asax file and web.config file to the root directory of the hosting IIS Web site.
Because every request targeting a Web application is routed through aspnet_isapi.dll, the request gets fully initialized with ASP.NET context. Furthermore, its processing behavior can be controlled by using a custom HttpApplication object and adding configuration elements to the web.config file.

First, you can see that Windows SharePoint Services configures each Web application with a custom HttpApplication object by using the SPHttpApplication class. Note that this class is deployed in the Windows SharePoint Services system assembly Microsoft.SharePoint.dll.

In addition to including a custom HttpApplication object, the Windows SharePoint Services architecture uses a custom HttpHandler(SPHttpHandler) and a custom HttpModule(SPRequestModule). These two SharePoint-specific components are integrated into the HTTP Request Pipeline for a Web application using standard entries in the web.config file.


      <remove verb="GET,HEAD,POST" path="*" />
      <add verb="GET,HEAD,POST" path="*"
          type="Microsoft.SharePoint.ApplicationRuntime.SPHttpHandler,..." />

      <clear />
      <add name="SPRequest
      <!-- other standard ASP.NET httpModules added back in -->


ASP.NET 2.0 introduced a new pluggable component type known as a virtual path provider. The idea behind a virtual path provider is that it abstracts the details of where page files are stored away from the ASP.NET runtime. By creating a custom virtual path provider, a developer can write a custom component that retrieves ASP.NET file types, such as .aspx and .master files, from a remote location, such as a Microsoft SQL Server database.

The Windows SharePoint Services team created a virtual path provider named SPVirtualPathProvider that is integrated into every Web application. The SPVirtualPathProvider class is integrated into the ASP.NET request handling infrastructure by the SPRequestModule. More specifically, the SPRequestModule component contains code to register the SPVirtualPathProvider class with the ASP.NET Framework as it does its work to initialize a Web application.

I Hope you liked the article. Please do provide your feedback in the comment box.

Thank you ! Happy Sharepointing !

Behind the scene when we create new web page with sharepoint 2010 :

Total Pageviews