Ghosted and Unghosted Pages

If you explore a SharePoint web site (virtual server) through the IIS MMC, you notice that neither the team sites nor portal areas are visible. However, when you navigate your browser to a team site web page or portal web page, it is rendered. That page is rendered because Share-Point answers the request before IIS is given a chance to look for a physical file mapped to the requested URL.

When SharePoint answers the request for a URL, it looks up the page (URL) in the database. It first examines the Sites table in the configuration database to determine the site collection and consequently the content database to which the page belongs. Next, SharePoint queries the Docs table in the specified content database.

If the returned row from the Docs table has a null Content column, the file is rendered by the file specified in the SetupPath column. This path points to a physical file on the SharePoint front end web server's hard disk. This page is therefore considered a ghosted page because its entry in the Docs table is a pointer or a ghost of a physical file. Because this file exists on the server's hard disk, the ASP.NET parser is used to render the page.

In contrast, if the returned row from the Docs table has a non-null Content column and therefore a null SetupPath, the page is rendered from the data in the Content column. This page is considered unghosted because it is the reverse of a ghosted page. It does not contain a pointer to a physical file. Because there is only a virtual file to parse and no physical file, the ASP.NET parser cannot be used. SharePoint uses its own SafeMode parser.

The benefits and drawbacks to ghosted and unghosted pages can be boiled down to the differences between the ASP.NET and SharePoint SafeMode parsers. The ASP.NET parser compiles a page into an assembly the first time it is rendered. On subsequent page executions, the compilation step is skipped because an assembly exists. This results in faster page execution. In contrast, the SafeMode parser does not compile a page into an assembly. It always parses the page anew to form an object tree structure and then executes against that structure. In this regard it is similar to how ASP (the predecessor to ASP.NET) works. The SafeMode parser not only works differently from the ASP.NET parser but also operates under different rules. These rules effectively make unghosted pages execute slower than comparable ghosted pages. The SafeMode parser works differently from the ASP.NET parser in the following ways:

1. The page will not be compiled. Therefore, all compile directives will be ignored.

2. Inline code cannot be run. It will cause an error, and the page will not execute. The only dynamic code allowed is server-side controls that are marked safe (SafeControls, trusted controls, etc.).

3. The page cannot be executed on a single threaded apartment (STA) thread. Therefore, the Page directive's AspCompat attribute cannot be used.

4. Session state is either on for all pages or off for all pages. The Page directive's EnableSessionState cannot be used to selectively turn on session state for some pages, while disabling it for others.

Now that we understand the functional differences between the parsers, the question becomes what actions make a page ghosted or unghosted? In answering that question, we must talk a little about site definitions (see Chapter 2 for more details). Site definitions consist of physical files that reside on the front end web server's hard disk. When creating a new site, the user can choose a template from one of the front end web server's site definitions. Upon choosing one of these site definition templates, the ASPX pages of the selected template are ghosted and therefore mapped to the physical files on the server's hard disk. Pages become unghosted if the file has been updated using FrontPage 2003 or web folders or if the document library fields have been modified. In addition, all files uploaded to SharePoint are by definition unghosted because there is no physical file on the server's hard disk to reference.

When you understand what types of pages are unghosted (uploaded pages, pages modified with FrontPage, etc.), it should make more sense why the SafeMode parser is more restrictive and therefore slower than the ASP.NET parser. Among other things, the SafeMode parser restricts the user's ability to run malicious server-side code on the front end web server.

It is worth noting that custom site templates are based on site definitions. Therefore, a custom site template duplicates the same ghosting and unghosting found in the site from which it was copied. Thus, all new sites created with this custom site template have the same ghosted and unghosted pages as the originalat the time the template was created. Of course changes to the original site do not cascade to sites using this template.

However, ghosted pages reflect updates made to the physical file to which they are mapped. You could therefore make small formatting changes to these web pages and cascade the changes to sites using them. You would need to be careful not to remove certain resourcessuch as web part zonesfrom the page. Modifying or removing resources can result in a loss of functionality. Cascading changes to unghosted pages is generally not practical and almost always a nightmare.