前几天看到园子里一篇关于 Url 重写的文章。
摘引自ScottGu Blog 的原文
---------------------------------------------------------------------------
Why does URL mapping and rewriting matter?
The most common scenarios where developers want greater flexibility with URLs are:
1) Handling cases where you want to restructure the pages within your web application, and you want to ensure that people who have bookmarked old URLs dont break when you move pages around. Url-rewriting enables you to transparently forward requests to the new page location without breaking browsers.
2) Improving the search relevancy of pages on your site with search engines like Google, Yahoo and Live. Specifically, URL Rewriting can often make it easier to embed common keywords into the URLs of the pages on your sites, which can often increase the chance of someone clicking your link. Moving from using querystring arguments to instead use fully qualified URLs can also in some cases increase your priority in search engine results. Using techniques that force referring links to use the same case and URL entrypoint (for example: weblogs.asp.net/scottgu instead of weblogs.asp.net/scottgu/default.aspx) can also avoid diluting your pagerank across multiple URLs, and increase your search results.
In a world where search engines increasingly drive traffic to sites, extracting any little improvement in your page ranking can yield very good ROI to your business. Increasingly this is driving developers to use URL-Rewriting and other SEO (search engine optimization) techniques to optimize sites (note that SEO is a fast moving space, and the recommendations for increasing your search relevancy evolve monthly). For a list of some good search engine optimization suggestions, Id recommend reading the SSW Rules to Better Google Rankings, as well as MarketPositions article on how URLs can affect top search engine ranking.
---------------------------------------------------------------------------
第一点原因中所描述的场景，在Web站点改版中经常碰到。Web站点改版经常会调整一些页面的位置，QueryString中参数的结构等等。很可能使原来用户在收藏夹中收藏的链接成为死链。在这种场景下URL-Rewrite像是软件架构技术中的一个中间层的概念，URL-Rewrite对外公开的URL是被重写过的，这个URL被用户收藏，不会变，当Web站点调整，内部Page的位置改变了，使得内部实际的URL地址也改变了，这时修改内部的重写规则，让原来对外公开的URL重写到新的内部URL上。从而保证了对外URL不变，其实对内已经完成了页面位置的调整。虽然URL-Rewrite可以做到防止死链的产生，但是大多数站点在改版或调整时，不会使用URL-Rewrite来防止死链的产生，一般会直接修改404 The page cannot be found 页面，把404出错页面改成一个更加友好的提示页面，并且会在几秒钟之后跳转到网站首页。
第二点原因是SEO了，如果您的站点是个内部OA ERP CRM这种站点，只需要自己内部人员来访问。其实完全可以不用做SEO，因为这种站点根本不需要搜索引擎来收录，也不需要别人通过搜索引擎找到这个站点，所以这种站点完全没有必要进行SEO优化。如果您的站点是个商业站点，新闻站点，娱乐站点，越多人访问越好的站点，SEO优化是非常重要，此时通过URL-Rewrite进行SEO优化也就非常必要了。随着搜索引擎逐渐成为人们查找信息，索取资源的首选工具，搜索引擎对一个站点的影响也就愈来愈大，下面是 zhangsichu.com 9-1～9-10 这段时间内的第三方来路数据统计。
来路统计是通过记录httpheader中的Referer，来得知用户在浏览这个页面之前所在的那个页面。从而得出用户是通过那个页面到达这个页面的。
在266个独立IP中，有200个IP是来自搜索引擎的。也就是说，用户先通过搜索引擎的搜索结果，然后来到zhangsichu.com的用户有200个。占到了75.2%。一大半的人是通过搜索来的。充分说明了SEO对站点的重要，在这种情况下，就必须做URL-Rewrite进行SEO优化了。
如果您的站点既不需要考虑URL兼容防止死链问题，也不需要进行SEO优化，就完全没有必要进行URL-Rewrite。URL-Rewrite是一个对性能有害的处理过程。
常用的URL-Rewrite方案
URL-Rewrite既可以发生在Web服务器(IIS/Apache)一级，也可以发生在Web应用程序一级(Asp.Net/Jsp/PHP/…)。
1.Web应用程序级别的URL-Rewrite
在Web应用程序级别的URL-Rewrite。有三个比较著名的现成组件。
1) 微软提供的 URL-Rewrite
2) Open Source的 UrlRewriter.NET
3) UrlRewriting
这种组件内部核心的工作原理: 都是在自己的Web Application的web.config中添加httpModule。用这个httpModule来处理重写。(其实也可继承System.Web.HttpApplication，在Application_BeginRequest中插入一个自己的方法处理重写)
其中核心的处理代码，下面的代码摘引自UrlRewriter.NET组件。
1)从IHttpModule继承得到一个自己的HttpModule，这个HttpModule需要在web.config中配置，说明所有的请求都要经过这个HttpModule。
public sealed class RewriterHttpModule : IHttpModule
{
/// <summary>
/// Initialises the module.
/// </summary>
/// <param name="context">The application context.</param>
void IHttpModule.Init(HttpApplication context)
{
context.BeginRequest += new EventHandler(BeginRequest);
}
…
private void BeginRequest(object sender, EventArgs e)
{
// Add our PoweredBy header
HttpContext.Current.Response.AddHeader(Constants.HeaderXPoweredBy, Configuration.XPoweredBy);
_rewriter.Rewrite();
}
}
2)读取重写规则，判断是否需要重写，确定如何重写，进行重写。
public void Rewrite()
{
string originalUrl = ContextFacade.GetRawUrl().Replace("+", " ");
RawUrl = originalUrl;
// Create the context
RewriteContext context = new RewriteContext(this, originalUrl,
ContextFacade.GetHttpMethod(), ContextFacade.MapPath,
ContextFacade.GetServerVariables(), ContextFacade.GetHeaders(), ContextFacade.GetCookies());
// Process each rule.
ProcessRules(context);
// Append any headers defined.
AppendHeaders(context);
// Append any cookies defined.
AppendCookies(context);
// Rewrite the path if the location has changed.
ContextFacade.SetStatusCode((int)context.StatusCode);
if ((context.Location != originalUrl) && ((int)context.StatusCode < 400))
{
if ((int)context.StatusCode < 300)
{
// Successful status if less than 300
_configuration.Logger.Info(MessageProvider.FormatString(Message.RewritingXtoY,
ContextFacade.GetRawUrl(), context.Location));
// Verify that the url exists on this server.
HandleDefaultDocument(context);// VerifyResultExists(context);
ContextFacade.RewritePath(context.Location);
}
else
{
// Redirection
_configuration.Logger.Info(MessageProvider.FormatString(Message.RedirectingXtoY,
ContextFacade.GetRawUrl(), context.Location));
ContextFacade.SetRedirectLocation(context.Location);
}
}
else if ((int)context.StatusCode >= 400)
{
HandleError(context);
}
else if (HandleDefaultDocument(context))
{
ContextFacade.RewritePath(context.Location);
}
// Sets the context items.
SetContextItems(context);
}
这种重写是ASP.NET Pipeline级别的重写，可以重写一切Asp.net接管的请求。
如果您一定要在Asp.Net级别对.js的请求进行重写，可以在这里指定.js的请求由Asp.Net接管，但是这时您需要自己处理.js的Response。Web服务器级别的URL-Rewrite可以比较好的解决这方面的问题吧。
2. Web服务器级别的URL-Rewrite
