Silverlight 4 和 ASP.NET 的 WCF 错误异常

Question

我有一组 WCF 服务，到目前为止我一直在使用 ASP.NET MVC 应用程序。当服务器发现客户端提交的内容存在问题时，这些服务操作会返回 FaultException。例如：

if(string.IsNullOrEmpty(request.Name))
     throw new FaultException<ValidationDictionary>(new ValidationDictionary());

这在我的 ASP.NET 应用程序中效果很好

catch(FaultException<ValidationDictionary> fault)
{
  //  Happy error handling.
}

但是，使用 Silverlight，这一切都失败了。服务器返回带有错误异常的 500 状态代码（如预期的那样），但对于 Silverlight 来说，这看起来像是一个 duff 响应。

以下 MS 文章指出了一个（丑陋的）解决方法：http://msdn.microsoft.com/en-us/library/ee844556%28v=vs.95%29.aspx 此解决方法使服务传输 200 个状态代码，即使存在 FaultException，以便 Silverlight 客户端可以获取它们。但这会弄乱我服务的“普通”客户端（我的 ASP.NET 应用程序，其他用户）。

但是，服务的重点是与您的客户分开。我仍然希望我的服务返回 500 个状态代码，以便我的 ASP.NET 应用程序可以检测到 FaultExceptions 并处理它们。但我也希望 Silverlight 也能够处理它们。

以前有人反对过这个吗？

Answer 1

我们正在使用丑陋的 500 到 200 转换器端点行为（您提供的链接中的选项之一），它在 Silverlight 中工作得非常好。一个快速的 Windows 窗体客户端似乎也明白，虽然响应代码是 200（好的），但我仍然看到 e.Error 正确填充。 您使用的客户端（ASP.NET）是否真的存在 200 与 500 的技术问题？如果不是，有什么问题？

直到最近，我还在 Silverlight 中使用了备用 HTTP 堆栈（该 MSDN 文章中的其他选项）。使用它修复了很多事情（如果我没记错的话，包括返回的错误）。我们之所以使用它，是因为它提供了一致的 NTLM/Negotiate 身份验证，而与浏览器无关。我不得不停止使用它，因为它被认为缺乏 HTTP 压缩是一个交易破坏者。这将使服务保持不变（错误为 500 秒）。