WCF 中的自定义 JSON IErrorHandler 返回 StatusCode 200/504,而应返回 400

发布于 2024-09-15 02:11:59 字数 675 浏览 4 评论 0原文

我有一个 WCF 服务,除其他绑定外,它还使用 WebHttpBinding 进行 JSON 输入/结果。

我制作了一个自定义 IErrorHandler 实现,以便能够在出现问题时将 StatusCode 设置为 400,并返回一条可理解的 JSON 消息。这是您随处可见的直接实现(此处描述的好方法)。

我的问题是:当我使用 Visual Studio Web 开发服务器(Cassini)在本地测试它时,它工作得很好。但是,当我将其部署到我的测试服务器(带有 IIS 和其他所有标准配置的 Windows 2008)时,它不起作用。

当我调用它并使用 Firebug 进行调试时,我得到 HttpStatusCode 200 作为返回,但没有响应文本。使用 Fiddler,我得到 HttpStatusCode 504 并且根本没有返回。然而,我期望的行为(以及本地发生的情况)是调用带有responseText集的ajax调用的错误回调。

我远程调试了一下,一切看起来都很好。执行管道正常,所有类都被调用,因为它们应该就像它们在本地一样,只是它不起作用。

有什么建议吗?我几乎没有选择来解决这个问题。

多谢!

I have a WCF service that among other bindings also uses WebHttpBinding for JSON inputs/results.

I made a custom IErrorHandler implementation in order to be able to set the StatusCode to 400 when something goes wrong and also return a JSON understandable message. It´s the straight implementation that you can find everywhere (nice way described here).

My problem is: when I test it locally using Visual Studio Web Development Server (Cassini) it works perfectly. However, when I deploy it to my test server (Windows 2008 with standard config for IIS and everything else) it does not work.

When I call it and debug with Firebug I get a HttpStatusCode 200 as a return and no response text. With Fiddler I get a HttpStatusCode 504 and no return at all. However, the behavior I expected (and what happens locally) is a call to the error callback of the ajax call with the responseText set.

I debugged it remotely and everything looks just fine. The execution pipeline is OK and all the classes are called as they should be just like they are locally, except it does not work.

Any suggestions? I´m pretty much out of options here to figure this out.

Thanks a lot!

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

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

发布评论

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

评论(2

好久不见√ 2024-09-22 02:11:59

如果 firebug 和 fiddler 给出不同的结果,如果您直接 telnet 到它并执行请求(类似:),

    GET /VirtualDirectoryAndGetData HTTP/1.1
    HOST: example.com
    [carriage return]

如果您以某种方式获得奇怪的标头/格式,我不会感到惊讶(解释为什么 firebug/fiddler不同意)

另一件事要测试的是发布到您的开发机器,看看它是否是特定于机器的问题或服务器与开发网络服务器的问题。

如果它发生在 VS 之外的任何地方,您也可以尝试注释掉您设置的行,

  rmp.StatusCode = System.Net.HttpStatusCode.BadRequest;
  rmp.StatusDescription = "Bad request";

这可能表明它是响应代码问题还是错误处理程序问题。

如果您可以编辑您的问题以包含结果(删除敏感信息),我们将看看是否可以进一步追踪它。

编辑:再次查看问题后,很可能服务器在发送任何响应之前出错。 FF 默认情况下可能采用 200,而 ie 可能采用 504(网关超时)。这完全是猜测,但也是有可能的。您在事件日志中看到任何内容吗?

if firebug and fiddler are giving different results, what happens if you telnet to it directly and perform a request (Something like:)

    GET /VirtualDirectoryAndGetData HTTP/1.1
    HOST: example.com
    [carriage return]

It wouldn't surprise me if you're somehow getting odd headers/formatting back (to explain why firebug/fiddler disagree)

Another thing to test would be publishing to your dev machine to see if it's a machine-specific issue or a server vs dev webserver issue.

If it's happening anywhere outside VS, you might also try commenting out the lines where you set

  rmp.StatusCode = System.Net.HttpStatusCode.BadRequest;
  rmp.StatusDescription = "Bad request";

This may indicate whether it's a response code issue or an error handler issue.

If you can edit your question to include the results (with sensitive info removed), we'll see if we can track it down further.

Edit: after looking at the question again, it may well be that the server is erroring before it can send ANY response. FF might assume 200 by default, whereas ie might assume 504 (Gateway Timeout). This is total speculation but is possible. Do you see anything in the event logs?

耳根太软 2024-09-22 02:11:59

我有一个类似的问题,我能够解决。查看 IIS 设置。有关我如何克服该问题的详细信息,请参阅这篇文章:当 HTTP 状态代码为 401 Unauthorized 时,IErrorHandler 返回错误的消息正文

I had a similar issue which I was able to solve. Take a look at the IIS settings. Details on how I overcame the issue are in this post: IErrorHandler returning wrong message body when HTTP status code is 401 Unauthorized

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