<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会在一些细节方面造成什么样的区别，以及相关的注意点。

相关链接：

（1）IIS与ASP.NET

（2）使用已有组件进行URL Rewrite

（4）不同级别URL Rewrite的一些细节与特点