關於.Net Core下因客戶端主動取消導致Request請求[FromBody]模型綁定讀取異常BadHttpRequestException

　　最近我們的接口老是會出現BadHttpRequestException異常，但是手動查看報錯的頁面卻一點問題沒有，很奇怪，后來仔細研究這個異常。異常原因其實根據異常對象本身就已經能分析出來了（由於第一次遇到不清楚怎么造成的，尷尬），就是由於無法正常讀取Http-Request請求對象里的內容導致的異常！但是什么情況下會導致這個情況，不得而知。  后來百度其他朋友的文章，終於了解到發生當前錯誤的原因：

　　是由於當請求出現並發，而請求的線程池又不夠使用，前面的請求阻塞后面的請求時，后面的請求強制取消后就會導致后面的請求在被接收程序處理Request內容時發生異常，即：BadHttpRequestException

先看下接口是怎么接收的：

[HttpPost]
public async Task<IActionResult> PPIFrameInit([FromBody] PaypalClientRequest parames)
{
      //...  
}

很顯然，接口采用的是自動綁定Model模型Request-Body的方式，那么如果按照上述請求就很容易發生下面的異常了。

異常內容如下：

ClientIP：157.185.158.160 
URL：http://www.coowigsby.com/ajax/paydd/PPIFrameInit 
Type：Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException 
Msg：Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException: Unexpected end of request content.
   at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelBadHttpRequestException.Throw(RequestRejectionReason reason)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.Http1ContentLengthMessageBody.ReadAsyncInternal(CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpRequestStream.ReadAsyncInternal(Memory`1 destination, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.WebUtilities.FileBufferingReadStream.ReadAsync(Memory`1 buffer, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.WebUtilities.StreamHelperExtensions.DrainAsync(Stream stream, ArrayPool`1 bytePool, Nullable`1 limit, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Mvc.Formatters.NewtonsoftJsonInputFormatter.ReadRequestBodyAsync(InputFormatterContext context, Encoding encoding)
   at Microsoft.AspNetCore.Mvc.ModelBinding.Binders.BodyModelBinder.BindModelAsync(ModelBindingContext bindingContext)
   at Microsoft.AspNetCore.Mvc.ModelBinding.ParameterBinder.BindModelAsync(ActionContext actionContext, IModelBinder modelBinder, IValueProvider valueProvider, ParameterDescriptor parameter, ModelMetadata metadata, Object value, Object container)
   at Microsoft.AspNetCore.Mvc.Controllers.ControllerBinderDelegateProvider.<>c__DisplayClass0_0.<<CreateBinderDelegate>g__Bind|0>d.MoveNext()
--- End of stack trace from previous location ---
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeInnerFilterAsync>g__Awaited|13_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeNextResourceFilter>g__Awaited|24_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Rethrow(ResourceExecutedContextSealed context)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.InvokeFilterPipelineAsync()
--- End of stack trace from previous location ---
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Awaited|17_0(ResourceInvoker invoker, Task task, IDisposable scope)
   at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)
   at MeShop.CacheResponse.CacheResponseMiddleware.Invoke(HttpContext httpContext) in /builds/sitegroup/meshop/meshop/MeShop.CacheResponse/CacheResponseMiddleware.cs:line 56
   at MeShop.View.Shop.Models.CheckExpirationMiddleware.Invoke(HttpContext httpContext) in /builds/sitegroup/meshop/meshop/MeShop.View.Shop/Models/CheckExpirationMiddleware.cs:line 38
   at MeShop.WebCommon.Cache.ResponseDistributedCacheMiddleware.Invoke(HttpContext httpContext) in /builds/sitegroup/meshop/meshop/MeShop.WebCommon/Cache/ResponseDistributedCacheMiddleware.cs:line 105
   at Microsoft.AspNetCore.ResponseCaching.ResponseCachingMiddleware.Invoke(HttpContext httpContext)
   at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
   at MeShop.WebCommon.CircuitBreakerWebMiddleware.<>c__DisplayClass13_0.<<InvokeAsync>b__1>d.MoveNext() in /builds/sitegroup/meshop/meshop/MeShop.WebCommon/Middleware/CircuitBreakerWebMiddleware.cs:line 246
--- End of stack trace from previous location ---
   at Polly.AsyncPolicy.<>c__DisplayClass40_0.<<ImplementationAsync>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at Polly.CircuitBreaker.AsyncCircuitBreakerPolicy.<>c__DisplayClass8_0`1.<<ImplementationAsync>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at Polly.CircuitBreaker.AsyncCircuitBreakerEngine.ImplementationAsync[TResult](Func`3 action, Context context, CancellationToken cancellationToken, Boolean continueOnCapturedContext, ExceptionPredicates shouldHandleExceptionPredicates, ResultPredicates`1 shouldHandleResultPredicates, ICircuitController`1 breakerController)
   at Polly.CircuitBreaker.AsyncCircuitBreakerPolicy.ImplementationAsync[TResult](Func`3 action, Context context, CancellationToken cancellationToken, Boolean continueOnCapturedContext)
   at Polly.AsyncPolicy.ExecuteAsync(Func`3 action, Context context, CancellationToken cancellationToken, Boolean continueOnCapturedContext)
   at MeShop.WebCommon.CircuitBreakerWebMiddleware.InvokeAsync(HttpContext context) in /builds/sitegroup/meshop/meshop/MeShop.WebCommon/Middleware/CircuitBreakerWebMiddleware.cs:line 275

 

這里列舉一下本地調試的復現步驟（本地調試是單線程）：

• 在請求處理過程的某處設置斷點
• 在PostMan或瀏覽器上先發送A請求，命中斷點，不繼續往下處理，讓請求阻塞
• 繼續發放B請求，這時請求阻塞中，然后點擊取消請求
• 釋放斷點繼續處理，結果是A請求正常處理結束，B請求處理時拋出異常

解決方法有三種（參考的博客里只介紹了一種）：

• 1_可選擇在全局異常過濾器中不處理該異常，不打印錯誤日志(有掩耳盜鈴的嫌疑，不推薦)；
• 2_可以將接口[FromBody]由自動綁定改成代碼讀取接收，使用try-catch捕獲異常單獨處理（跟1類似，也不推薦）；
• 3_可以增加最小線程池數量，使其能夠擁有足夠的線程處理並發請求（確實訪問量太大，可以使用）；
• 4_優化現有的代碼：分析當時的請求為何造成了線程不夠用的原因，把耗時較長造成阻塞的有問題的方法處理掉，更新后再繼續觀察（適用於訪問量沒有那么大，部分接口代碼質量不好的情況時使用）；

 

參考博客：關於.Net Core3.0下因客戶端主動取消請求導致的Request.Body異常