Url Rewrite 重寫

前幾天看到園子裏一篇關於 Url 重寫的文章《獲取ISAPI_Rewrite重寫後的URL》 ， URL-Rewrite 這項技術早已不是一項新技術了，這個話題也已經被不少人討論過屢次。搜索一下URL-Rewrite能夠找到不少URL-Rewrite方面的文章和組 件，本身之前也屢次接觸過這個東東，也來講說吧。 ScottGu 有一篇很是經典的 URL-Rewrite Blog

Tip/Trick: Url Rewriting with ASP.NET  http://weblogs.asp.net/scottgu/archive/2007/02/26/tip-trick-url-rewriting-with-asp-net.aspx

 

爲何要進行URL-Rewrite
ScottGu的blog中給出了兩個重要的緣由：
1.保證WebApplication在進行結構調整，移動頁面位置時，用戶收藏的URL不會所以而成爲死鏈。
2. SEO優化。
摘引自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 http://msdn2.microsoft.com/zh-cn/library/ms972974.aspx
  2) Open Source的 UrlRewriter.NET http://urlrewriter.net/
  3) UrlRewriting http://www.urlrewriting.net/en/Download.aspx

這種組件內部核心的工做原理: 都是在本身的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接管的請求。

在這裏對/Pd/Book.aspx的請求被重寫到了 /Pd.aspx?Cg=books.
Web應用程序級別的URL- Rewrite只能重寫Web應用程序接管的請求。它沒有辦法處理.js .jpg的重寫。緣由是這些請求到達IIS後，IIS根本就沒有把這些請求分發到Asp.Net,因此這些請求就不會發生重寫的處理和操做。在IIS中可 以配置，對哪些後綴的請求是被IIS分發到Asp.Net的。

 

 

若是您必定要在Asp.Net級別對.js的請求進行重寫，能夠在這裏指定.js的請求由Asp.Net接管，可是這時您須要本身處理.js的Response。Web服務器級別的URL-Rewrite能夠比較好的解決這方面的問題吧。

2. Web服務器級別的URL-Rewrite

 

Apache服務器
Apache服務器原生支持了URL-Rewrite。在config中打開LoadModule rewrite_module modules/mod_rewrite.so 而後配置重寫的正則表達式。例如：

摘引自Apache2.2中文參考手冊 中文手冊 Apache-UrlRewrite

---------------------------------------------
描述：
這個規則的目的是強制使用特定的主機名以代替其餘名字。好比，你想強制使用www.example.com代替example.com，就能夠在如下方案的基礎上進行修改：
解決方案：
對運行在非80端口的站點
 
RewriteCond %{HTTP_HOST} !^fully\.qualified\.domain\.name [NC]
RewriteCond %{HTTP_HOST} !^$
RewriteCond %{SERVER_PORT} !^80$
RewriteRule ^/(.*) http://fully.qualified.domain.name:%{SERVER_PORT}/$1 [L,R]
 
對運行在80端口的站點
 
RewriteCond %{HTTP_HOST} !^fully\.qualified\.domain\.name [NC]
RewriteCond %{HTTP_HOST} !^$
RewriteRule ^/(.*) http://fully.qualified.domain.name/$1 [L,R]
---------------------------------------------------------------------------