Url Rewrite 再说Url 重写

明天看到园子里一篇关于 Url
重写的文章《获取ISAPI_Rewrite重写后的UCR-VL》
UOdysseyL-Rewrite
那项技能早已不是一项新技巧了,这一个话题也已经被不少人谈论过多次。搜索一下U帕杰罗L-Rewrite能够找到很多UXC60L-Rewrite方面包车型客车篇章和零部件,自个儿原先也再三接触过这几个东东,也来说说吗。
ScottGu 有一篇11分经典的 U福特ExplorerL-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

为何要进行U宝马7系L-Rewrite
ScottGu的blog中付出了多少个根本的原由:
1.管教WebApplication在展开结构调整,移动页面地方时,用户收藏的U奥迪Q3L不会由此而改为死链。
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中参数的构造等等。很大概使原本用户在收藏夹中收藏的链接成为死链。在那种现象下UXC90L-Rewrite像是软件架构技术中的2当中间层的定义,USportageL-Rewrite对伯公开的U奇骏L是被重写过的,这一个UTucsonL被用户收藏,不会变,当Web站点调整,内部Page的岗位变动了,使得内部实际的U讴歌RDXL地址也改成了,那时修改内部的重写规则,让本来对外祖父开的UMuranoL重写到新的中间U奥德赛L上。从而确认保障了对外USportageL不变,其实对内已经达成了页面地点的调动。就算U卡宴L-Rewrite能够做到严防死链的发生,然则多数站点在改版或调整时,不会使用U途达L-Rewrite来幸免死链的爆发,一般会直接修改404
The page cannot be found
页面,把404出错页面改成一个尤为温馨的提示页面,并且会在几分钟之后跳转到网站首页。

  第三点原因是SEO了,假使你的站点是个里面OA E途达P
C兰德酷路泽M这种站点,只须要本人内部职员来拜会。其实完全能够绝不做SEO,因为那种站点根本不须求摸索引擎来收录,也不必要外人通过寻找引擎找到那么些站点,所以那种站点完全没有要求实行SEO优化。即便你的站点是个买卖站点,新闻站点,娱乐站点,越多个人走访越好的站点,SEO优化是不行主要,此时经过U路虎极光L-Rewrite实行SEO优化也就可怜要求了。随着搜索引擎逐步变为大千世界寻找信息,索取财富的首要选拔工具,搜索引擎对三个站点的影响也就特别大,下边是
zhangsichu.com 9-1~9-10 这段时日内的第1方来路数据总结。

图片 1

来路总结是通过记录httpheader中的Referer,来得知用户在浏览这么些页面从前所在的不胜页面。从而得出用户是透过万分页面到达那些页面包车型客车。
在2六14个独立IP中,有200个IP是源于搜索引擎的。也正是说,用户先经过搜索引擎的寻找结果,然后来到zhangsichu.com的用户有200个。占到了75.2%。一大半的人是由此查找来的。丰盛表明了SEO对站点的重点,在那种情景下,就不可能不做UCR-VL-Rewrite进行SEO优化了。

 
若果你的站点既不必要考虑UEscortL包容幸免死链难题,也不要求进行SEO优化,就全盘没有要求开始展览U奥迪Q5L-Rewrite。U帕杰罗L-Rewrite是八个对质量有毒的处理进程。

常用的URL-Rewrite方案
U中华VL-Rewrite既能够生出在Web服务器(IIS/Apache)一流,也得以产生在Web应用程序一级(Asp.Net/Jsp/PHP/…)。

 
1.Web应用程序级别的UQashqaiL-Rewrite
  在Web应用程序级其他U宝马7系L-Rewrite。有七个比较知名的现成组件。
  1) 微软提供的 ULX570L-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继承获得2个和谐的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接管的乞请。

 

图片 2

 

在此处对/Pd/Book.aspx的请求被重写到了 /Pd.aspx?Cg=books.
Web应用程序级其他U宝马X5L-Rewrite只可以重写Web应用程序接管的呼吁。它从未章程处理.js
.jpg的重写。原因是那些请求到达IIS后,IIS根本就向来不把那么些请求分发到Asp.Net,所以这么些请求就不会产生重写的处理和操作。在IIS中得以配备,对什么后缀的呼吁是被IIS分发到Asp.Net的。

 

图片 3

 

一旦你肯定要在Asp.Net级别对.js的伸手进行重写,能够在这里钦命.js的请求由Asp.Net接管,可是此时你必要团结处理.js的Response。Web服务器级其他ULacrosseL-Rewrite可以相比好的解决这方面包车型客车题材吗。

2. Web服务器级别的U途乐L-Rewrite

 

Apache服务器
Apache服务器原生支持了UPAJEROL-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]
---------------------------------------------------------------------------

 

IIS6/IIS7 Web服务器
IIS7新的“管道格局”其实是把ASP.NET中的某个概念与IIS进行了特别深度的集成。在IIS7
Program Manager: 迈克 Volodarsky的Blog中有一篇小说分析了那上头的内容:
Breaking Changes for ASP.NET 2.0 applications running in Integrated
mode on IIS
7.0

 

IIS7的“经典情势”与IIS 6基本上是如出一辙的。

在IIS6 +
Asp.Net应用程序级的U昂CoraL-Rewrite,只万幸呼吁被分配到Asp.Net引擎后才能产生重写操作。在IIS7那点被转移了。IIS7能够对没有后缀名的呼吁举办重写,Asp.Net和IIS7进行了纵深的合一。IIS7能够在
IIS
请求管道的别的地点进行一个HttpModule,上边是三个IIS7下Asp.Net的重写配置:

摘引自ScottGu的Blog

 

<?xml version="1.0" encoding="UTF-8"?>

<configuration>

<configSections>
<section name="rewriter" 
requirePermission="false" 
type="Intelligencia.UrlRewriter.Configuration.RewriterConfigurationSectionHandler, Intelligencia.UrlRewriter" />
</configSections>

<system.web>

<httpModules>
<add name="UrlRewriter" type="Intelligencia.UrlRewriter.RewriterHttpModule, Intelligencia.UrlRewriter" />
</httpModules>

  </system.web>

<system.webServer>

<modules runAllManagedModulesForAllRequests="true">
<add name="UrlRewriter" type="Intelligencia.UrlRewriter.RewriterHttpModule" />
</modules>

<validation validateIntegratedModeConfiguration="false" />

</system.webServer>

<rewriter>
<rewrite url="~/products/(.+)" to="~/products.aspx?category=$1" />
</rewriter>

</configuration>

 

其中:<rewrite url=”~/products/(.+)” to=”~/products.aspx?category=$1″
/>那条规则中的~/products/(.+)那条正则表明式。匹配了/products/下的享有链接。
IIS6服务器级别下的重写要求利用ISAPI Filters Rewrite来兑现。

ISAPI Filters有八个要命著名工程:
  1)Helicon Techs ISAPI Rewrite: http://www.isapirewrite.com/
提供2个99英镑(可免费试用30天)的ISAPI
U福睿斯L重写产品全部版,以及叁个免费的轻量级版本。
  2)Ionics ISAPI Rewrite: http://cheeso.members.winisp.net/IIRF.aspx
全免费开源组件。
  在 ISAPI
Filter编制程序重写U陆风X8L

中有认证。

劳务器级的重写与利用程序级的重写最大的区分在于他们发生的空子不如。下图是在服务器级把/Pd/Book.aspx重写到/Pd.aspx?Cg=books

 

 

图片 4

 

请求还没有到Asp.Net引擎,就被重写了。

3.Asp.Net级别上海重型机器厂写的片段小细节难题(部分内容源自ScottGu 的Blog)
  若是页面中留存form且form是runat=server的<form
runat=”server”>,那么这一个页面在重写后form的action是原始UQashqaiL,不是重写后到底的U福特ExplorerL。例如/Pd/Book.aspx重写到/Pd.aspx?Cg=books这些情形。实际用户浏览器访问的地方是/Pd/Book.aspx,在劳动器级被重写后呼吁变成了/Pd.aspx?Cg=books,在这种场合下form的action会被render成/Pd.aspx?Cg=books,其实此时特别想要action被render成/Pd/Book.aspx,让页面PostBack到均等职位。在有些意况下action被render成/Pd.aspx?Cg=books是不会对健康办事有震慑的,只要/Pd.aspx?Cg=books不被重写规则匹配上,/Pd.aspx?Cg=books会被正确发回去Asp.Net引擎。可是浏览器上的地址栏会变化,暴表露真正的地点。假使那一个U帕杰罗L被某分别的规则匹配,那就务须要求form的action被正确的Render成/Pd/Book.aspx,那种统一的重写后的UCRUISERL。

消除办法:
  1)本人包裹form控件。把url写在某些hidden
田野先生里同postback一起回到,render时修改action为hidden 田野同志里的url.
  2)使用JavaScript在form submit前修改action例如
window.document.forms[0].action = window.location;
  3)使用ASP.NET 2.0 Control Adapter(源自ScottGu 的Blog)
 
那种重写是当在运用Asp.Net应用程序一级的重写时,使用Context.Request.RawUrl填写form的action,当使用IIS应用服务器一流的重写时把干净的U君越L记录在Request.ServerVariables[“HTTP_X_REWRITE_URL”]中,使用Request.ServerVariables[“HTTP_X_REWRITE_URL”]填写form的action,填写form
action 的经过都以由此Control Adapter对form Control扩张,override
form控件的 WriteAttribute方法,在Render时再也钦定form的action。

中央源代码
摘引自ScottGu的Blog

图片 5

 

重写后路径包容难点
 
在/Pd/Book.aspx重写到/Pd.aspx?Cg=books的风貌中,页面中要是有绝对地方的财富,如某些img的src=”../logo.gif”或src=”logo.gif”。那时浏览器请求那么些能源条件的地点是/pd/也便是说src=”../logo.gif”请求的门径是/logo.gif,src=”logo.gif”请求的门路是/pd/logo.gif。可是事实上这个财富的条件地点是
/ 因为本来的U昂CoraL是/Pd.aspx?Cg=books。那时就会产生产资料源找不到的情况。
  1)使用劳务器端的img使用 ~ 路径可以化解那些标题(源自ScottGu的Blog)。
  2)使用<base href=” http://xxx/
“></base>标签,这么些标签须求写在head里。告诉页面,页面中存有相对路径的规范路径是
http://xxx/ ,从而消除重写后路径失效的标题。
  base标签的辨证: http://www.w3school.com.cn/tags/tag_base.asp

 
到此地,UCR-VL-Rewrite的标题研究完了。在事实上项目中必将还会遇上种种区别的题材,可是消除的思路,揣摸会是地点那么些技能的组合和扩充,希望因而上面对UKoleosL-Rewrite难题的座谈,会对境遇的新题材能起到一些帮衬的成效。

 

 

小编:葡萄城控件技术团队.Zhang Sichu

职称:Web消除方案专家

相关文章