dotText源码阅读(5)--URLreWrite和Handler
Dottext需要映射全部不存在的文件到blog应用程序，实际上是需要IIS对于该应用下的问不进行处理，而是交给dottext程序处理，而dottext则利用一系列的handler来进行配置，对应不同的文件类型，或者匹配特定的文件，实现整个blog的URL 重写的。
首先，是通过
<httpHandlers>
<addverb="*"path="*.asmx"type="System.Web.Services.Protocols.WebServiceHandlerFactory, System.Web.Services, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"validate="false"/>
<addverb="*"path="Error.aspx"type="System.Web.UI.PageHandlerFactory"/>
<addverb="*"path="*"type="Dottext.Common.UrlManager.UrlReWriteHandlerFactory,Dottext.Common"/>
</httpHandlers>
确保了任何对blog所在应用程序的访问都会被以上3个handler处理，如果是扩展名.asmx的http请求，会被系统缺省的处理程序处理；而对于错误处理（大多数都是转到error.aspx）会转入到系统的缺省aspx处理程序，其他任何请求都会转到Dottext.Common.UrlManager.UrlReWriteHandlerFactory,Dottext.Common 所以我们首先来看看这个处理句柄：
这是一个工厂类型的执行句柄，他自身并不进行处理。而是负责将请求根据不同的类别进行分别派遣，调出不同的处理程序进行执行，而这构成了dottext高效处理整个blog运行的精妙设计部分。
protected virtual HttpHandler[] GetHttpHandlers(HttpContext context)
{
return HandlerConfiguration.Instance().HttpHandlers;//这是个收集
}
是IhttpHandler接口的实现，用于返回处理http请求的全部句柄。而句柄配置在web.config中，所以dottext是这样获得全部handler的。而HandlerConfiguration.Instance()类似我们前面分析的配置处理体系那里的处理过程：
public static HandlerConfiguration Instance()
{
return ((HandlerConfiguration)ConfigurationSettings.GetConfig("HandlerConfiguration"));
}
是从配置文件的xml片断中，获得产生具体的类实例，并经过反序列化后（请看看HandlerConfiguration的属性定义），得到一个句柄的数组，返回给UrlReWriteHandlerFactory的调用函数。具体为：
public virtual IHttpHandler GetHandler(HttpContext context, string requestType, string url, string path)
{
HttpHandler[] items = GetHttpHandlers(context);
if(items != null)
{
int count = items.Length;
string appStr=Dottext.Framework.Util.Globals.RemoveAppFromPath(context.Request.Path,context.Request.ApplicationPath);//得到访问哪一个应用程序的哪一个具体文件
for(int i = 0; i<count; i++)
{
//定向到特定的aspx文件
if(items[i].IsMatch(appStr)) //看看是否匹配系统配置中的者则表达式
{
//throw new Exception();
switch(items[i].HandlerType)
{
case HandlerType.Page://默认是Page
return ProccessHandlerTypePage(items[i],context,requestType,url);
case HandlerType.Direct: HandlerConfiguration.SetControls(context,items[i].BlogControls);
return (IHttpHandler)items[i].Instance();
case HandlerType.Factory: return ((IHttpHandlerFactory)items[i].Instance()).GetHandler(context,requestType,url,path);
default:
throw new Exception("Invalid HandlerType: Unknown");
}
}
}
}
//如果请求的页面不匹配任何一个句柄，就使用ASP.NET的
return PageHandlerFactory.GetHandler(context,requestType,url, path);
}
获得全部web.config指定的handler以及正则表达式后，就进行匹配当前http访问请求的处理分析，如果请求的URL字符串匹配一个Page类型正则表达式（HttpHandler是一个实体类，通过反序列化后获得了type和Pattern属性，如果请求的资源是aspx或者html的，那么会进行正则式判断是否符合句柄的模式，）如果符合，那么同时就知道了句柄的类型，根据HandlerType.Page 、HandlerType.Direct、HandlerType.Factory进行分别处理。
如果是Page类型（某个aspx页面），那么执行：
private IHttpHandler ProccessHandlerTypePage(HttpHandler item, HttpContext context, string requestType, string url)
{
string pagepath = item.FullPageLocation;
if(pagepath == null)
{
pagepath = HandlerConfiguration.Instance().FullPageLocation;
}
HandlerConfiguration.SetControls(context,item.BlogControls);
IHttpHandler myhandler=PageParser.GetCompiledPageInstance(url,pagepath,context);
return myhandler;
}
HandlerConfiguration.Instance()的代码如下：
public static HandlerConfiguration Instance()
{
return ((HandlerConfiguration)ConfigurationSettings.GetConfig("HandlerConfiguration"));
}
同样，这也是配置文件通过反序列化得到一个HandlerConfiguration的实例，HandlerConfiguration的配置节内容在web.config中存在，我们会得到一个defaultPageLocation属性，FullPageLocation如果在属性无法获取的时候就返回defaultPageLocation的值，也就是说，通常我们访问某个目录，不带指定的aspx 的page文件名，就会自动访问defaultPageLocation.的指示的值。
SetControls 是针对部分页面的，就是类似<HttpHandlerpattern="/archive/\d{4}/\d{1,2}\.aspx$"controls="ArchiveMonth.ascx"/>这类page 的，通常是指向一个用户控件，而大家知道用户控件实际上就是一个page。SetControls会把控件加入到当前请求的context重，以便执行期间从context中区的控件。
PageParser对象实际上是asp.net的解释对对象，它将指定的资源编译成程序集，这类似一个普通的物理存在的aspx页面执行机制。大家注意到，返回的是一个IhttpHandler对象，实际上asp.net的任何一个page都应该实现这个接口的，所以此处的逻辑就相当于执行了一个存在的页面。虽然页面可能不存在，但是通过配置指定最后得到了一个IhttpHandler对象处理了用户的http请求，这是Page类型的处理过程简要描述。
第二类HandlerType是Direct ,有以下的http资源请求定向到这类Handler:
<HttpHandlerpattern="(\.config|\.asax|\.ascx|\.config|\.cs|\.vb|\.vbproj|\.asp|\.licx|\.resx|\.resources)$" type="Dottext.Framework.UrlManager.HttpForbiddenHandler, Dottext.Framework"handlerType="Direct"/>
<HttpHandlerpattern="(\.gif|\.js|\.jpg|\.zip|\.jpeg|\.jpe|\.css|\.rar|\.xml|\.xsl)$"type="Dottext.Common.UrlManager.BlogStaticFileHandler, Dottext.Common"handlerType="Direct"/>
...... <HttpHandlerpattern="/services\/pingback\.aspx$"type="Dottext.Framework.Tracking.PingBackService, Dottext.Framework" handlerType="Direct"/> <HttpHandlerpattern="/services\/metablogapi\.aspx$"type="Dottext.Framework.XmlRpc.MetaWeblog, Dottext.Framework" handlerType="Direct"/>
可以看到，大部分我们找不到实际的文件名，但是却可以通过访问blog下的url返回内容，系统根据url判断如何返回内容。我们举一个例子来看看Direct怎么执行的。看看<HttpHandlerpattern="/rss\.aspx$"type="Dottext.Common.Syndication.RssHandler, Dottext.Common" handlerType="Direct"/>
执行：
case HandlerType.Direct: HandlerConfiguration.SetControls(context,items[i].BlogControls);
return (IHttpHandler)items[i].Instance();
时候，会实例化一个Dottext.Common.Syndication.RssHandler类的实例（RssHandler是间接实现了IhttpHandler接口的），它继承自抽象类BaseSyndicationHandler，BaseSyndicationHandler实现了总体的返回特定格式RSS文档的功能和能力，通过继承覆盖，不同的格式的实现类（RSS20和ATOM等）实现了各自格式的rss文档返回给用户。总之，在这类的handler中，最终通过Context.Response操纵到客户的输出流。
第三类的是Factory类型的，其自身就是一个工厂模式的handler，会再次将当前url转交给下一级handler,这样实现了可扩展性。如果dottext的新功能需要进一步处理URL得到其他功能就可以利用此类进行处理。譬如：
<HttpHandlerpattern="/(?:admin)"type="Dottext.Web.UI.Handlers.BlogExistingPageHandler, Dottext.Web"handlerType="Factory"/>
当用户访问应用程序下的/admin目录时候，自然处于该Dottext.Web.UI.Handlers.BlogExistingPageHandle 处理。由于是工厂模式，所以我们着重看看：
public virtual IHttpHandler GetHandler(HttpContext context, string requestType, string url, string path)
{ BlogConfig config = Config.CurrentBlog(context);
if(ConfigProvider.Instance().IsAggregateSite)
{
string app = config.Application.ToLower();
url = Regex.Replace(url,app,"/",RegexOptions.IgnoreCase);
app = "\\\\"+config.CleanApplication+"\\\\";
path = Regex.Replace(path,app,"/",RegexOptions.IgnoreCase);
if(!Regex.IsMatch(path,"\\.\\w+$"))
{
path = System.IO.Path.Combine(path,"index.aspx");
}
}
return PageParser.GetCompiledPageInstance(url, path, context);
}
处理时候，首先取得当前blog的配置，ConfigProvider.Instance()返回一个Iconfig接口的实例，看看这个Instance的代码：
static ConfigProvider() //静态构造函数
{
ConfigProviderConfiguration cpc = Config.Settings.BlogProviders.ConfigProvider;
config = (IConfig)cpc.Instance();
config.Application = cpc.Application;
config.CacheTime = cpc.CacheTime;
config.Host = cpc.Host;
config.ImageDirectory = cpc.ImageDirectory;
config.BlogID = cpc.BlogID;
}
private static IConfig config = null;
public static IConfig Instance()
{
return config;
}
执行静态构造函数，通过Config.Settings.BlogProviders.ConfigProvider反序列化得到ConfigProviderConfiguration。ConfigProviderConfiguration继承抽象类BaseProvider，通过BaseProvider的instance方法：
public object Instance()
{
return Activator.CreateInstance(System.Type.GetType(this.ProviderType));
}
此处的ProviderType是通过反序列化得到：
[XmlAttribute("type")]
public string ProviderType
{
get { return _type; }
set { _type = value; }
}
也就是
<ConfigProvidertype="Dottext.Common.Config.MultipleBlogConfig, Dottext.Common"host="localhost" cacheTime="120"/> 中指明的MultipleBlogConfig 类型。MultipleBlogConfig继承自BaseBlogConfig , BaseBlogConfig实现了IConfig,所以你才看到
config = (IConfig)cpc.Instance();
然后，得到了相应的属性IsAggregateSite。该属性的意思是当前访问的是否是聚合站点（而不是但个博客的站点，只有聚合站点才可以使用存在的aspx文件）。确认聚合站点后，就取得应用程序目录下的实际aspx文件，然后利用CLR的功能PageParser.GetCompiledPageInstance(url, path, context)返回页面执行结果。
所有blog的http请求，依据URL通过正则表达式匹配到不同的Handler类型，实现了3种类别的处理，但最终用户看到的是请求执行结果。修改web.config我们可以进行特定资源的特殊执行，这是UrlReWrite的实质。
