SharePoint is ASP.NET, it is well known. Yet, sometimes, it may be difficult to understand why/how some features work, because we don’t usually see them in regular ASP.NET development. However, all of them are build upon standard ASP.NET/IIS functionality, which you can easily duplicate on non-SharePoint environments. Here are some clues.
Most of your SharePoint content does not exist in the filesystem (the “14 hive”), but instead is stored in a content database. How come, then, are we able to access them through a standard URL? In order to achieve this, SharePoint uses a Virtual Path Provider. This is an interesting and mostly underused mechanism that exists since ASP.NET 2.0, which allows obtaining a file stream dynamically. Typical examples are loading pages from a database or from a compressed file. The provider SharePoint uses is called Microsoft.SharePoint.ApplicationRuntime.SPVirtualPathProvider and it is set by the Microsoft.SharePoint.ApplicationRuntime.SPRequestModule module, which, in turn, is set on the Web.config file.
All SharePoint sites feature the _layouts, wpresources folders and its pages and web services, however, these do not physically exist for every site, but only on the 14 hive. There’s a call to TransferRequest inside the Microsoft.SharePoint.ApplicationRuntime.SPRequestModule module which internally redirects to the proper location while preserving the browser URL whenever these paths are being accessed.
As you may know, event handler declarations such as OnClick=”…” on markup files (ASPX, ASCX, Master) are prohibited if these files are not located on the 14 hive. Also, the CompilationMode and AutoEventWireup attributes are also not allowed, as are code blocks (<% … %> and <%= … %>). This is caused by applying a custom page parser filter, Microsoft.SharePoint.ApplicationRuntime.SPPageParserFilter, which is registered on the Web.config file, on the pages section.
The SharePoint Foundation RPC Protocol allows some interesting functionality on contents such as lists and document libraries, on any site. It is invoked by sending requests to an URL with the format http://[site_name]/_vti_bin/owssvr.dll?Cmd=Method_name[&Parameter1=Value1&Parameter2=Value2...]. This is a native ISAPI global module (meaning, written in C/C++ and leveraging the Win32 API plus the Internet Server API) called SharePoint14Module which is registered on the %WINDIR%\System32\inetsrv\config\applicationHost.config file.
This was just a basic description of some of the features that are less known. As always, your feedback and questions/corrections are greatly appreciated!