IIS7 ASPX 404 错误页面/Server.Transfer 和相对路径问题

发布于 2024-10-13 22:40:47 字数 1093 浏览 8 评论 0原文

我正在尝试实现一个通用的 .NET 3.5 ASPX 404 错误页面,该页面可以处理 IIS 7(经典模式)中的“未找到”请求以及代码中引发的 404 HttpException。我正在避免 customErrors,因为我想要真正的 404 返回代码而不是重定向。

为此,我在 web.config 的 system.webserver 部分添加了以下内容:

<httpErrors>
  <remove statusCode="404" subStatusCode="-1" />
  <error statusCode="404" subStatusCode="-1" path="/virtualdir/errorpages/error404.aspx" responseMode="ExecuteURL" prefixLanguageFilePath="" />
</httpErrors>

我还在 Global.asax Application_Error 中添加了 Server.Transfer 调用,以捕获代码中引发的异常。

问题在于,相对路径(例如 app_themes 以及任何链接)是相对于错误页面而不是原始请求的 URL 计算的。

因此,对 /virtualdir/fail/fail/fail/fail/fail.html 的请求尝试在 /virtualdir/fail/fail/fail/app_themes 中查找 app_themes。

我认为可能有一个涉及 Request.RawUrl 的解决方案,但我还没有找到。

我确信我不是第一个遇到这个问题的人,但这次我的 Google Fu 让我失望了。

编辑

我做了一些调查,在不同的情况下,错误的 URL 要么维护在 Request.URL 属性中(需要),要么附加到错误页面 URL 作为查询字符串的一部分,格式为 (/virtualdir/errorpages/error404. aspx?404;http://host/virtualdir/fail/fail/fail/fail/fail.html)。

在我的 IIS 6 本地机器上,ASPX 错误以前一种方式起作用,在 IIS 7 测试盒上,ASPX 页面使用后一种方法。

I am trying to implement a universal .NET 3.5 ASPX 404 error page that handles both "not found" requests in IIS 7 (classic mode) as well as 404 HttpExceptions thrown in code. I am avoiding customErrors as I want a true 404 return code rather than a redirect.

To do this I have added the following in the system.webserver section of web.config:

<httpErrors>
  <remove statusCode="404" subStatusCode="-1" />
  <error statusCode="404" subStatusCode="-1" path="/virtualdir/errorpages/error404.aspx" responseMode="ExecuteURL" prefixLanguageFilePath="" />
</httpErrors>

I have also added a Server.Transfer call in Global.asax Application_Error to capture exceptions thrown in code.

The problem is that the relative paths (such as app_themes as well as any links) are calculated relative to the error page rather than the URL of the original request.

So a request for /virtualdir/fail/fail/fail/fail/fail.html tries to find app_themes at /virtualdir/fail/fail/fail/app_themes.

I think there might be a solution involving Request.RawUrl but I haven't found it yet.

I'm sure I can't be the first person to have this problem but my Google Fu has let me down this time.

EDIT

I've done some investigation and under different circumstances the faulting URL is either maintained in the Request.URL property (desired) or appended to the error page URL as part of the query string in the format (/virtualdir/errorpages/error404.aspx?404;http://host/virtualdir/fail/fail/fail/fail/fail.html).

On my IIS 6 local box, ASPX errors act in the former manner, on the IIS 7 test box, ASPX pages use the latter method.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

大海や 2024-10-20 22:40:47

这是我的解决方案:

string queryString = Request.Url.Query;
if (queryString.StartsWith("?404;"))
{
    try
    {
        Uri newUri = new Uri(queryString.Replace("?404;", String.Empty));

        HttpContext.Current.RewritePath(newUri.PathAndQuery);
    }
    catch (UriFormatException)
    {
        // Do nothing, the query string is malformed.
    }
}

不过感觉有点脏。我对声明式解决方案抱有希望。

This is my solution:

string queryString = Request.Url.Query;
if (queryString.StartsWith("?404;"))
{
    try
    {
        Uri newUri = new Uri(queryString.Replace("?404;", String.Empty));

        HttpContext.Current.RewritePath(newUri.PathAndQuery);
    }
    catch (UriFormatException)
    {
        // Do nothing, the query string is malformed.
    }
}

It feels a bit dirty though. I am holding out hope for a declarative solution.

初雪 2024-10-20 22:40:47

我现在无法测试它,但是您是否尝试过使用波浪号使 URL 与应用程序相关?例如:

<error statusCode="404" subStatusCode="-1" path="~/errorpages/error404.aspx" responseMode="ExecuteURL" prefixLanguageFilePath="" />

I can't test it out right now, but have you tried using the tilde to make the URLs app-relative? eg:

<error statusCode="404" subStatusCode="-1" path="~/errorpages/error404.aspx" responseMode="ExecuteURL" prefixLanguageFilePath="" />
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文