可以执行 URL 重写的一个安全位置是在 beginrequest 事件中。也就是说，如果 URL 需要重写，该操作将在任何一个内置 HTTP 模块运行后执行。使用窗体身份验证时，这种方法存在一定的缺陷。如果您以前使用过窗体身份验证，您会了解当用户访问受限资源时，他们将被自动重定向到指定的登录页面。成功登录后，用户将被返回到他们第一次尝试访问的页面。
如果在 beginrequest 或 authenticaterequest 事件中执行 URL 重写，登录页面（提交后）将把用户重定向到重写后的页面上。也就是说，假设用户在其浏览窗口中键入了 /people/ScottMitchell.aspx，此地址将被重写为 /info/employee.aspx?empID=1001。如果将 Web 应用程序配置为使用窗体身份验证，当用户第一次访问 /people/ScottMitchell.aspx 时，首先，URL 将被重写为 /info/employee.aspx?empID=1001;接下来，formsauthenticationmodule 将运行，并将用户重定向到登录页面（如果需要）。但是，用户在成功登录后将被发送到 /info/employee.aspx?empID=1001，因为当 formsauthenticationmodule 运行后，此 URL 即是请求的 URL。
同样，在 beginrequest 或 authenticaterequest 事件中执行重写时，urlauthorizationmodule 看到的将是重写后的 URL。也就是说，如果您在 Web.config 文件中使用 <location> 元素来为特定的 URL 指定授权，则必须引用重写后的 URL。
要解决这些细微问题，您可以决定在 authorizerequest 事件中执行 URL 重写。此方法解决了 URL 授权和窗体身份验证的一些问题，但同时也产生了新的问题：文件授权无法工作。使用 Windows 身份验证时，fileauthorizationmodule 将检查以确保通过身份验证的用户具有访问特定 ASP.NET 页面的相应权限。
假设一组用户对 C:\Inetput\wwwroot\info\employee.aspx 没有 Windows 级别的文件访问权限，并要尝试访问 /info/employee.aspx?empID=1001，他们将会收到授权错误消息。但是，如果我们将 URL 重写移到 authenticaterequest 事件中，当 fileauthorizationmodule 检查安全设置时，仍然认为被请求的文件是 people/ScottMitchell.aspx，因为该 URL 必须被重写。因此，文件授权检查将通过，允许此用户查看重写后的 URL /info/employee.aspx?empID=1001 的内容。
那么，应该何时在 HTTP 模块中执行 URL 重写？这取决于要使用的身份验证类型。如果不想使用任何身份验证，则无论 URL 重写发生在 beginrequest、authenticaterequest 还是 authorizerequest 中都没有什么关系。如果要使用窗体身份验证而不使用 Windows 身份验证，请将 URL 重写放在 authorizerequest 事件处理程序中执行。最后，如果要使用 Windows 身份验证，请在 beginrequest 或 authenticaterequest 事件进行过程中安排 URL 重写。
也可以由 HTTP 处理程序或 HTTP 处理程序工厂执行 URL 重写。如上所述，HTTP 处理程序是负责生成特定类型请求的内容的类;HTTP 处理程序工厂是负责返回 HTTP 处理程序实例的类，该实例可以生成特定类型请求的内容。
在本文中，我们将对如何为 ASP.NET 网页创建 URL 重写 HTTP 处理程序工厂进行讨论。HTTP 处理程序工厂必须实现 ihttphandlerfactory 接口，此接口包括 GetHandler() 方法。初始化相应的 HTTP 模块后，ASP.NET 引擎将确定为给定的请求调用哪个 HTTP 处理程序或 HTTP 处理程序工厂。如果要调用 HTTP 处理程序工厂，ASP.NET 引擎将为 Web 请求调用传入 httpcontext 的 HTTP 处理程序工厂的 gethandler() 方法，以及一些其他信息。然后，HTTP 处理程序工厂必须返回一个对象，该对象将实
