IIS 8.5 400 错误请求答案

【问题标题】：IIS 8.5 400 Bad RequestIIS 8.5 400 错误请求
【发布时间】：2018-12-05 16:34:34
【问题描述】：

我在使用 IIS 8.5 上托管的 ASP.Net Core Web Api 应用程序时遇到了一些困难。 IIS 8.5 为特定的发布请求返回 400 状态代码。

错误请求由托管在具有不同端口的同一域上的 Web 应用程序执行。 API 配置为处理 cors，错误请求的预检已成功完成。

我注意到一件奇怪的事情： Api 部署时包含 Swagger UI。因此，我尝试使用 Swagger UI 重现该错误。但在这种情况下，请求是成功的。两个请求的正文和 url 完全相同，除了请求来源之外，标头没有明显差异。

看起来请求根本没有被 Api 处理（在这种情况下，我应该在我们的日志文件中看到某事），所以我很确定错误发生在 IIS 本身的某个地方。

我已经调查了 httperr.log 文件。它包含请求失败时的流水线：

2018-12-05 15:38:36 192.168.100.132 62121 192.168.100.173 1142 HTTP/1.1 POST /api/some/request/path 400 13 BadRequest myServicePool

我希望此文件包含有关错误原因的更多详细信息。我想知道“BadRequest”前面的“13”有什么特殊含义吗？

根据提供的信息，有没有人知道为什么会发生此错误？我真的不这么认为。但是，如果有人可以提示我在哪里搜索有关错误原因的更多详细信息，我将非常高兴。如果您需要更多详细信息，请告诉我。

【问题讨论】：

13 可能是 sc-win32-status (-> 日志文件中的标题)
或 HTTP 子状态... IIS 日志仅包含有关流量的一些基本信息，而不包含 IIS 内部发生的情况，事件日志说明正在发生什么？您还可以尝试启用失败的请求跟踪，它提供了 IIS 管道的一些全面详细信息，尤其是当您猜测 POST 未到达应用程序时。
HTTP 错误日志将无法为您提供更多提示。但是您可以在 Wireshark 等工具中捕获有问题的 HTTP 请求，并根据 HTTP RFC 文档分析其详细信息。请注意，在大多数情况下，这应该在字节级别完成，而不仅仅是字符串。
看起来13不是子状态。至少它没有在微软文档中列为可能的子状态：support.microsoft.com/de-de/help/943891/…

标签： asp.net .net .net-core iis-8

【解决方案1】：

如果我们可以在您的代码中提供有关您如何发送请求的示例代码，那就更好了。

但是，根据给定的事实，我认为问题出在请求正文的内容中。即使是招摇的请求和你发送的请求看起来完全一样，它应该在某些方面有所不同。

您使用的是 JSON 转换器吗？如果您使用 JSON 转换器，并且如果您将 .NET 模型序列化为 JSON 字符串并附加到请求中，请确保您使用 Camel Case 对其进行格式化。

因为默认情况下它可能只是将 .NET 模型转换为 Pascal 案例。

示例

我将使用 Newtonsoft JSON 库对此进行详细说明。

.NET 模型序列化而不指定格式

var businessLeadJson = JsonConvert.SerializeObject(ObjectA);

转换结果 - {"Company":"sample","ContactName":"contact 1"}

.NET模型通过指定格式序列化

var businessLeadJson = JsonConvert.SerializeObject(businessLead, new 
      JsonSerializerSettings() { ContractResolver = new CamelCasePropertyNamesContractResolver() });

转换结果 - {"company":"sample","contactName":"contact 1"}

请注意 JSON 字符串中属性名称的大小写。第一个结果中的第一个字母是大写的。

因此，我建议您通过指定格式尝试序列化作为有效负载（请求正文）附加的对象，因为 REST API 期望 JSON 字符串格式正确。

请在序列化请求正文的对象时指定骆驼大小写格式。

祝你好运..！

【讨论】：

HTTP 错误日志是由 HTTP.sys 编写的，所以这样的 400 意味着基本的 HTTP 协议违规，而不是 JSON 级别的违规。
请求是由 javascript 应用程序发出的。我使用普通的 javascript 对象作为请求正文。所以我确定问题不在于 json 正文。我什至无法在我们的开发系统上重现该问题，它只发生在我们客户的生产系统上。

【解决方案2】：

我刚刚偶然设法重现了这个错误。

问题是，如果用户尚未登录，应用程序会发送一个空的 Authorization-Header。

似乎在某些配置/IIS 版本上会导致错误请求，或者系统之间存在什么差异，而在某些情况下则没有问题。

【讨论】：