Sitecore Pipelines and Processors in web request

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.


This pipeline initiate Sitecore application


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:


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


It handles 404 error page and rewrite to proper URL.


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)


It rewrite the URL by embedding language.


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.


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


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.


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


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)


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


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


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


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)


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.


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.


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


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.


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.


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


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


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.


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.


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


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



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


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


Adds renderings to the current page, which are assigned.


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


Builds full page, and expands all controls and placeholders.


All controls are inserted to the page as System Controls.


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


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

No comments:

Post a Comment