iis7 asp.net url重写 在ASP.NET中重写URL - IIS - 服务器之家

服务器之家

专注于服务器技术!
当前位置:首页 > Web服务器 > IIS

iis7 asp.net url重写 在ASP.NET中重写URL

发布时间:2017-03-20 来源:服务器之家

经常有人请我指导应该如何动态地“重写”URL,以在他们的web应用中发布比较干净的URL端点。这个博客帖子概述了几个方法,你可以用来在中干净地映射或重写URL,以及按照你自己的需求组织你的URL的结构。

为什么URL映射和重写很重要?

下面是开发人员想要对URL有更大的灵活性的最常见的场景:

1) 处理这样的情形:你要更改你的web应用中网页的结构,但你同时也要确保在你移动网页后,那些被人收藏的老URL不会成为死链接。重写URL允许你透明地将请求转交到新的网页地址而不出错。

在一个搜索引擎日渐驱动网站访问量的世界里,在你的网页排名上稍微得到一些提高就能给你的业务带来不错的投资回报(ROI)。逐渐地,这驱使开发人员使用URL重写以及其他SEO(搜索引擎优化 )技术来优化网站(注,SEO是个步调很快的空间,增加你的搜索相关性的建议月月在演变)。想了解一些关于搜索引擎优化方面好的建议的话,我建议你阅读一下《SSW Rules to Better Google Rankings (SSW的提高Google排名之要领)》,以及MarketPosition关于《how URLs can affect top search engine ranking (URL会如何影响顶级搜索引擎排名)》的文章。

例程的URL重写场景

为这个博客贴子起见,我将假设我们将在一个应用里建造一套电子商务的产品目录网页,产品是按种类来组织的(譬如,图书,录像,CD,DVD等等)。

但我们不想使用查询字符串来呈示每个类别,我们想修改应用,让每个产品类别对搜索引擎来说看上去象是一个独特的URL,并且在实际的URL中嵌入关键词(而不是通过查询字符串参数)。我们将在这个博客帖子剩下来的篇幅里,讨论一下达成这个目的我们可以采取的4种不同方法。

方法一:使用Request.PathInfo 参数而不是查询字符串

我将示范的第一个方法根本不使用URL重写,而是使用中不太为人所知的一个特性,Request的PathInfo属性。为帮助解释这个属性的有用之处,考虑一下我们电子商店下面这些URL的情形:

然后,你可以轻易地编写一个函数来获取产品类别,象这样(下面这个函数去除前面的斜杠字符,只返回“Books”,“DVDs”,或 “CDs”):

    Function GetCategory() As String

        If 

(Request.PathInfo.Length = 0) Then
            Return ""
        Else
            Return Request.PathInfo.Substring(1)
        End If

    End Function

方法二:使用HttpModule实现URL重写

上述Request.PathInfo技术的替换方法是,利用提供的HttpContext.RewritePath方法。这个方法允许开发人员动态地重写收到的URL的处理路径,然后让使用刚重写过后的路径来继续执行请求。

譬如,我们可以选择向大众呈示下列URL:

    void Application_BeginRequest(object sender, EventArgs e) { string fullOrigionalpath = Request.Url.ToString();
        }
        }
    } 

手工编写象上面这样的编码的坏处是,很枯燥乏味,而且容易犯错。我建议你别自己写,而是使用网上现成的HttpModule来完成这项工作。这有几个你现在就可以下载和使用的免费的HttpModule:

    <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> <rewriter>
  </rewriter>  
</configuration> 

  <rewriter>
  </rewriter>  

这使得你的编码极其干净,并且扩展性非常之好。

这个样例和这个技术的很好的地方在于,为部署使用这个方法的应用,不需作任何服务器配置改动。在设置为中等信任安全等级(medium trust)的共享主机的环境里,这个技术也行之有效 (只要把文件FTP/XCOPY到远程服务器就可以了,不需要安装)。

方法三:在IIS7中使用HttpModule 实现无扩展名的URL重写

在 IIS5 和 IIS6 中,使用处理上面这样的URL不是很容易。 IIS 5/6 使得在ISAPI扩展里非常难以重写这些类型的URLS。你需要做的是使用ISAPI过滤器在IIS请求管道(request pipeline)的较早期实现重写。我将在下面的第四个方法里示范如何在 IIS5/6 实现这样的重写。

    <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>
  </rewriter>
</configuration>

注意一下<system.webServer>内<modules>部分设置为true的runAllManagedModulesForAllRequests属性。这个属性确保来自Intelligencia的模块(是在IIS7正式发布前编写的),会被调用,有机会重写到服务器的所有URL请求(包括文件夹)。上面的web.config文件非常酷之处在于:

1) 它在任何IIS7机器上都会工作,你不需要管理员在远程主机上启用任何东西,它也能在设置为中等信任安全等级(medium trust)的共享主机的环境场景下工作。

2) 因为我在<httpModules>和 IIS7 的<modules> 部分同时配置了UrlRewriter,我既能在 VS内置的web服务器(即Cassini)中,也能在IIS7下使用同样的URL重写规则。两者完全支持无扩展名的URL重写。这使得测试和开发非常容易。

IIS 7.0 将在今年的晚些时候作为Windows Longhorn服务器的一部分发布,将在几个星期内随Beta3版本的发布支持go-live许可。由于添加到IIS7中的所有的新宿主(hosting)特性,我们预期主机供应商将会非常快地开始积极提供IIS7账号,这意味着你应该很快就可以开始利用上述的无扩展名的URL重写支持。我们将在 IIS7 RTM 时段里发布一个为微软所支持的URL重写模块,该模板是免费的,你可以在IIS7上使用,并且这模块将对你web服务器上的所有内容的高级URL重写场景提供很好的支持。

方法四:在IIS5和IIS6中使用 ISAPIRewrite 来实现无扩展名的URL重写

如果你不想等到IIS7出来才利用无扩展名的URL重写,那么你最好的措施是使用ISAPI过滤器来重写URL。我知道有2个ISAPI过滤器方案,你也许要去看一下:

我没亲手用过上面的产品,虽然我听过到对这2个产品的好评。Scott Hanselman和 Jeff Atwood 最近都写了精彩的博客贴子讲述使用这些产品的体验,同时提供了一些如何在这些产品中配置匹配规则的例子。Helicon Tech的ISAPI Rewrite的规则使用跟 Apache的mod_rewrite同样的句法,譬如(取自Jeff的博客贴子):

[ISAPI_Rewrite]
# fix missing slash on folders
# note, this assumes we have no folders with periods!
RewriteCond Host: (.*)
RewriteRule ([^.?]+[^.?/]) http\://$1$2/ [RP]

# remove index pages from URLs

# force proper www. prefix on all requests
RewriteCond %HTTP_HOST ^test\.com [I]

# only allow whitelisted referers to hotlink images
RewriteRule .*\.(?:gif|jpg|jpeg|png) /images/block.jpg [I,O]

一定要去读一下Scott和Jeff的贴子以了解这些ISAPI 模块的详情,以及你都能用它们做些什么。

注:使用ISAPI过滤器的一个坏处是,共享主机环境一般不允许你安装这样的组件,所以你要用它们的话,你要么需要一个专用的虚拟主机服务器,要么需要一个专用的主机服务器。但,如果你有一个主机计划允许你安装ISAPI的话,这会在IIS5/6下会提供最大的灵活性,让你过渡到IIS7推出为止。

在URL重写里处理 PostBack

在 1.0 和1.1 中,大家经常诉诸于继承<form> 控件生成他们自己的控件,来正确地输出要使用的action属性。虽然这可以工作,但结果有点乱,因为这意味着你需要更新你所有的页面来使用这个另外的表单控件,而且有时在Visual Studio所见即所得设计器里也会遇上问题。

你可在这里查看一个我创建的样例实现,其展示了该如何实现与URL重写协作的表单控件适配器(Form Control Adapter) 。它在我上面使用的第一个(Request.PathInfo),第二个方法中都工作,它使用Request的RawUrl属性获取原先没改写过的 URL来显示。而在第四个方法(ISAPIRewrite过滤器)中,你可以获取ISAPI过滤器保存在Request.ServerVariables["HTTP_X_REWRITE_URL"] 中的原先的URL值。

我上面的FormRewriter类实现在标准的和 AJAX 1.0网页上应该都工作(如果你遇上问题的话,告诉我一声)。

正确地处理CSS和图像引用

不少人在第一次使用URL重写时,有时会遇上一个疑难杂症,就是他们发现他们的图像和CSS样式表引用有时会停止工作。这是因为他们在HTML网页里有对这些文件的相对引用,当你开始在应用里重写URL时,你需要意识到浏览器经常会在不同的逻辑层次结构层上(logical hierarchy levels)请求文件,而不是实际存储在服务器上的东西。