4.0 升级后,404 错误的 HttpHandler 停止工作

发布于 2024-10-17 18:38:56 字数 1136 浏览 2 评论 0原文

我有一个 HttpHandler 来处理 404 错误,这是我几年前实现的作为 url 路由的一种方式。如果请求映射到有效页面,它将重定向到该页面。否则,它会返回 404。(我知道我应该开始使用 asp.net 4.0 的新路由功能,但这需要一些时间。我需要尽快使其正常工作。)

在 IIS6 中,我已将 404 错误映射到“/404.ashx”。在 web.config 中,自定义错误设置如下:

<customErrors mode="On" defaultRedirect="error.aspx">
  <error statusCode="404" redirect="/404.ashx"/>
</customErrors>

和 http 处理程序:

<httpHandlers>
  <add verb="GET" path="404.ashx" type="myNamespace.PageNotFoundHandler,myAssemblyName"/>
</httpHandlers>

这已经工作多年了 - 一旦我将站点更改为使用 asp.net 4.0,它就停止工作。所有内容都针对 4.0 进行了重新编译,并且没有任何代码更改。

现在,当我点击这些曾经有效的 URL 之一时,我会看到一个带有 404 错误代码的空白页面。如果删除 IIS 404 错误映射,我会得到常规的旧 404 页面。看来 httphandler 没有被调用。

我有其他工作正常的 http 处理程序。

我已将注册表中的 EnableExtensionlessUrls 项设置为 0,如建议的 此处 和其他地方。

我想一定是我错过了一些配置设置或类似的东西。当然,这只是我的生产服务器上的问题,因此我无法在调试器中运行它来查看发生了什么。如果没有什么简单的事情发生,我会在我的系统中插入一些额外的日志记录来帮助追踪它。

关于我还可以检查什么的任何想法?

I have an HttpHandler which takes care of 404 errors, which I implemented years ago as a way of doing url routing. If the request maps to a valid page, it redirects to that page. Otherwise, it returns a 404. (I know I should start using the new routing feature of asp.net 4.0, but that will take some time. I need to get this working asap.)

In IIS6, I have mapped the 404 error to "/404.ashx". In the web.config, custom errors are set up like so:

<customErrors mode="On" defaultRedirect="error.aspx">
  <error statusCode="404" redirect="/404.ashx"/>
</customErrors>

and the http handler:

<httpHandlers>
  <add verb="GET" path="404.ashx" type="myNamespace.PageNotFoundHandler,myAssemblyName"/>
</httpHandlers>

This has been working for years - it stopped working as soon as I changed the site to use asp.net 4.0. Everything was recompiled for 4.0, and there were no code changes.

Now, when I hit one of these urls that used to work, I get a blank page with a 404 error code. If I remove the IIS 404 error mapping, I get a regular old 404 page. It seems that the httphandler is not being called.

I have other http handler which are working fine.

I have set the EnableExtensionlessUrls item in the registry to 0, as suggested here and other places.

I figure there must be some configuration setting I missed or something like that. Naturally, this is a problem only on my production server, so I can't run it in the debugger to see what is happening. If nothing easy comes up, I will insert some extra logging in my system to help track it down.

Any ideas on what I else can check?

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

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

发布评论

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

评论(2

猫七 2024-10-24 18:38:56

您可以检查一下是否是 Verb 属性,也许应该是 POST 或 *?

另一个快速修复方法是将代码添加到全局类中的 Application_Error 事件处理程序中,如下所示。

for (Ex = Server.GetLastError(); Ex != null; Ex = Ex.InnerException)
{
   if (Ex is HttpException && ((HttpException)Ex).GetHttpCode() == 404 && Context != null)
   {
       Context.Server.Transfer("~/404.ashx");
       return;
   }
}

这将消除对 Web 配置内部任何配置设置的需要,但它的行为可能与您当前使用的有所不同,因为它会采用当前请求的页面/文件的页面标识,而不是沿着查询中的路径传递字符串作为处理正常的 IIS 404 自定义错误页面。

You might check to see if it's the Verb attribute, maybe it should be POST or *?

Another quick fix would be to add code to your Application_Error event handler in your global class like so.

for (Ex = Server.GetLastError(); Ex != null; Ex = Ex.InnerException)
{
   if (Ex is HttpException && ((HttpException)Ex).GetHttpCode() == 404 && Context != null)
   {
       Context.Server.Transfer("~/404.ashx");
       return;
   }
}

This would remove the need for any configuration settings inside of your web config, but it might behave somewhat differently than what you currently use as it would take on the page identity of the currently requested page/file instead of passing along the path in a query string as the normal IIS 404 custom error page is handled.

携余温的黄昏 2024-10-24 18:38:56

从默认应用程序池更改为经典应用程序池为我解决了这个问题。

Changing from the default app pool to the classic one fixed it for me.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文