Sitecore Pipelines and Processors in web request (Life Cycle)

Sitecore is such a flexible CMS, you can do any customizations so quickly. Sitecore has customized ASP.NET's framework to provide more flexibility and power for itself and Sitecore developers.

Pipelines are nothing but to perform a sequential opterations/process, which is defined in web.config. Which gives better flexibility by adding new or overriding existing processors.

Below are the pipelines covered while any page is requested. These pipelines would be different on Staging and Live environment, also it depends on different modules installed on Sitecore environment. 

initialize

This pipeline initiate Sitecore application 

preProcessRequest

It is invoked for each HTTP request managed by ASP.NET. It is used to prevent Sitecore from processing requests with specific extensions other than .aspx. And yet, it is not used for request processing logic.

Below are processors in this pipeline: 

NormalizeRawUrl

If Sitecore not getting proper raw URL, then it normalize (rewrite)  it and set into current context.

IIS404Handler

It handles 404 error page and rewrite to proper URL. 

FilterUrlExtensions

It decides which extensions to allow or reject. i.e., aspx, html, asmx, ics, etc. are allowed (Allowed/Blocked extensions are specified within this processor configurations in web.config file) 

StripLanguage

It rewrite the URL by embedding language. 

httpRequestBegin

This pipeline contains processors which are used for request processing logic. It sequential finds Site, Device, Language, Item, Layout, etc. details for the requested URL and then allow Sitecore to continue rendering it. 

CheckIgnoreFlag

This is where Sitecore realises the html file doesn’t exists and redirects it to it’s 404 page.

Class: Sitecore.Pipelines.PreprocessRequest.CheckIgnoreFlag
Assembly: Sitecore.Kernel

Description:
Determines if a blanket pipeline active flag has been set.

There are two reasons it might not be set, and both are handled in a the preprocessRequest pipeline’s FilterUrlExtensions processor.

1. The request might have a blocked extension. In the FilterUrlExtensions config entry, there are settings for allowed and blocked extensions. If this request has a blocked extension, then then flag will be set to false.
2. A request might be set up to be handled by a Custom Handler. Custom Handlers are defined in web.config in /configuration/sitecore/customHandlers. If this request matches the trigger attribute of any of those handlers, then pipelines don’t need to run, since requests will be processed by the Custom Handler rather than regular Sitecore processes. If there’s a Custom Handler match, then the flag will be set to ‘false’.

By default, Sitecore sets a SitecoreOn flag to true. If either of the above conditions are met, that flag will be set to false. The SitecoreOn flag is set in the Context.Items collection.

This processor checks the SitecoreOn key’s value to determine if the httpRequestBegin pipeline should run. If the value is false, then the entire httpRequestBegin pipeline is aborted.

StartMeasurements

It starts timer to record performance counters/measurements. The timer is stopped and performance counters/measurements are retrieved in the httpRequestEnd pipeline’s StopMeasurements processor. If any counter exceeds the defined threashold, it's logged in log file.

Class: Sitecore.Pipelines.HttpRequest.StartMeasurements
Assembly: Sitecore.Kernel

Description:
Prepares some performance checks in Sitecore’s Items collection. These are retrieved in the httpRequestEnd pipeline’s StopMeasurements processor and tested against some thresholds. If any threshold is exceeded, it’s written out to the log file as a warning. You can change what threshold is tested in the StopMeasurements configuration in web.config.

Here are the checks that get tracked:

• SC_REQUEST_MEASUREMENT_TIMER key: a new timer object. This will check total elapsed time for the request. The related threshold is TimingThreshold.
• SC_REQUEST_MEASUREMENT_ITEMS key: a count of items accessed. This will check total number of item accesses during the request. The related threshold is ItemThreshold. (The count of accesses is retrieved from Sitecore.Diagnostics.PerformanceCounters.DataCounters.ItemsAccessed.)
• SC_REQUEST_MEASUREMENT_MEMORY key: total allocated memory as reported by the garbage collector. This will check total memory consumed during the request. The related threshold is MemoryThreshold. This value is retrieved from System.GC.GetTotalMemory().
• SC_REQUEST_MEASUREMENT_URL key: the current request’s raw URL.

IgnoreList

Decides whether handle the current request or not depending on the ignoreUrlPrefix setting value. It checks if the requested page is in the ignore URL list in the web.config.

Mostly the URLs which Sitecore does not render itself are set in IgnoreList. Like, RichTextEditor, Telerik Dialogs, axd files.

Set IgnoreUrlPrefixes to a '|' separated list of url prefixes that should not be regarded and processed as friendly urls (ie. forms etc.)

If such page is defined, the pipeline terminates

Class: Sitecore.Pipelines.HttpRequest.IgnoreList
Assembly: Sitecore.Kernel
Description:
Identifies if the file path of the requested URL is in the ignore list. The ignore list is managed by the IgnoreUrlPrefixes Sitecore Setting item in web.config. If the URL’s file path begins with an entry in IgnoreUrlPrefixes, the rest of this pipeline is aborted.

SiteResolver

It parses the incoming URL and Determines the current site defined in /configuration/sitecore/sites. It identifies Site either by hostname of the current request or by passed querystring parameter: sc_site.It resolves Sitecore Site object. This object is now added to the current Context (Sitecore.Context.Site)

Class: Sitecore.Pipelines.HttpRequest.SiteResolver
Assembly: Sitecore.Kernel

Description:
Determines which Sitecore site, as defined in /configuration/sitecore/sites, was requested and updates Sitecore.Context.Site with that information. Sitecore determines this by checking the following:

1. A query string parameter for sc_site
2. If the EnableSiteConfigFiles Sitecore Setting is set to true, then Sitecore will check the request’s physical file directory for a site.config file. Note that the directory it checks will be the full directory path; Sitecore won’t ascend the directory structure looking for a site.config file. For example, if you have a URL for http://site.net/dir1/dir2/file.aspx, you would need to have a physical directory and for dir1 and dir2 and a site.config file in both directories.

If the EnableSiteConfigFiles setting is false, or the directory doesn’t exist, or there is no site.config file in that directory, the algorithm continues with 3, below.

If you’re going to use site.config, which I’d recommend against for its maintenance challenges, the site.config consists of a single site element with a reference attribute that points to the site element in web.config. For example:

<site reference='website_name' />

3. This is the main part of the algorithm that will be hit most frequently. Sitecore uses the Sitecore.Sites.SiteContextFactory class’s GetSiteContext static method to retrieve the SiteContext information associated with the request. It does this by passing in the requested host name, full request path and port number. Next, it loops across each site defined in configuration/sitecore/sites and tests if the current request matches.

Because Sitecore will examine each of the site elements in the order they’re listed in web.config, it’s important to have your most generous match (e.g., for the default website site that Sitecore ships with) listed after more specific options.

If none of these techniques work, Sitecore.Context.Site will end up with null, which may force later processors to abort.

UserResolver

Identifies current user and add it to current request context (Sitecore.Context.User). In backend, Sitecore uses standard ASP.NET membership.

Class: Sitecore.Pipelines.HttpRequest.UserResolver
Assembly: Sitecore.Kernel
Description:
This processor determines the current request’s user account by setting the Sitecore.Context.User property.
Because Sitecore uses standard ASP.NET membership, it starts by examining the HttpContext.Current.User property. If it’s been set already, and it’s a Sitecore User object (Sitecore.Security.Accounts.User) then Sitecore uses that. If it hasn’t been set, Sitecore tries to retrieve the user from the username saved in the standard ASP.NET FormsAuthentication ticket Sitecore sets during authentication.
In the case that HttpContext.Current doesn’t exist (e.g., code is running outside a regular ASP.NET web request, then Sitecore tries to use the current thread’s user.
If neither of these techniques work, Sitecore returns the default user account. This is going to be the Anonymous user on the current security domain, which is set by the current Site, as discovered in the previous SiteResolver processor.

DatabaseResolver

Identifies current database and add it to current request context.(Sitecore.Context.Database. It also resovles database by passing querystring parameter:sc_content.

Class: Sitecore.Pipelines.HttpRequest.DatabaseResolver
Assembly: Sitecore.Kernel
Description:
This processor allows you to override the Database specified by the Site in SiteResolver. If you want, you can append an sc_database query string parameter with the name of a database.
Overriding is only allowed if the current user is an admin or a member of Sitecore Client Users, since specifying this value allows users to connect to something other than web.

BeginDiagnostics

If debugging is on, it starts diagnosis of sitecore request.

Class: Sitecore.Pipelines.HttpRequest.BeginDiagnostics
Assembly: Sitecore.Kernel
Description:
This processor determines what happens if you try to run in Debug Mode in the page editor. That is, it checks that settings are correct; that security is correct; and that debug mode is enabled in Sitecore Settings. If all settings check out, Debug Mode, Profiling, etc., are enabled.

DeviceResolver

Resolves the current Sitecore device either by querystring parameter sc_device or then knowing BrowserAgent and add it to current context (Sitecore.Context.Site.Device)

Class: Sitecore.Pipelines.HttpRequest.DeviceResolver
Assembly: Sitecore.Kernel

Description:
This processor determines which Device Sitecore will use to resolve presentation. It tries the following approaches, in order:

1. The value of the sc_device query string parameter - either the name or GUID of a device in the Context database.
2. The device attribute on the Context’s Site. That is, Sitecore.Context.Site.Device, as specified in web.config in the current site’s device attribute.
3. By matching the values in the Device’s definition item’s fields. First, Sitecore tries to match the Query string field, then the Browser agent field.

Note to match Query string field, every key-value pair in the Query string field has to match the keys in the incoming request’s query string. Empty or non-existent keys in the incoming query string will fail to match. Here are some examples:

Field	URL QS	Matches?
mydevice	Any request	No
mydevice=on	?mydevice	No
mydevice=on	?mydevice=on	Yes
mydevice=on	?mydevice=anything_else	No
mydevice=on	?foo=yes&mydevice=on&bar=no	Yes
mydevice=on&subdevice=2	?mydevice=on	No
mydevice=on&subdevice=2	?mydevice=on&subdevice=2	Yes

To match the Browser agent field, Sitecore just checks if the field value is contained anywhere in the HttpContext.Current.Request.UserAgent’s property value.

4. The defaultDevice attribute on the Context’s Site. That is, Sitecore.Context.Site.DefaultDevice.
5. A device that has its Default field checked (raw value of "1").

Note the difference between a site’s device and defaultDevice. Site.Device overrides Query string and Browser agent field values, while Site.DefaultDevice is the fallback if those fields fail to match.

LanguageResolver

Resolves the Sitecore context language and add it to current context (Sitecore.Context.Language). Language can be identified either by querystring parameter sc_lang or by cookie (SiteName#Lang) value set to the browser.

Class: Sitecore.Pipelines.HttpRequest.LanguageResolver
Assembly: Sitecore.Kernel

Description:
The LanguageResolver determines which language Sitecore should use, if it’s being set during the current request.

During the normal processing of a request, when the language is not being set, Sitecore will retrieve the current language like this:

1. The sc_Language key of the Sitecore.Context.Items collection.
2. The value of the a language cookie SiteName#lang (e.g., for the default website site the cookie key would be website#lang.
3. The language specified in the language attribute of the site config element.
4. The language specified in the defaultLanguage Sitecore Setting in web.config.
5. Failing all other options, the language resolved as en.

During this processor, Sitecore checks if the language was specified in an sc_lang query string parameter. If not, it also checks for any language code that was extracted by the preprocessRequest pipeline’s StripLanguage processor. That processor pulls out the first chunk from the request’s URL (from an initial / to the next / or . character).

If either were set, Sitecore sets the current language which updates the sc_Language key of the Sitecore.Context.Items collection and updates the language cookie (see #2, above). This has the effect of setting the Sitecore.Context.Language property.

CustomHandlers

It triggers custom handlers defiend in customHandlers/handler in web.config. This fulfills use of .ashx requests. Like, for url starts with ~/media/, the hander is set to sitecore_media.ashx. So, it will proceed for all requests of media. Similarly we have different handlers for api, xaml, icon, feed, etc.

Class: Sitecore.Pipelines.HttpRequest.CustomHandlers
Assembly: Sitecore.Kernel
Description:
This processor dispatches requests to specialized handlers that are required. These handlers are defined in web.config under configuration/sitecore/customHandlers.
If the current request ends with the a handler’s file (e.g., sitecore_media.ashx), then Sitecore aborts the current pipeline, since this request is specifically targeting a handler directly.
If the current request should be handled by a custom handler (e.g., a URL that starts with ~/media should be handled by sitecore_media.ashx), then Sitecore rewrites the Context’s path information and aborts the pipeline.
Otherwise, processing continues normally.

FilterUrlExtensions

This processor is actually deprecated, same processor is taking care in preprocessRequest pipeline.

Class: Sitecore.Pipelines.HttpRequest.FilterUrlExtensions
Assembly: Sitecore.Kernel
Description:
This processor is deprecated and is here just for backwards compatibility. This processor has an empty Process method.
On the other hand, the preprocessRequest pipeline has a FilterUrlExtensions processor that ensures requests can proceed and that pipelines should be executed.

QueryStringResolver

It analyzes such query string as “sc_itemid”. It checks this item in context database with context language. If this item is valid, then it sets it to current context.

Class: Sitecore.Pipelines.HttpRequest.QueryStringResolver
Assembly: Sitecore.Kernel

Description:
This processor checks for two values that can be specified in query string parameters:

1. sc_itemid: specifies the Sitecore Item for the current request. Only if the ID can be found through Sitecore.Context.Database.GetItem() is Sitecore.Context.Item set to that Item. Ignored if Sitecore.Context.Item has been set in a previous processor.
2. xmlcontrol: specifies that a Sitecore xmlcontrol should be used as the layout for rendering.

DynamicLinkResolver

It parses dynamic links (Links served using ~link.aspx) and gives itemid, language and database details by using a media prefix syntax (specified in the configuration/sitecore/mediaLibrary/mediaPrefixes section of web.config).

Depending on it, it sets this item as Context Site item.

Class: Sitecore.Pipelines.HttpRequest.DynamicLinkResolver
Assembly: Sitecore.Kernel
Description:
This processor checks if the request was for a specific ID using the ~/link.aspx syntax, or a media item by using a media prefix syntax (specified in the configuration/sitecore/mediaLibrary/mediaPrefixes section of web.config).
This processor only checks for these links if the Context.Item hasn’t already been set by an earlier processor.
If an item has been selected using these syntaxes, it’s assigned to Sitecore.Context.Item.

AliasResolver

One Sitecore item can have multiple aliases, means one item can be accessed using different URLs. It checks the requested URL to see if it matches an alias that exists on the system.

An Alias is a an alternate path for an item when browsing the web site.

For this "AliasesActive" setting should be enabled in web.config

Class: Sitecore.Pipelines.HttpRequest.AliasResolver
Assembly: Sitecore.Kernel
Description:
This processor checks if the request was for an alias instead of a regular item.
First, it checks if aliases are enabled in the AliasesActive Sitecore setting in web.config. If aliases aren’t active, it skips to the next processor.
If aliases are active, it checks if any alias matches the current request’s LocalPath property (HttpRequestArgs.LocalPath). The LocalPath is the portion of the URL after StartPath, generally just the path without domain and port information.
If there’s an alias match, it will try to find the Item pointed to by the alias. If it can find that Item, and the Context.Item hasn’t been set yet, then Context.Item is updated with the Item from the alias. If Context.Item has already been set, then the execution skips to the next pipeline. Note that this means that aliases are searched even if Context.Item was previously assigned, so a large number of aliases could have performance implications.
If Context.Item couldn’t be updated (and still isn’t set), Sitecore will set the Request’s FilePath to the alias’s URL, if present. For example, this is the case for an alias with an external link.

DefaultResolver

Resolves the start path item for the context site. Sitecore instantiates this item using the “RootPath” and “StartItem” attributes of the context site by simply concatenating these values when

1. Context.Item hasn’t been set yet
2. Context.Database has been set (usually from Context.Site.Database)
3. Context.Site has been set and Context.Site.StartPath is non-empty (i.e., positive length)
4. The LocalPath is empty or equals /default

Class: Sitecore.Pipelines.HttpRequest.DefaultResolver
Assembly: Sitecore.Kernel

Description:
This processor sets Context.Item to the default Item for the current Context.Site, if set.

The default Item is applied only if all of these things are true:

1. Context.Item hasn’t been set yet
2. Context.Database has been set (usually from Context.Site.Database)
3. Context.Site has been set and Context.Site.StartPath is non-empty (i.e., positive length)
4. The LocalPath is empty or equals /default

If all of these things are true, it will attempt to retrieve the site’s StartPath item. StartPath is the concatenation of the site’s rootPath and startItem attributes. For example /sitecore/content/home in the default install of Sitecore’s website site. If the Item can be retrieved, it’s assigned to Context.Item.

FileResolver

It checks whether this request is a physical file or not. If it is physical file, then will be served as is, otherwise Sitecore will use its filepath as default.aspx (Default Page) and and continue request with Sitecore rendering process. If it finds same Item Name and a physical file, then physical file will be getting more priority.

Class: Sitecore.Pipelines.HttpRequest.FileResolver
Assembly: Sitecore.Kernel

Description:
The FileResolver checks if there is a physical file at the request path. If there is, then that file will be executed as the Layout for the page instead of any Presentation assigned to the item itself. Sitecore.Context will be available and fully populated, even if a physical file is executed.

The existence of the FileResolver allows you to have Sitecore execute files directly instead of using the normal Sitecore rendering process from an Item in the database.

Note that file names must fully match, including extension. For example, if there’s an item in the Content Tree at /sitecore/content/home/test1 and a file in the root of the Sitecore application named test1.aspx, here’s what will happen with different URL’s:

URL	Result
site.com/test1	Content Item
site.com/test1/	Content Item
site.com/test1.aspx	Physical File

In this way, physical files take precedence over Content Items. Note that in the third example, above, that even though test1.aspx is executed, Sitecore.Context.Item will be populated with the /sitecore/content/home/test1 item in the ItemResolver processor of this pipeline.

ItemResolver

Resolves the Sitecore context item from the incoming URL.

The item will be null when a request is requested, which does not find any Sitecore item.

Class: Sitecore.Pipelines.HttpRequest.ItemResolver
Assembly: Sitecore.Kernel

Description:
Although all of the processors in this pipeline are important, this is the one that many people will feel is the “heart” of the pipeline.

ItemResolver translates the requested URL in to a Content Item from the Content Tree – in other words, this is what finds the item a visitor is looking for when they click on a link.

In the following notes, Sitecore Decoded means that encoding replacements have been completed. Encoding replacements are specified in web.config in /configuration/sitecore/encodeNameReplacements.

Sitecore finds the requested Item by following these steps:

1. If Context.Item has already been set, skip to the next processor.
2. Try to do a straight lookup from the Sitecore Decoded ItemPath, which is the non-domain portion of a URL, stripped of query string, extensions and trailing / characters.
3. Attempt to a lookup from the LocalPath, which is the ItemPath with StartPath removed.
4. Attempt the same, but Sitecore Decoded.
5. Try with the Context.Site.RootPath prepended to LocalPath.
6. Try the same, but Sitecore Decoded.
7. Resolve by a name search. In this step, the resolver tries to get the start item specified in Context.Site.RootPath. If it can find it, it scans each child looking for a match on each chunk of the request’s Sitecore Decoded LocalPath using the Item’s Display Name and Name properties.
8. Same as 6, but tries with only the ItemPath portion of the URL.
9. Finally, if the sc_usesitestartpath query string parameter has been set to true, then the Context.Site.StartItem Item is returned.

If all of these steps fail, the Sitecore.Context.Item will be set to null.

LayoutResolver

It determins layout for the request from querystring parameter: sc_layout or by getting layout assigned to the Sitecore.Context.Item (Set from the presentation details). Sitecore assigns Layout to a request by updating Sitecore.Context.Page.FilePath

Class: Sitecore.Pipelines.HttpRequest.LayoutResolver
Assembly: Sitecore.Kernel

Description:
This processor determines which Sitecore Layout will be used to satisfy the current request.

If Context.Item hasn’t been set, or if Context.Page.FilePath (the layout to be used) has already been set, then processing skips to the next processor.

This processor tries to find a layout using these steps:

1. Determine if the sc_layout query string parameter supplied a valid reference (path or GUID) to a Layout definition Item.
2. If not, see of the Context.Item has a Layout assigned through the Context.Item.Visualization.Layout property, which is set through normal Presentation Layout Details dialogs.
3. If a valid Layout Item has been found, Sitecore will first try to use any XML Controls that have been assigned to it through the Control or Path fields. The processor will also work to decode and transcribe XML Control references (e.g., xmlcontrol query strings).
4. Otherwise, the Layout’s Path will be assigned as a standard .aspx file
5. Finally, if no Layout could be found, Sitecore will use the Layout specified in the DefaultLayoutFile Sitecore Setting, if present.

Sitecore assigns Layout to a request by updating Sitecore.Context.Page.FilePath. If none of these techniques work, that property will return null or the empty string.

ExecuteRequest

Rewrites the context path and handles the “item not found” or ”layout not found” errors

Class: Sitecore.Pipelines.HttpRequest.ExecuteRequest
Assembly: Sitecore.Kernel

Description:
This is where the rubber meets the road. This processor finalizes activity and makes sure the Sitecore.Context is ready for the execution process to begin. It checks the following:

1. That Context.Site has been assigned and the current user has Site Enter permissions. If Site Enter is not granted, Sitecore will redirect to an Access Denied message.
2. If no Context.Item has been assigned, Sitecore will redirect to a Item Not Found error message.
3. If no Layout has been assigned (in Context.Page.FilePath), then Sitecore will redirect to a Layout Not Found error message.
4. If the Layout assigned is not internal to this application, Sitecore will emit a Response.Redirect to the URL specified in Context.Page.FilePath.
5. Finally, if none of that happens, Sitecore updates the HttpContext’s paths with a call to RewritePath with the location of the physical file to execute.

End of Pipeline

After this, ASP.NET will continue execution normally as HttpContext has the correct paths and Sitecore.Context has been fully populated.

RenderLayout

PageHandlers

Custom page handlers are executed here defined in pageHandlers/handler in web.config. We are not having any custom page handlers.

SecurityCheck

Checks security of all items in request for current user. It also checks security depending on Current Site requested and Preview Mode.

InsertRenderings

Adds renderings to the current page, which are assigned.

PageExtenders

We can add page extenders here defined in pageextenders/pageextender. For example, PreviewPageExtender, WebEditPageExtender, DebuggerPageExtender

BuildTree

Builds full page, and expands all controls and placeholders.

InsertSystemControls

All controls are inserted to the page as System Controls.

InsertUnusedControls

All unused controls are inserted to the page as System Controls.

BrowserCaching

Sets browser caching headers. Also add last modified header (Item updated DateTime)