c# - Azure 连接设置中的 Web API 因大请求而失败

Question

我在 AspNetCore 中有一个 WebApi，它部署在 Azure 应用服务上。 WebApi 只能用于发布对象数组。该对象包含很多属性(100+)和 3 个对象数组。 (它代表一座建筑物)。每个对象数组可以包含 300 多个对象。

当我在 Visual studio 2017 (15.4.1) 中调试时，api 工作正常并接受所有请求。当部署到 Azure 时，它​​接受大多数请求。但有一些消失在虚空中。我的意思是没有任何回应。出错的请求在其中一个数组中有很多对象。通过将对象数量减少到一定数量，请求被接受。如前所述，在 visual studio 中，所有请求都被接受。数据发送稳定。

我创建了一个测试 Controller ，具有相同的界面，但没有逻辑，只有响应“成功”!在此界面上，请求也会失败(相同的行为)。两个 Controller 都使用 Newtonsoft(10.0.3) 进行反序列化。

是什么导致了这些请求的行为差异？

Controller 代码:

public class TestController : Controller
{       
    [HttpPost]
    [RequireHttps]
    public IActionResult Post([FromBody] Buildings Buildings)
    {
        enumActionResult status = enumActionResult.success;
        try
        {   
            if (Buildings == null)
                throw new Exception("No valid buildings posted!");

            if (Buildings.items == null)
                throw new Exception("No valid building items posted!");

            if (Buildings.items.Count == 0)
                throw new Exception("Zero building items posted!");


            return Json(new response() { status = status.ToString(), Buildings = list
        }

        catch (Exception ex)
        {
            return Json(new ErrorResponseFormat() { message = ex.Message, status = enumActionResult.error, data = new ErrorResponse(ex) });
        }
    }
}

更新(2017-12-19):问题仍然存在，但已缩小到 SSL。我创建了一个新的 Controller ，它只返回请求:

 public class EchoController : Controller
    {
        [HttpPost]           
        public IActionResult Post()
        {
            return new FileStreamResult(Request.Body, Request.ContentType);
        }
    }

如果我在失败的 URL 上使用 https 发出请求，并且我在 http URL 上发出完全相同的请求，它是成功的。这与我从调试器获得的行为相同，因为它仅使用 http。因此，问题似乎出在 http 与 https 之间，而不是调试器和 azure 云环境之间的差异。

与此同时，我在配置中实现了(按照 Bruce Chen 的建议):

    <system.webServer>
        <security>
          <requestFiltering>
            <!-- Measured in Bytes -->
            <requestLimits maxAllowedContentLength="4000000000" maxQueryString="100000000"/>        
            <!-- 1 GB, Byte in size, up to 2GB-->
          </requestFiltering>   
         <access sslFlags="Ssl, SslRequireCert"/>        
        </security>
      </system.webServer>

并升级到 .NET 4.6.2。此时仍然没有解决方案，但问题似乎缩小了。

更新(20-12-2017):我发现以下有趣的事情:当我向 (https) api 发送“大”请求时，它丢失了。但是当它前面有一个小请求时，两个请求都会被接受。所以看起来大请求的连接设置失败了。

webapi 使用自定义域、https 和 IP 白名单。客户端需要使用客户端证书进行身份验证。完整的 Webapi 配置(是的，我删除了之前的 requestLimits 条目):

    configuration>
  <connectionStrings>
    ...
  </connectionStrings>
  <system.webServer>
    <security>      
       <access sslFlags="Ssl, SslRequireCert"/>   
    </security>
  </system.webServer>
   <runtime>
      <gcServer enabled="true"/>
   </runtime> 
</configuration>

而客户端是 postman ，使用证书。有什么想法吗？

Answer 1

终于在一个msdn博客中找到了awnser。

https://blogs.msdn.microsoft.com/waws/2017/04/03/posting-a-large-file-can-fail-if-you-enable-client-certificates/

我们的解决方案是第一个选项，因为客户端不是 .NET 应用程序。感觉像是作弊，但它确实有效。

(下面我复制了链接中的文字，为了保存，也因为实在是太难找了):

概览

如果您需要客户端证书和 POST 或 PUT 大量数据，您的请求可能会失败。这个问题已经与 IIS 一起存在了至少 10 年(这现在也适用于 Windows 平台上的 Azure App Services，因为它使用 IIS)。这方面的信息不多，所以这篇博客应该有助于澄清这个问题。解决方案非常简单!

问题

HTTPS (TCP) 的底层协议(protocol)会将大型数据包分解为多个帧。通常这对应用程序来说不是问题并且对客户端和服务器都是透明的。一些需要客户端证书的应用程序可能会因此而遇到问题……当初始数据被推送到多个帧中并且 IIS 服务器在继续之前需要客户端证书。当数据开始从客户端流向服务器(在 Server Hello 的初始 SSL 握手之后)并且发送第一个数据包时，您实际上可以在网络跟踪中看到这一点。服务器回复是客户端证书请求的开始，然后来自客户端的下一个数据包包含更多数据。此时服务器抛出一个错误，因为它希望传输的下一个数据是客户端证书。这不会发生在较小的数据包上，因为对 POST 或 PUT 的整个请求已经完成，服务器接下来得到的是客户端证书握手，而不是来自 PUSH 或 PUT 的额外数据

分辨率

要解决此问题，您只需使用以下两种技术之一:

• 首先使用 HEAD 请求建立连接
• 为请求设置 Expect: 100-continue header

选项 1:首先使用 HEAD 请求建立连接我不像下一个选项那样喜欢这个选项，但它已经成功运行。概念是 HEAD 请求根本没有数据，并且可以毫无问题地建立 SSL 连接。然后你依靠你的 HTTP 库的底层实现来重新使用这个连接(大多数情况下)，没有进一步的 SSL 握手，你避免了这个问题

选项 2:为请求设置 Expect: 100-continue header 这是最好的选择。根据 RFC，这就是它实际存在的原因!简而言之，一旦服务器准备好接受请求(在本例中为 SSL 协商之后)，您将返回 100 状态并可以继续 POST 或 PUT 您的数据。所有 HTTP 客户端库都实现了这一点(因为它是 RFC 的一部分)所以这很简单并且可以保证工作。下面是在 .NET 中使用 HttpWebRequest(或任何这些衍生产品)时进行设置的示例。在代码中发出任何 HTTP 请求之前，您在代码中执行一次此操作(例如在 global.asax 或 Startup.cs 中ServicePointManager.Expect100Continue = true;请参阅:ServicePointManager.Expect100Continue 属性如果您使用的是较新的 HttpClient 类，则会自动添加它(出于显而易见的原因)。

总结强调文本虽然这已经成为十多年的问题，但它从未在任何面向公众的文档中找到它的方式(很可能是因为 Expect header 是我们老派类型和较新类的最佳实践默认情况下，所有库都包含此 header )。