引言让我们花点时间来看一下网站上的一些 URL。您是否发现一些类似于 http://www.51aspx.com/info/dispEmp%20...%20pID&＃61;459-099&;type&＃61;summary 的 URL&＃xff1f;或者&＃xff0c;您可能将一系列网页从一个目录或网站移动到另一个目录或网站&＃xff0c;结果导致已将旧 URL 用作书签的访问者断开链接。在本文中&＃xff0c;我们将了解如何通过将 http://51aspx.com/CV/UrlReWriter//dispEmp ... pID&＃61;459-099&;type&＃61;summary 替换为类似于 http://51aspx.com/CV/UrlReWriter/ 的网址&＃xff0c;使用 URL 重写将那些冗长的 URL 缩写为富有意义且容易记忆的 URL。我们还将了解如何将 URL 重写用于创建智能 404 错误。
URL 重写是截取传入 Web 请求并自动将请求重定向到其他资源的过程。执行 URL 重写时&＃xff0c;通常会检查被请求的 URL&＃xff0c;并基于 URL 的值将请求重定向到其他 URL。例如&＃xff0c;在进行网站重组而将 /people/ 目录下的所有网页移动到 /info/employees/ 目录中时&＃xff0c;您可能希望使用 URL 重写来检查 Web 请求是否指向了 /people/ 目录中的文件。如果请求指向 /people/ 目录中的文件&＃xff0c;您可能希望自动将请求重定向到 /info/employees/ 目录中的同一文件。
使用传统的 ASP&＃xff0c;应用 URL 重写的唯一方法是编写 ISAPI 筛选器&＃xff0c;或者购买提供 URL 重写功能的第三方产品。但是&＃xff0c;使用 Microsoft® ASP.NET&＃xff0c;您可以通过很多方法来轻松地创建您自己的 URL 重写软件。本文讨论了可供 ASP.NET 开发人员实现 URL 重写的各种技术&＃xff0c;然后讨论了 URL 重写的一些实际使用情况。在深入讨论 URL 重写的技术细节之前&＃xff0c;让我们先看一些可以使用 URL 重写的日常情景。
返回页首 URL 重写的常见用法创建数据驱动的 ASP.NET 网站时&＃xff0c;通常会产生一个单个的网页&＃xff0c;该网页基于查询字符串参数显示数据库数据的子集。例如&＃xff0c;在设计电子商务站点时&＃xff0c;您的任务之一便是允许用户浏览待售产品。为此&＃xff0c;您可以创建一个名为 displayCategory.aspx 的页面&＃xff0c;该页面将显示给定类别的产品。可以通过查询字符串参数来指定要查看的该类别的产品。也就是说&＃xff0c;如果用户要浏览待售的 Widget 产品&＃xff0c;并且所有 Widget 产品的 CategoryID 均为 5&＃xff0c;则用户可以访问以下网址&＃xff1a;http://51aspx.com/CV/UrlReWriter/displayCategory.aspx?CategoryID&＃61;5。
创建具有此类 URL 的网站有两点不足&＃xff1a;首先&＃xff0c;从最终用户的角度考虑&＃xff0c;URL http://51aspx.com/CV/UrlReWriter/displayCategory.aspx?CategoryID&＃61;5 比较杂乱。可用性专家 Jakob Neilsen 建议遵循以下标准来选择 URL&＃xff1a;
- 简短。
- 易于键入。
- 可以看出站点的结构。
- “可删节”&＃xff0c;允许用户通过删除 URL 的组成部分来浏览站点。
较好的方法是允许使用切合实际且容易记忆的 URL&＃xff0c;如 http://51aspx.com/CV/UrlReWriter/。只要看一眼 URL&＃xff0c;您便可以推断出将要显示的内容 -- 有关 Widget 的信息。此 URL 也很容易记住和共享。我可以告诉我的同事“请查看 yoursite.com/products/Widgets&＃xff0c;”&＃xff0c;她可能无需再次问我 URL 是什么即可打开该页面。&＃xff08;尝试一下&＃xff0c;您只需说出“Amazon.com 页面”即可&＃xff01;&＃xff09;此 URL 还将显示出来&＃xff0c;并且应该是“可删节”的。也就是说&＃xff0c;如果用户删去 URL 的末端&＃xff0c;键入 http://51aspx.com/CV/UrlReWriter/&＃xff0c;他们应该看到所有产品的列表&＃xff0c;或者至少应该看到他们可以查看的所有类别的产品列表。
注意&＃xff1a;要获得“可删节”URL 的最好示例&＃xff0c;可考虑使用由许多 blog 引擎生成的 URL。要查看 2004 年 1 月 28 日的帖子&＃xff0c;用户可以访问诸如 http://someblog.com/2004/01/28 的 URL。如果该 URL 被删节为 http://someblog.com/2004/01&＃xff0c;用户将看到 2004 年 1 月的所有帖子。将该 URL 进一步删节为 http://someblog.com/2004 将显示 2004 年的所有帖子。
除了简化 URL 之外&＃xff0c;URL 重写还经常用于处理网站重组&＃xff0c;以免导致大量链接断开或书签过期。
返回页首 请求到达 IIS 时将会发生什么情况在正式研究 URL 如何实现重写之前&＃xff0c;应首先了解 Microsoft® Internet Information Services (IIS) 如何处理传入请求&＃xff0c;这一点非常重要。当请求到达 IIS Web 服务器时&＃xff0c;IIS 检查被请求文件的扩展名以确定如何处理该请求。IIS 可以自行处理请求&＃xff08;如 HTML 页面、图像以及其他静态内容&＃xff09;&＃xff0c;或者将请求路由到 ISAPI 扩展。&＃xff08;ISAPI 扩展是一个处理传入 Web 请求的非托管编译类。其任务是生成被请求资源的内容。&＃xff09;
例如&＃xff0c;当传入针对 Info.asp 网页的请求时&＃xff0c;IIS 会将此消息路由到 asp.dll ISAPI 扩展。然后&＃xff0c;该 ISAPI 扩展将加载被请求的 ASP 页面&＃xff0c;执行该页面&＃xff0c;并将所呈现的 HTML 返回给 IIS&＃xff0c;然后&＃xff0c;IIS 将该 HTML 发送回请求客户端。对于 ASP.NET 页面&＃xff0c;IIS 会将此消息路由到 aspnet_isapi.dll ISAPI 扩展。然后&＃xff0c;aspnet_isapi.dll ISAPI 扩展将处理操作传递给托管的 ASP.NET 辅助进程&＃xff0c;该辅助程序将处理请求&＃xff0c;并返回 ASP.NET 网页的呈现 HTML。
您可以自定义 IIS&＃xff0c;以指定扩展名与 ISAPI 扩展的映射关系。图 1 显示了 Internet Information Services 管理工具的“应用程序配置”对话框。请注意&＃xff0c;与 ASP.NET 有关的扩展名&＃xff08;.aspx、ascx、config、asmx、rem、cs、vb 及其他&＃xff09;均已映射到 aspnet_isapi.dll ISAPI 扩展。
图 1. 已配置的文件扩展名映射
讨论 IIS 如何管理传入请求稍稍超出了本文范围。但是可以在 Michele Leroux Bustamante 的文章 Inside IIS and ASP.NET 中找到对此内容的深入讨论。ASP.NET 引擎仅处理那些扩展名已明确映射至 IIS 中的 aspnet_isapi.dll 的传入 Web 请求&＃xff0c;了解这一点非常重要。
使用 ISAPI 筛选器检查请求IIS 除了可以将传入 Web 请求的文件扩展名映射到相应的 ISAPI 扩展之外&＃xff0c;还将执行许多其他任务。例如&＃xff0c;IIS 将尝试对发出请求的用户进行身份验证&＃xff0c;并确定通过身份验证的用户是否有权限访问被请求的文件。在处理请求的有效期内&＃xff0c;IIS 将经历几个状态。在每个状态下&＃xff0c;IIS 都将引发可以使用 ISAPI 筛选器以编程方式进行处理的事件。
与 ISAPI 扩展一样&＃xff0c;ISAPI 筛选器是在 Web 服务器上安装的非托管代码块。ISAPI 扩展被设计为可以响应针对特定文件类型的请求。另一方面&＃xff0c;ISAPI 筛选器还包含可以对 IIS 引发的事件进行响应的代码。ISAPI 筛选器可以截取甚至修改传入和传出的数据。ISAPI 筛选器可以应用于很多方面&＃xff0c;包括&＃xff1a;
- 身份验证和授权。
- 记录和监视。
- HTTP 压缩。
- URL 重写。
请求进入 ASP.NET 引擎时将会发生什么情况在 ASP.NET 之前&＃xff0c;需要使用 ISAPI 筛选器来实现 IIS Web 服务器上的 URL 重写。由于 ASP.NET 引擎与 IIS 非常相似&＃xff0c;因此可以使用 ASP.NET 进行 URL 重写。存在相似之处的原因在于 ASP.NET 引擎可以实现以下功能&＃xff1a;
- 在处理请求时可以引发事件。
- 允许任意数量的 HTTP 模块处理所引发的事件&＃xff0c;这与 IIS 的 ISAPI 筛选器相似。
- 将呈现被请求资源这项任务委托给 HTTP 处理程序&＃xff0c;该处理程序与 IIS 的 ISAPI 扩展相似。
正如上一部分所讨论的&＃xff0c;可以创建 ISAPI 筛选器以响应 IIS 引发的事件。同样&＃xff0c;ASP.NET 提供了 HTTP 模块&＃xff0c;该模块可以响应由 ASP.NET 引擎引发的事件。可以将 ASP.NET Web 应用程序配置为具有多个 HTTP 模块。对于由 ASP.NET 引擎处理的每个请求&＃xff0c;将初始化每个已配置的 HTTP 模块&＃xff0c;并允许将事件处理程序绑定到处理请求期间所引发的事件。请注意&＃xff0c;对每个请求均使用了许多内置 HTTP 模块。其中的一个内置 HTTP 模块是 FormsAuthenticationModule&＃xff0c;该模块首先检查是否使用了窗体身份验证&＃xff0c;如果使用&＃xff0c;将检查是否对用户进行了身份验证。如果没有使用&＃xff0c;会自动将用户重定向到指定的登录页面。
如上所述&＃xff0c;通过使用 IIS&＃xff0c;传入请求将最终发送给 ISAPI 扩展&＃xff0c;而 ISAPI 扩展的任务是返回特定请求的数据。例如&＃xff0c;在请求传统的 ASP 网页时&＃xff0c;IIS 将请求传递给 asp.dll ISAPI 扩展&＃xff0c;该扩展的任务是返回被请求的 ASP 页面的 HTML 标记。ASP.NET 引擎使用相似的方法。初始化 HTTP 模块后&＃xff0c;ASP.NET 引擎的下一项任务是确定应由哪个 HTTP 处理程序来处理请求。
所有通过 ASP.NET 引擎传递的请求最终都将到达 HTTP 处理程序或 HTTP 处理程序工厂&＃xff08;HTTP 处理程序工厂仅返回 HTTP 处理程序的实例&＃xff0c;然后使用该实例来处理请求&＃xff09;。最终的 HTTP 处理程序将返回响应&＃xff0c;即呈现被请求的资源。此响应将被发送回 IIS&＃xff0c;然后 IIS 将响应返回给提出请求的用户。
ASP.NET 包括许多内置的 HTTP 处理程序。例如&＃xff0c;PageHandlerFactory 用于呈现 ASP.NET 网页。WebServiceHandlerFactory 用于呈现 ASP.NET Web 服务的响应 SOAP 信封。TraceHandler 将向 trace.axd 呈现请求的 HTML 标记。
图 2 描述了如何处理对 ASP.NET 资源的请求。首先&＃xff0c;IIS 接收到请求&＃xff0c;并将请求调度给 aspnet_isapi.dll。接下来&＃xff0c;ASP.NET 引擎对已配置的 HTTP 模块进行初始化。最后将调用正确的 HTTP 处理程序&＃xff0c;并呈现被请求的资源&＃xff0c;将所生成的标记返回给 IIS 和请求客户端。
图 2. IIS 和 ASP.NET 正在处理请求
京公网安备 11010802041100号