WEB开发网
开发学院WEB开发ASP.NET URL Rewrite(3):在URL Rewrite后保持PostBack地... 阅读

URL Rewrite(3):在URL Rewrite后保持PostBack地址

 2009-03-25 16:51:16 来源:WEB开发网   
核心提示:在进行了URL Rewrite之后,经常会遇到的问题就是页面中PostBack的目标地址并非客户端请求的地址,URL Rewrite(3):在URL Rewrite后保持PostBack地址,而是URL Rewrite之后的地址,以上一篇文章中的重写为例: <rewriter> <rewrite u
在进行了URL Rewrite之后,经常会遇到的问题就是页面中PostBack的目标地址并非客户端请求的地址,而是URL Rewrite之后的地址。以上一篇文章中的重写为例:

<rewriter>
  <rewrite url="^/User/(\d+)$" to="~/User.aspx?id=$1" PRocessing="stop" />
  <rewrite url="^/User/(\w+)$" to="~/User.aspx?name=$1" processing="stop" />
</rewriter>

当用户请求“/User/jeffz”之后,页面中的出现的代码却会是<form action="/User.aspx?name=jeffz" />,这是因为在生成代码时,页面会使用当前Request.Url.PathAndQuery的值来得到form元素的action。这导致了一旦PostBack,地址栏里就会出现“User.aspx?name=jeffz”,而这个地址很可能是请求不到正确的资源的(因为可能被Rewrite到了别处,或者由于目录级别的关系而根本没有该资源)。在之前《UpdatePanel与UrlRewrite》一文中,我说可以在页面末尾添加一行javaScript代码来解决这个问题:

<script language="Javascript" type="text/javascript">
   document.getElementsByTagName("form")[0].action = window.location;
</script>

这行代码的意图非常明显,将form的action修改为window.location(即浏览器地址栏中的路径),这样当页面进行PostBack时,目标地址就会是URL Rewrite之前的地址了。这种做法能够让程序正常运行,但是实在不能让我满意。为什么?

因为太丑了。

因为我们还是把URL Rewrite之后的地址暴露给了客户端。用户只要装一个HTTP嗅探器(例如著名的Fiddler),或者在IE中直接选择查看源文件,我们的目标地址就毫无遮掩的显示在用户面前了。怎么能让用户知道我们的重写规则?我们必须解决这个问题。解决的方法很简单,也已经非常流行了,那就是使用Control Adaptor来改变Form生成时的行为。不过让我感到比较奇怪的是,关于这个Control Adaptor,在网络上搜到的尽是VB.NET的版本,倒是微软主推的C#语言却找不到。虽然只要了解一点VB.NET的语法要改写起来并不困难,但是毕竟也是个额外的工作啊。所以我现在就将这个Adaptor的C#版本代码贴出来,以便朋友们能够直接使用:

namespace Sample.Web.UI.Adapters
{
   public class FormRewriterControlAdapter :
     System.Web.UI.Adapters.ControlAdapter
   {
     protected override void Render(HtmlTextWriter writer)
     {
       base.Render(new RewriteFormHtmlTextWriter(writer));
     }
   }
 
   public class RewriteFormHtmlTextWriter : HtmlTextWriter
   {
     public RewriteFormHtmlTextWriter(HtmlTextWriter writer)
       : base(writer)
     {
       this.InnerWriter = writer.InnerWriter;
     }
 
     public RewriteFormHtmlTextWriter(TextWriter writer)
       : base(writer)
     {
       this.InnerWriter = writer;
     }
 
     public override void WriteAttribute(string name, string value, bool fEncode)
     {
       if (name == "action")
       {
         HttpContext context = HttpContext.Current;
 
         if (context.Items["ActionAlreadyWritten"] == null)
         {
           value = context.Request.RawUrl;
           context.Items["ActionAlreadyWritten"] = true;
         }
       }
 
       base.WriteAttribute(name, value, fEncode);
     }
   }
}

简单的说,这个Control Adaptor其实一直在等待“action”这个属性被输出的那一刻,将value变为当前Request对象的RawUrl属性。这个属性在asp.net刚接受到IIS传来的请求时就确定了,它不会随着接下来BeginRequest中的Rewrite操作而改变,因此我们只要为Form的action输出RawUrl就可以解决PostBack地址改变这个问题了。

不过要让这个Control Adaptor生效,还必须在Web项目中创建一个browser文件,例如“App_Browsers\Form.browser”,在里面写入如下代码:

<browsers>
  <browser refID="Default">
   <controlAdapters>
    <adapter controlType="System.Web.UI.HtmlControls.HtmlForm"
        adapterType="Sample.Web.UI.Adapters.FormRewriterControlAdapter" />
   </controlAdapters>
  </browser>
</browsers>

至此,在ASP.NET层面上作URL Rewrite导致PostBack地址改变的问题已经完美解决了——等等,为什么要强调“ASP.NET层面”?没错,因为如果在IIS层面上作URL Rewrite,这个问题依旧存在。例如您使用了IIRF做URL Rewrite,并让上面的Control Adapter生效,还是会发现页面上PostBack的地址和客户端请求的地址不同。难道RawUrl也变得“不忠诚”了?这不是RawUrl的缘故,而是ASP.NET机制所决定的。为了解释这个问题,我们重新看一下在第一篇文章《IIS与ASP.NET》中那幅示意图:

IIS级别的URL Rewrite发生在上面这幅图中步骤2之前,正因为被重新Rewrite了,所以IIS的ISAPI选择器才会将该请求交给ASPNET ISAPI处理。换句话说,当IIS把请求交由ASP.NET引擎处理的时候,ASP.NET从IIS那里获得的信息中已经是URL Rewrite之后的地址了(例如/User.aspx?name=jeffz),这样无论在ASP.NET处理该请求的哪个环节,都无法得知IIS当初收到请求时的URL。

也就是说,其实真没办法了。

不过“真没办法”四个字是有条件的,完整地说应该是:“靠ASP.NET自身”的确“真没办法”了。不过如果IIS在进行URL Rewrite的时候帮我们一把,那么情况又会如何呢?IIRF作为一个成熟的开源组件,它自然知道ASP.NET引擎,乃至所有的ISAPI处理程序都需要它的帮助,它自然知道“改出手时就出手”的道理,因此它练就了将原始地址存放在服务器变量HTTP_X_REWRITE_URL之中的能力。不过IIRF也不会“自觉”地这么做(多累啊),这还要我们在配置文件中提醒它:

RewriteRule   ^/User/(\d+)$   /User.aspx?id=$1    [I, L, U]
RewriteRule   ^/User/(\w+)$   /User.aspx?name=$1   [I, L, U]

请注意,我们使用了额外的Modifier。在Modifier集合中加入U表明我们需要IIRF将URL Rewrite之前的原始地址存放在服务器变量HTTP_X_REWRITE_URL中。现在我们就可以在ASP.NET获取到这个值了,于是我们将之前的Control Adapter代码中的WriteAttribute方法作如下修改:

public override void WriteAttribute(string name, string value, bool fEncode)
{
   if (name == "action")
   {
     HttpContext context = HttpContext.Current;
 
     if (context.Items["ActionAlreadyWritten"] == null)
     {
       value = context.Request.ServerVariables["HTTP_X_REWRITE_URL"]
         ?? context.Request.RawUrl;
       context.Items["ActionAlreadyWritten"] = true;
     }
   }
 
   base.WriteAttribute(name, value, fEncode);
}

现在action的value已经不是简单地从RawUrl属性中获取了,而是设法从ServerVariables集合中取得HTTP_X_REWRITE_URL变量的值,因为那里存放了IIS所接受到的原始请求的地址。

至此,有关URL Rewrite的主要话题已经讲完了,在下一篇,也就是本系列的最后一篇文章中,我们将重点看一下使用不同层面的URL Rewrite会在一些细节方面造成什么样的区别,以及相关的注意点。

Tags:URL Rewrite URL

编辑录入:爽爽 [复制链接] [打 印]
赞助商链接