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

Question

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

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

我创建了一个测试控制器，具有相同的界面，但没有逻辑，只有响应 "succes"！在此界面上，请求也会失败（相同的行为）。两个控制器都使用 Newtonsoft(10.0.3) 进行反序列化。

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

控制器代码：

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。我创建了一个新控制器，其中只有 returns 请求：

 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 发送 "Large" 请求时，它丢失了。但是当它前面有一个小请求时，两个请求都会被接受。所以看起来大请求的连接设置失败了。

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

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

而且客户端是邮递员，使用证书。有什么想法吗？

Answer 1

据我了解，您的请求可能会达到 IIS 限制。由于 maxAllowedContentLength 属性 requestLimits 描述如下：

Specifies the maximum length of content in a request, in bytes.

The default value is 30000000.

我假设您可以增加 maxAllowedContentLength，如下所示：

<security>
  <requestFiltering>
    <!-- Measured in Bytes -->
    <requestLimits maxAllowedContentLength="1073741824" />  <!-- 1 GB, Byte in size, up to 2GB-->
  </requestFiltering>
</security>

我建议您检查您的请求正文大小并尝试增加 maxAllowedContentLength 以缩小此问题的范围。而且，我发现了一个issue talking about request size limit in ASP.NET Core 2.0.0. Also, here is a similar issue, you could refer to here.

Answer 2

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

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

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

（下面我把link的文字复制过来保存，也因为实在是太难找了）：

概览

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

问题

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

的附加数据

分辨率

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

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

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

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

总结 强调文本虽然这已经成为十多年的问题，但它从未在任何 public 面向文档中找到解决方法（很可能是因为 Expect header 是最好的为我们练习 old-school 类型和较新的 classes 和库都默认包含此 header）。

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

Web API in Azure connection setup fails with large requests

c#

ssl

azure

asp.net-web-api

asp.net-core-webapi