當前位置：首頁 > 编程语言 > asp.net >内容正文

asp.net

深入探究ASP.NET Core读取Request.Body的正确方式

發(fā)布時間：2023/12/4 asp.net 56 豆豆

生活随笔收集整理的這篇文章主要介紹了深入探究ASP.NET Core读取Request.Body的正确方式小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

前言

????相信大家在使用ASP.NET Core進行開發(fā)的時候，肯定會涉及到讀取Request.Body的場景，畢竟我們大部分的POST請求都是將數(shù)據(jù)存放到Http的Body當中。因為筆者日常開發(fā)所使用的主要也是ASP.NET Core所以筆者也遇到這這種場景，關于本篇文章所套路的內(nèi)容，來自于在開發(fā)過程中我遇到的關于Request.Body的讀取問題。在之前的使用的時候，基本上都是借助搜索引擎搜索的答案，并沒有太關注這個，發(fā)現(xiàn)自己理解的和正確的使用之間存在很大的誤區(qū)。故有感而發(fā)，便寫下此文，以作記錄。學無止境，愿與君共勉。

常用讀取方式

當我們要讀取Request Body的時候，相信大家第一直覺和筆者是一樣的，這有啥難的，直接幾行代碼寫完，這里我們模擬在Filter中讀取Request Body，在Action或Middleware或其他地方讀取類似，有Request的地方就有Body，如下所示

public override void OnActionExecuting(ActionExecutingContext context) {//在ASP.NET Core中Request Body是Stream的形式StreamReader stream = new StreamReader(context.HttpContext.Request.Body);string body = stream.ReadToEnd();_logger.LogDebug("body content:" + body);base.OnActionExecuting(context); }

寫完之后，也沒多想，畢竟這么常規(guī)的操作，信心滿滿，運行起來調(diào)試一把，發(fā)現(xiàn)直接報一個這個錯System.InvalidOperationException: Synchronous operations are disallowed. Call ReadAsync or set AllowSynchronousIO to true instead.大致的意思就是同步操作不被允許，請使用ReadAsync的方式或設置AllowSynchronousIO為true。雖然沒說怎么設置AllowSynchronousIO，不過我們借助搜索引擎是我們最大的強項。

同步讀取

首先我們來看設置AllowSynchronousIO為true的方式，看名字也知道是允許同步IO，設置方式大致有兩種，待會我們會通過源碼來探究一下它們直接有何不同，我們先來看一下如何設置AllowSynchronousIO的值。第一種方式是在ConfigureServices中配置，操作如下

services.Configure<KestrelServerOptions>(options => {options.AllowSynchronousIO = true; });

這種方式和在配置文件中配置Kestrel選項配置是一樣的只是方式不同，設置完之后即可，運行不在報錯。還有一種方式，可以不用在ConfigureServices中設置，通過IHttpBodyControlFeature的方式設置，具體如下

public override void OnActionExecuting(ActionExecutingContext context) {var syncIOFeature = context.HttpContext.Features.Get<IHttpBodyControlFeature>();if (syncIOFeature != null){syncIOFeature.AllowSynchronousIO = true;}StreamReader stream = new StreamReader(context.HttpContext.Request.Body);string body = stream.ReadToEnd();_logger.LogDebug("body content:" + body);base.OnActionExecuting(context); }

這種方式同樣有效，通過這種方式操作，不需要每次讀取Body的時候都去設置，只要在準備讀取Body之前設置一次即可。這兩種方式都是去設置AllowSynchronousIO為true，但是我們需要思考一點，微軟為何設置AllowSynchronousIO默認為false，說明微軟并不希望我們?nèi)ネ阶x取Body。通過查找資料得出了這么一個結論

Kestrel：默認情況下禁用 AllowSynchronousIO（同步IO），線程不足會導致應用崩潰，而同步I/O API（例如HttpRequest.Body.Read）是導致線程不足的常見原因。

由此可以知道，這種方式雖然能解決問題，但是性能并不是不好，微軟也不建議這么操作，當程序流量比較大的時候，很容易導致程序不穩(wěn)定甚至崩潰。

異步讀取

通過上面我們了解到微軟并不希望我們通過設置AllowSynchronousIO的方式去操作，因為會影響性能。那我們可以使用異步的方式去讀取，這里所說的異步方式其實就是使用Stream自帶的異步方法去讀取，如下所示

public override void OnActionExecuting(ActionExecutingContext context) {StreamReader stream = new StreamReader(context.HttpContext.Request.Body);string body = stream.ReadToEndAsync().GetAwaiter().GetResult();_logger.LogDebug("body content:" + body);base.OnActionExecuting(context); }

就這么簡單，不需要額外設置其他的東西，僅僅通過ReadToEndAsync的異步方法去操作。ASP.NET Core中許多操作都是異步操作，甚至是過濾器或中間件都可以直接返回Task類型的方法，因此我們可以直接使用異步操作

這兩種方式的操作優(yōu)點是不需要額外設置別的，只是通過異步方法讀取即可，也是我們比較推薦的做法。比較神奇的是我們只是將StreamReader的ReadToEnd替換成ReadToEndAsync方法就皆大歡喜了，有沒有感覺到比較神奇。當我們感到神奇的時候，是因為我們對它還不夠了解，接下來我們就通過源碼的方式，一步一步的揭開它神秘的面紗。

重復讀取

上面我們演示了使用同步方式和異步方式讀取RequestBody，但是這樣真的就可以了嗎？其實并不行，這種方式每次請求只能讀取一次正確的Body結果，如果繼續(xù)對RequestBody這個Stream進行讀取，將讀取不到任何內(nèi)容，首先來舉個例子

上面的例子中body里有正確的RequestBody的結果，但是body2中是空字符串。這個情況是比較糟糕的，為啥這么說呢？如果你是在Middleware中讀取的RequestBody，而這個中間件的執(zhí)行是在模型綁定之前，那么將會導致模型綁定失敗，因為模型綁定有的時候也需要讀取RequestBody獲取http請求內(nèi)容。至于為什么會這樣相信大家也有了一定的了解，因為我們在讀取完Stream之后，此時的Stream指針位置已經(jīng)在Stream的結尾處，即Position此時不為0，而Stream讀取正是依賴Position來標記外部讀取Stream到啥位置，所以我們再次讀取的時候會從結尾開始讀，也就讀取不到任何信息了。所以我們要想重復讀取RequestBody那么就要再次讀取之前重置RequestBody的Position為0，如下所示

public override async Task OnActionExecutionAsync(ActionExecutingContext context, ActionExecutionDelegate next) {StreamReader stream = new StreamReader(context.HttpContext.Request.Body);string body = await stream.ReadToEndAsync();_logger.LogDebug("body content:" + body);//或者使用重置Position的方式 context.HttpContext.Request.Body.Position = 0;//如果你確定上次讀取完之后已經(jīng)重置了Position那么這一句可以省略context.HttpContext.Request.Body.Seek(0, SeekOrigin.Begin);StreamReader stream2 = new StreamReader(context.HttpContext.Request.Body);string body2 = await stream2.ReadToEndAsync();//用完了我們盡量也重置一下，自己的坑自己填context.HttpContext.Request.Body.Seek(0, SeekOrigin.Begin);_logger.LogDebug("body2 content:" + body2);await next(); }

寫完之后，開開心心的運行起來看一下效果，發(fā)現(xiàn)報了一個錯System.NotSupportedException: Specified method is not supported.at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpRequestStream.Seek(Int64 offset, SeekOrigin origin)大致可以理解起來不支持這個操作，至于為啥，一會解析源碼的時候咱們一起看一下。說了這么多，那到底該如何解決呢？也很簡單，微軟知道自己刨下了坑，自然給我們提供了解決辦法，用起來也很簡單就是加EnableBuffering

public override async Task OnActionExecutionAsync(ActionExecutingContext context, ActionExecutionDelegate next) {//操作Request.Body之前加上EnableBuffering即可context.HttpContext.Request.EnableBuffering();StreamReader stream = new StreamReader(context.HttpContext.Request.Body);string body = await stream.ReadToEndAsync();_logger.LogDebug("body content:" + body);context.HttpContext.Request.Body.Seek(0, SeekOrigin.Begin);StreamReader stream2 = new StreamReader(context.HttpContext.Request.Body);//注意這里！！！我已經(jīng)使用了同步讀取的方式string body2 = stream2.ReadToEnd();context.HttpContext.Request.Body.Seek(0, SeekOrigin.Begin);_logger.LogDebug("body2 content:" + body2);await next(); }

通過添加Request.EnableBuffering()我們就可以重復的讀取RequestBody了，看名字我們可以大概的猜出來，他是和緩存RequestBody有關，需要注意的是Request.EnableBuffering()要加在準備讀取RequestBody之前才有效果，否則將無效，而且每次請求只需要添加一次即可。而且大家看到了我第二次讀取Body的時候使用了同步的方式去讀取的RequestBody，是不是很神奇，待會的時候我們會從源碼的角度分析這個問題。

源碼探究

上面我們看到了通過StreamReader的ReadToEnd同步讀取Request.Body需要設置AllowSynchronousIO為true才能操作，但是使用StreamReader的ReadToEndAsync方法卻可以直接操作。

StreamReader和Stream的關系

我們看到了都是通過操作StreamReader的方法即可，那關我Request.Body啥事，別急咱們先看一看這里的操作，首先來大致看下ReadToEnd的實現(xiàn)了解一下StreamReader到底和Stream有啥關聯(lián)，找到ReadToEnd方法[點擊查看源碼????^[1]]

public override string ReadToEnd() {ThrowIfDisposed();CheckAsyncTaskInProgress();// 調(diào)用ReadBuffer，然后從charBuffer中提取數(shù)據(jù)。StringBuilder sb = new StringBuilder(_charLen - _charPos);do{//循環(huán)拼接讀取內(nèi)容sb.Append(_charBuffer, _charPos, _charLen - _charPos);_charPos = _charLen; //讀取buffer，這是核心操作ReadBuffer();} while (_charLen > 0);//返回讀取內(nèi)容return sb.ToString(); }

通過這段源碼我們了解到了這么個信息，一個是StreamReader的ReadToEnd其實本質(zhì)是通過循環(huán)讀取ReadBuffer然后通過StringBuilder去拼接讀取的內(nèi)容，核心是讀取ReadBuffer方法，由于代碼比較多，我們找到大致呈現(xiàn)一下核心操作[點擊查看源碼????^[2]]

if (_checkPreamble) {//通過這里我們可以知道本質(zhì)就是使用要讀取的Stream里的Read方法int len = _stream.Read(_byteBuffer, _bytePos, _byteBuffer.Length - _bytePos);if (len == 0){if (_byteLen > 0){_charLen += _decoder.GetChars(_byteBuffer, 0, _byteLen, _charBuffer, _charLen);_bytePos = _byteLen = 0;}return _charLen;}_byteLen += len; } else {//通過這里我們可以知道本質(zhì)就是使用要讀取的Stream里的Read方法_byteLen = _stream.Read(_byteBuffer, 0, _byteBuffer.Length);if (_byteLen == 0) {return _charLen;} }

通過上面的代碼我們可以了解到StreamReader其實是工具類，只是封裝了對Stream的原始操作，簡化我們的代碼ReadToEnd方法本質(zhì)是讀取Stream的Read方法。接下來我們看一下ReadToEndAsync方法的具體實現(xiàn)[點擊查看源碼????^[3]]

public override Task<string> ReadToEndAsync() {if (GetType() != typeof(StreamReader)){return base.ReadToEndAsync();}ThrowIfDisposed();CheckAsyncTaskInProgress();//本質(zhì)是ReadToEndAsyncInternal方法Task<string> task = ReadToEndAsyncInternal();_asyncReadTask = task;return task; }private async Task<string> ReadToEndAsyncInternal() {//也是循環(huán)拼接讀取的內(nèi)容StringBuilder sb = new StringBuilder(_charLen - _charPos);do{int tmpCharPos = _charPos;sb.Append(_charBuffer, tmpCharPos, _charLen - tmpCharPos);_charPos = _charLen; //核心操作是ReadBufferAsync方法await ReadBufferAsync(CancellationToken.None).ConfigureAwait(false);} while (_charLen > 0);return sb.ToString(); }

通過這個我們可以看到核心操作是ReadBufferAsync方法，代碼比較多我們同樣看一下核心實現(xiàn)[點擊查看源碼????^[4]]

byte[] tmpByteBuffer = _byteBuffer; //Stream賦值給tmpStream Stream tmpStream = _stream; if (_checkPreamble) {int tmpBytePos = _bytePos;//本質(zhì)是調(diào)用Stream的ReadAsync方法int len = await tmpStream.ReadAsync(new Memory<byte>(tmpByteBuffer, tmpBytePos, tmpByteBuffer.Length - tmpBytePos), cancellationToken).ConfigureAwait(false);if (len == 0){if (_byteLen > 0){_charLen += _decoder.GetChars(tmpByteBuffer, 0, _byteLen, _charBuffer, _charLen);_bytePos = 0; _byteLen = 0;}return _charLen;}_byteLen += len; } else {//本質(zhì)是調(diào)用Stream的ReadAsync方法_byteLen = await tmpStream.ReadAsync(new Memory<byte>(tmpByteBuffer), cancellationToken).ConfigureAwait(false);if (_byteLen == 0) {return _charLen;} }

通過上面代碼我可以了解到StreamReader的本質(zhì)就是讀取Stream的包裝，核心方法還是來自Stream本身。我們之所以大致介紹了StreamReader類，就是為了給大家呈現(xiàn)出StreamReader和Stream的關系，否則怕大家誤解這波操作是StreamReader的里的實現(xiàn)，而不是Request.Body的問題，其實并不是這樣的所有的一切都是指向Stream的Request的Body就是Stream這個大家可以自己查看一下，了解到這一步我們就可以繼續(xù)了。

HttpRequest的Body

上面我們說到了Request的Body本質(zhì)就是Stream，Stream本身是抽象類，所以Request.Body是Stream的實現(xiàn)類。默認情況下Request.Body的是HttpRequestStream的實例[點擊查看源碼????^[5]]，我們這里說了是默認，因為它是可以改變的，我們一會再說。我們從上面StreamReader的結論中得到ReadToEnd本質(zhì)還是調(diào)用的Stream的Read方法，即這里的HttpRequestStream的Read方法，我們來看一下具體實現(xiàn)[點擊查看源碼????^[6]]

public override int Read(byte[] buffer, int offset, int count) {//知道同步讀取Body為啥報錯了吧if (!_bodyControl.AllowSynchronousIO){throw new InvalidOperationException(CoreStrings.SynchronousReadsDisallowed);}//本質(zhì)是調(diào)用ReadAsyncreturn ReadAsync(buffer, offset, count).GetAwaiter().GetResult(); }

通過這段代碼我們就可以知道了為啥在不設置AllowSynchronousIO為true的情下讀取Body會拋出異常了吧，這個是程序級別的控制，而且我們還了解到Read的本質(zhì)還是在調(diào)用ReadAsync異步方法

public override ValueTask<int> ReadAsync(Memory<byte> destination, CancellationToken cancellationToken = default) {return ReadAsyncWrapper(destination, cancellationToken); }

ReadAsync本身并無特殊限制，所以直接操作ReadAsync不會存在類似Read的異常。

通過這個我們得出了結論Request.Body即HttpRequestStream的同步讀取Read會拋出異常，而異步讀取ReadAsync并不會拋出異常只和HttpRequestStream的Read方法本身存在判斷AllowSynchronousIO的值有關系。

AllowSynchronousIO本質(zhì)來源

通過HttpRequestStream的Read方法我們可以知道AllowSynchronousIO控制了同步讀取的方式。而且我們還了解到了AllowSynchronousIO有幾種不同方式的去配置，接下來我們來大致看下幾種方式的本質(zhì)是哪一種。通過HttpRequestStream我們知道Read方法中的AllowSynchronousIO的屬性是來自IHttpBodyControlFeature也就是我們上面介紹的第二種配置方式

private readonly HttpRequestPipeReader _pipeReader; private readonly IHttpBodyControlFeature _bodyControl; public HttpRequestStream(IHttpBodyControlFeature bodyControl, HttpRequestPipeReader pipeReader) {_bodyControl = bodyControl;_pipeReader = pipeReader; }

那么它和KestrelServerOptions肯定是有關系的，因為我們只配置KestrelServerOptions的是HttpRequestStream的Read是不報異常的，而HttpRequestStream的Read只依賴了IHttpBodyControlFeature的AllowSynchronousIO屬性。Kestrel中HttpRequestStream初始化的地方在BodyControl[點擊查看源碼????^[7]]

private readonly HttpRequestStream _request; public BodyControl(IHttpBodyControlFeature bodyControl, IHttpResponseControl responseControl) {_request = new HttpRequestStream(bodyControl, _requestReader); }

而初始化BodyControl的地方在HttpProtocol中,我們找到初始化BodyControl的InitializeBodyControl方法[點擊查看源碼????^[8]]

public void InitializeBodyControl(MessageBody messageBody) {if (_bodyControl == null){//這里傳遞的是bodyControl傳遞的是this_bodyControl = new BodyControl(bodyControl: this, this);}(RequestBody, ResponseBody, RequestBodyPipeReader, ResponseBodyPipeWriter) = _bodyControl.Start(messageBody);_requestStreamInternal = RequestBody;_responseStreamInternal = ResponseBody; }

這里我們可以看的到初始化IHttpBodyControlFeature既然傳遞的是this，也就是HttpProtocol當前實例。也就是說HttpProtocol是實現(xiàn)了IHttpBodyControlFeature接口，HttpProtocol本身是partial的，我們在其中一個分布類HttpProtocol.FeatureCollection中看到了實現(xiàn)關系 [點擊查看源碼????^[9]]

internal partial class HttpProtocol : IHttpRequestFeature, IHttpRequestBodyDetectionFeature, IHttpResponseFeature, IHttpResponseBodyFeature, IRequestBodyPipeFeature, IHttpUpgradeFeature, IHttpConnectionFeature, IHttpRequestLifetimeFeature, IHttpRequestIdentifierFeature, IHttpRequestTrailersFeature, IHttpBodyControlFeature, IHttpMaxRequestBodySizeFeature, IEndpointFeature, IRouteValuesFeature { bool IHttpBodyControlFeature.AllowSynchronousIO { get => AllowSynchronousIO; set => AllowSynchronousIO = value; } }

通過這個可以看出HttpProtocol確實實現(xiàn)了IHttpBodyControlFeature接口，接下來我們找到初始化AllowSynchronousIO的地方，找到了AllowSynchronousIO = ServerOptions.AllowSynchronousIO;這段代碼說明來自于ServerOptions這個屬性，找到初始化ServerOptions的地方[點擊查看源碼????^[10]]

private HttpConnectionContext _context; //ServiceContext初始化來自HttpConnectionContext public ServiceContext ServiceContext => _context.ServiceContext; protected KestrelServerOptions ServerOptions { get; set; } = default!; public void Initialize(HttpConnectionContext context) {_context = context;//來自ServiceContextServerOptions = ServiceContext.ServerOptions;Reset();HttpResponseControl = this; }

通過這個我們知道ServerOptions來自于ServiceContext的ServerOptions屬性，我們找到給ServiceContext賦值的地方，在KestrelServerImpl的CreateServiceContext方法里[點擊查看源碼????^[11]]精簡一下邏輯，抽出來核心內(nèi)容大致實現(xiàn)如下

public KestrelServerImpl(IOptions<KestrelServerOptions> options,IEnumerable<IConnectionListenerFactory> transportFactories,ILoggerFactory loggerFactory) //注入進來的IOptions<KestrelServerOptions>調(diào)用了CreateServiceContext: this(transportFactories, null, CreateServiceContext(options, loggerFactory)) { }private static ServiceContext CreateServiceContext(IOptions<KestrelServerOptions> options, ILoggerFactory loggerFactory) {//值來自于IOptions<KestrelServerOptions> var serverOptions = options.Value ?? new KestrelServerOptions();return new ServiceContext{Log = trace,HttpParser = new HttpParser<Http1ParsingHandler>(trace.IsEnabled(LogLevel.Information)),Scheduler = PipeScheduler.ThreadPool,SystemClock = heartbeatManager,DateHeaderValueManager = dateHeaderValueManager,ConnectionManager = connectionManager,Heartbeat = heartbeat,//賦值操作ServerOptions = serverOptions,}; }

通過上面的代碼我們可以看到如果配置了KestrelServerOptions那么ServiceContext的ServerOptions屬性就來自于KestrelServerOptions，即我們通過services.Configure<KestrelServerOptions>()配置的值，總之得到了這么一個結論

如果配置了KestrelServerOptions即services.Configure()，那么AllowSynchronousIO來自于KestrelServerOptions。即IHttpBodyControlFeature的AllowSynchronousIO屬性來自于KestrelServerOptions。如果沒有配置，那么直接通過修改IHttpBodyControlFeature實例的 AllowSynchronousIO屬性能得到相同的效果，畢竟HttpRequestStream是直接依賴的IHttpBodyControlFeature實例。

EnableBuffering神奇的背后

我們在上面的示例中看到了，如果不添加EnableBuffering的話直接設置RequestBody的Position會報NotSupportedException這么一個錯誤，而且加了它之后我居然可以直接使用同步的方式去讀取RequestBody，首先我們來看一下為啥會報錯，我們從上面的錯誤了解到錯誤來自于HttpRequestStream這個類[點擊查看源碼????^[12]]，上面我們也說了這個類繼承了Stream抽象類,通過源碼我們可以看到如下相關代碼

//不能使用Seek操作 public override bool CanSeek => false; //允許讀 public override bool CanRead => true; //不允許寫 public override bool CanWrite => false; //不能獲取長度 public override long Length => throw new NotSupportedException(); //不能讀寫Position public override long Position {get => throw new NotSupportedException();set => throw new NotSupportedException(); } //不能使用Seek方法 public override long Seek(long offset, SeekOrigin origin) {throw new NotSupportedException(); }

相信通過這些我們可以清楚的看到針對HttpRequestStream的設置或者寫相關的操作是不被允許的，這也是為啥我們上面直接通過Seek設置Position的時候為啥會報錯，還有一些其他操作的限制，總之默認是不希望我們對HttpRequestStream做過多的操作，特別是設置或者寫相關的操作。但是我們使用EnableBuffering的時候卻沒有這些問題，究竟是為什么?接下來我們要揭開它的什么面紗了。首先我們從Request.EnableBuffering()這個方法入手，找到源碼位置在HttpRequestRewindExtensions擴展類中[點擊查看源碼????^[13]]，我們從最簡單的無參方法開始看到如下定義

/// <summary> /// 確保Request.Body可以被多次讀取 /// </summary> /// <param name="request"></param> public static void EnableBuffering(this HttpRequest request) {BufferingHelper.EnableRewind(request); }

上面的方法是最簡單的形式，還有一個EnableBuffering的擴展方法是參數(shù)最全的擴展方法，這個方法可以控制讀取的大小和控制是否存儲到磁盤的限定大小

/// <summary> /// 確保Request.Body可以被多次讀取 /// </summary> /// <param name="request"></param> /// <param name="bufferThreshold">內(nèi)存中用于緩沖流的最大大小（字節(jié)）。較大的請求主體被寫入磁盤。</param> /// <param name="bufferLimit">請求正文的最大大小（字節(jié)）。嘗試讀取超過此限制將導致異常</param> public static void EnableBuffering(this HttpRequest request, int bufferThreshold, long bufferLimit) {BufferingHelper.EnableRewind(request, bufferThreshold, bufferLimit); }

無論那種形式，最終都是在調(diào)用BufferingHelper.EnableRewind這個方法，話不多說直接找到BufferingHelper這個類，找到類的位置[點擊查看源碼????^[14]]代碼不多而且比較簡潔，咱們就把EnableRewind的實現(xiàn)粘貼出來

//默認內(nèi)存中可緩存的大小為30K,超過這個大小將會被存儲到磁盤 internal const int DefaultBufferThreshold = 1024 * 30;/// <summary> /// 這個方法也是HttpRequest擴展方法 /// </summary> /// <returns></returns> public static HttpRequest EnableRewind(this HttpRequest request, int bufferThreshold = DefaultBufferThreshold, long? bufferLimit = null) {if (request == null){throw new ArgumentNullException(nameof(request));}//先獲取Request Bodyvar body = request.Body;//默認情況Body是HttpRequestStream這個類CanSeek是false所以肯定會執(zhí)行到if邏輯里面if (!body.CanSeek){//實例化了FileBufferingReadStream這個類，看來這是關鍵所在var fileStream = new FileBufferingReadStream(body, bufferThreshold,bufferLimit,AspNetCoreTempDirectory.TempDirectoryFactory);//賦值給Body，也就是說開啟了EnableBuffering之后Request.Body類型將會是FileBufferingReadStreamrequest.Body = fileStream;//這里要把fileStream注冊給Response便于釋放request.HttpContext.Response.RegisterForDispose(fileStream);}return request; }

從上面這段源碼實現(xiàn)中我們可以大致得到兩個結論

?BufferingHelper的EnableRewind方法也是HttpRequest的擴展方法，可以直接通過Request.EnableRewind的形式調(diào)用，效果等同于調(diào)用Request.EnableBuffering因為EnableBuffering也是調(diào)用的EnableRewind?啟用了EnableBuffering這個操作之后實際上會使用FileBufferingReadStream替換掉默認的HttpRequestStream，所以后續(xù)處理RequestBody的操作將會是FileBufferingReadStream實例

通過上面的分析我們也清楚的看到了，核心操作在于FileBufferingReadStream這個類，而且從名字也能看出來它肯定是也繼承了Stream抽象類，那還等啥直接找到FileBufferingReadStream的實現(xiàn)[點擊查看源碼????^[15]]，首先來看他類的定義

public class FileBufferingReadStream : Stream { }

毋庸置疑確實是繼承自Steam類，我們上面也看到了使用了Request.EnableBuffering之后就可以設置和重復讀取RequestBody，說明進行了一些重寫操作，具體我們來看一下

/// <summary> /// 允許讀 /// </summary> public override bool CanRead {get { return true; } } /// <summary> /// 允許Seek /// </summary> public override bool CanSeek {get { return true; } } /// <summary> /// 不允許寫 /// </summary> public override bool CanWrite {get { return false; } } /// <summary> /// 可以獲取長度 /// </summary> public override long Length {get { return _buffer.Length; } } /// <summary> /// 可以讀寫Position /// </summary> public override long Position {get { return _buffer.Position; }set{ThrowIfDisposed();_buffer.Position = value;} }public override long Seek(long offset, SeekOrigin origin) {//如果Body已釋放則異常ThrowIfDisposed();//特殊情況拋出異常//_completelyBuffered代表是否完全緩存一定是在原始的HttpRequestStream讀取完成后才置為true//出現(xiàn)沒讀取完成但是原始位置信息和當前位置信息不一致則直接拋出異常if (!_completelyBuffered && origin == SeekOrigin.End){throw new NotSupportedException("The content has not been fully buffered yet.");}else if (!_completelyBuffered && origin == SeekOrigin.Current && offset + Position > Length){throw new NotSupportedException("The content has not been fully buffered yet.");}else if (!_completelyBuffered && origin == SeekOrigin.Begin && offset > Length){throw new NotSupportedException("The content has not been fully buffered yet.");}//充值buffer的Seekreturn _buffer.Seek(offset, origin); }

因為重寫了一些關鍵設置，所以我們可以設置一些流相關的操作。從Seek方法中我們看到了兩個比較重要的參數(shù)_completelyBuffered和_buffer，_completelyBuffered用來判斷原始的HttpRequestStream是否讀取完成，因為FileBufferingReadStream歸根結底還是先讀取了HttpRequestStream的內(nèi)容。_buffer正是承載從HttpRequestStream讀取的內(nèi)容,我們大致抽離一下邏輯看一下，切記這不是全部邏輯，是抽離出來的大致思想

private readonly ArrayPool<byte> _bytePool; private const int _maxRentedBufferSize = 1024 * 1024; //1MB private Stream _buffer; public FileBufferingReadStream(int memoryThreshold) {//即使我們設置memoryThreshold那么它最大也不能超過1MB否則也會存儲在磁盤上if (memoryThreshold <= _maxRentedBufferSize){_rentedBuffer = bytePool.Rent(memoryThreshold);_buffer = new MemoryStream(_rentedBuffer);_buffer.SetLength(0);}else{//超過1M將緩存到磁盤所以僅僅初始化_buffer = new MemoryStream();} }

這些都是一些初始化的操作，核心操作當然還是在FileBufferingReadStream的Read方法里，因為真正讀取的地方就在這，我們找到Read方法位置[點擊查看源碼????^[16]]

private readonly Stream _inner; public FileBufferingReadStream(Stream inner) {//接收原始的Request.Body_inner = inner; } public override int Read(Span<byte> buffer) {ThrowIfDisposed();//如果讀取完成過則直接在buffer中獲取信息直接返回if (_buffer.Position < _buffer.Length || _completelyBuffered){return _buffer.Read(buffer);}//未讀取完成才會走到這里//_inner正是接收的原始的RequestBody//讀取的RequestBody放入buffer中var read = _inner.Read(buffer);//超過設定的長度則會拋出異常if (_bufferLimit.HasValue && _bufferLimit - read < _buffer.Length){throw new IOException("Buffer limit exceeded.");}//如果設定存儲在內(nèi)存中并且Body長度大于設定的可存儲在內(nèi)存中的長度,則存儲到磁盤中if (_inMemory && _memoryThreshold - read < _buffer.Length){_inMemory = false;//緩存原始的Body流var oldBuffer = _buffer;//創(chuàng)建緩存文件_buffer = CreateTempFile();//超過內(nèi)存存儲限制，但是還未寫入過臨時文件if (_rentedBuffer == null){oldBuffer.Position = 0;var rentedBuffer = _bytePool.Rent(Math.Min((int)oldBuffer.Length, _maxRentedBufferSize));try{//將Body流讀取到緩存文件流中var copyRead = oldBuffer.Read(rentedBuffer);//判斷是否讀取到結尾while (copyRead > 0){//將oldBuffer寫入到緩存文件流_buffer當中_buffer.Write(rentedBuffer.AsSpan(0, copyRead));copyRead = oldBuffer.Read(rentedBuffer);}}finally{//讀取完成之后歸還臨時緩沖區(qū)到ArrayPool中_bytePool.Return(rentedBuffer);}}else{_buffer.Write(_rentedBuffer.AsSpan(0, (int)oldBuffer.Length));_bytePool.Return(_rentedBuffer);_rentedBuffer = null;}}//如果讀取RequestBody未到結尾,則一直寫入到緩存區(qū)if (read > 0){_buffer.Write(buffer.Slice(0, read));}else{//如果已經(jīng)讀取RequestBody完畢，也就是寫入到緩存完畢則更新_completelyBuffered//標記為以全部讀取RequestBody完成，后續(xù)在讀取RequestBody則直接在_buffer中讀取_completelyBuffered = true;}//返回讀取的byte個數(shù)用于外部StreamReader判斷讀取是否完成return read; }

代碼比較多看著也比較復雜，其實核心思路還是比較清晰的，我們來大致的總結一下

?首先判斷是否完全的讀取過原始的RequestBody,如果完全完整的讀取過RequestBody則直接在緩沖區(qū)中獲取返回?如果RequestBody長度大于設定的內(nèi)存存儲限定，則將緩沖寫入磁盤臨時文件中?如果是首次讀取或為完全完整的讀取完成RequestBody，那么將RequestBody的內(nèi)容寫入到緩沖區(qū)，知道讀取完成

其中CreateTempFile這是創(chuàng)建臨時文件的操作流，目的是為了將RequestBody的信息寫入到臨時文件中。可以指定臨時文件的地址，若如果不指定則使用系統(tǒng)默認目錄，它的實現(xiàn)如下[點擊查看源碼????^[17]]

private Stream CreateTempFile() {//判斷是否制定過緩存目錄，沒有的話則使用系統(tǒng)臨時文件目錄if (_tempFileDirectory == null){Debug.Assert(_tempFileDirectoryAccessor != null);_tempFileDirectory = _tempFileDirectoryAccessor();Debug.Assert(_tempFileDirectory != null);}//臨時文件的完整路徑_tempFileName = Path.Combine(_tempFileDirectory, "ASPNETCORE_" + Guid.NewGuid().ToString() + ".tmp");//返回臨時文件的操作流return new FileStream(_tempFileName, FileMode.Create, FileAccess.ReadWrite, FileShare.Delete, 1024 * 16,FileOptions.Asynchronous | FileOptions.DeleteOnClose | FileOptions.SequentialScan); }

我們上面分析了FileBufferingReadStream的Read方法這個方法是同步讀取的方法可供StreamReader的ReadToEnd方法使用，當然它還存在一個異步讀取方法ReadAsync供StreamReader的ReadToEndAsync方法使用。這兩個方法的實現(xiàn)邏輯是完全一致的，只是讀取和寫入操作都是異步的操作，這里咱們就不介紹那個方法了，有興趣的同學可以自行了解一下ReadAsync方法的實現(xiàn)[點擊查看源碼????^[18]]

當開啟EnableBuffering的時候，無論首次讀取是設置了AllowSynchronousIO為true的ReadToEnd同步讀取方式，還是直接使用ReadToEndAsync的異步讀取方式，那么再次使用ReadToEnd同步方式去讀取Request.Body也便無需去設置AllowSynchronousIO為true。因為默認的Request.Body已經(jīng)由HttpRequestStream實例替換為FileBufferingReadStream實例，而FileBufferingReadStream重寫了Read和ReadAsync方法，并不存在不允許同步讀取的限制。

總結

????本篇文章篇幅比較多，如果你想深入的研究相關邏輯，希望本文能給你帶來一些閱讀源碼的指導。為了防止大家深入文章當中而忘記了具體的流程邏輯，在這里我們就大致的總結一下關于正確讀取RequestBody的全部結論

?首先關于同步讀取Request.Body由于默認的RequestBody的實現(xiàn)是HttpRequestStream，但是HttpRequestStream在重寫Read方法的時候會判斷是否開啟AllowSynchronousIO，如果未開啟則直接拋出異常。但是HttpRequestStream的ReadAsync方法并無這種限制，所以使用異步方式的讀取RequestBody并無異常。?雖然通過設置AllowSynchronousIO或使用ReadAsync的方式我們可以讀取RequestBody，但是RequestBody無法重復讀取，這是因為HttpRequestStream的Position和Seek都是不允許進行修改操作的，設置了會直接拋出異常。為了可以重復讀取，我們引入了Request的擴展方法EnableBuffering通過這個方法我們可以重置讀取位置來實現(xiàn)RequestBody的重復讀取。?關于開啟EnableBuffering方法每次請求設置一次即可，即在準備讀取RequestBody之前設置。其本質(zhì)其實是使用FileBufferingReadStream代替默認RequestBody的默認類型HttpRequestStream，這樣我們在一次Http請求中操作Body的時候其實是操作FileBufferingReadStream，這個類重寫Stream的時候Position和Seek都是可以設置的，這樣我們就實現(xiàn)了重復讀取。?FileBufferingReadStream帶給我們的不僅僅是可重復讀取，還增加了對RequestBody的緩存功能，使得我們在一次請求中重復讀取RequestBody的時候可以在Buffer里直接獲取緩存內(nèi)容而Buffer本身是一個MemoryStream。當然我們也可以自己實現(xiàn)一套邏輯來替換Body，只要我們重寫的時候讓這個Stream支持重置讀取位置即可。

以上就是本次筆者對關于如何更好的方式操作Request.Body的理解，關于講解內(nèi)容筆者深知自己能力有限，理解的不一定透徹，甚至理解的不一定對，還望大家多多諒解，也歡迎大家能夠多多交流。

References

[1]?點擊查看源碼????:?https://github.com/dotnet/runtime/blob/v5.0.5/src/libraries/System.Private.CoreLib/src/System/IO/StreamReader.cs#L393
[2]?點擊查看源碼????:?https://github.com/dotnet/runtime/blob/v5.0.5/src/libraries/System.Private.CoreLib/src/System/IO/StreamReader.cs#L576
[3]?點擊查看源碼????:?https://github.com/dotnet/runtime/blob/v5.0.5/src/libraries/System.Private.CoreLib/src/System/IO/StreamReader.cs#L898
[4]?點擊查看源碼????:?https://github.com/dotnet/runtime/blob/v5.0.5/src/libraries/System.Private.CoreLib/src/System/IO/StreamReader.cs#L1222
[5]?點擊查看源碼????:?https://github.com/dotnet/aspnetcore/blob/v5.0.5/src/Servers/Kestrel/Core/src/Internal/Http/HttpRequestStream.cs
[6]?點擊查看源碼????:?https://github.com/dotnet/aspnetcore/blob/v5.0.5/src/Servers/Kestrel/Core/src/Internal/Http/HttpRequestStream.cs#L55
[7]?點擊查看源碼????:?https://github.com/dotnet/aspnetcore/blob/v5.0.5/src/Servers/Kestrel/Core/src/Internal/Infrastructure/BodyControl.cs
[8]?點擊查看源碼????:?https://github.com/dotnet/aspnetcore/blob/v5.0.5/src/Servers/Kestrel/Core/src/Internal/Http/HttpProtocol.cs#L315
[9]?點擊查看源碼????:?https://github.com/dotnet/aspnetcore/blob/v5.0.5/src/Servers/Kestrel/Core/src/Internal/Http/HttpProtocol.FeatureCollection.cs
[10]?點擊查看源碼????:?https://github.com/dotnet/aspnetcore/blob/v5.0.5/src/Servers/Kestrel/Core/src/Internal/Http/HttpProtocol.cs#L82
[11]?點擊查看源碼????:?https://github.com/dotnet/aspnetcore/blob/v5.0.5/src/Servers/Kestrel/Core/src/Internal/KestrelServerImpl.cs#L92
[12]?點擊查看源碼????:?https://github.com/dotnet/aspnetcore/blob/v5.0.5/src/Servers/Kestrel/Core/src/Internal/Http/HttpRequestStream.cs
[13]?點擊查看源碼????:?https://github.com/dotnet/aspnetcore/blob/v5.0.5/src/Http/Http/src/Extensions/HttpRequestRewindExtensions.cs
[14]?點擊查看源碼????:?https://github.com/dotnet/aspnetcore/blob/v5.0.5/src/Http/Http/src/Internal/BufferingHelper.cs
[15]?點擊查看源碼????:?https://github.com/dotnet/aspnetcore/blob/v5.0.5/src/Http/WebUtilities/src/FileBufferingReadStream.cs
[16]?點擊查看源碼????:?https://github.com/dotnet/aspnetcore/blob/v5.0.5/src/Http/WebUtilities/src/FileBufferingReadStream.cs#L212
[17]?點擊查看源碼????:?https://github.com/dotnet/aspnetcore/blob/v5.0.5/src/Http/WebUtilities/src/FileBufferingReadStream.cs#L198
[18]?點擊查看源碼????:?https://github.com/dotnet/aspnetcore/blob/v5.0.5/src/Http/WebUtilities/src/FileBufferingReadStream.cs#L285

????歡迎掃碼關注我的公眾號????

總結

以上是生活随笔為你收集整理的深入探究ASP.NET Core读取Request.Body的正确方式的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。

上一篇：面试八股文：你写过自定义任务调度器吗？
下一篇： ML.NET 示例：对象检测