ASP.NET Core讀取Request.Body的正確方法
前言
相信大家在使用ASP.NET Core進(jìn)行開發(fā)的時(shí)候,肯定會(huì)涉及到讀取Request.Body的場(chǎng)景,畢竟我們大部分的POST請(qǐng)求都是將數(shù)據(jù)存放到Http的Body當(dāng)中。因?yàn)楣P者日常開發(fā)所使用的主要也是ASP.NET Core所以筆者也遇到這這種場(chǎng)景,關(guān)于本篇文章所套路的內(nèi)容,來自于在開發(fā)過程中我遇到的關(guān)于Request.Body的讀取問題。在之前的使用的時(shí)候,基本上都是借助搜索引擎搜索的答案,并沒有太關(guān)注這個(gè),發(fā)現(xiàn)自己理解的和正確的使用之間存在很大的誤區(qū)。故有感而發(fā),便寫下此文,以作記錄。學(xué)無止境,愿與君共勉。
常用讀取方式
當(dāng)我們要讀取Request Body的時(shí)候,相信大家第一直覺和筆者是一樣的,這有啥難的,直接幾行代碼寫完,這里我們模擬在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ī)的操作,信心滿滿,運(yùn)行起來調(diào)試一把,發(fā)現(xiàn)直接報(bào)一個(gè)這個(gè)錯(cuò)System.InvalidOperationException: Synchronous operations are disallowed. Call ReadAsync or set AllowSynchronousIO to true instead.
大致的意思就是同步操作不被允許,請(qǐng)使用ReadAsync的方式或設(shè)置AllowSynchronousIO為true。雖然沒說怎么設(shè)置AllowSynchronousIO,不過我們借助搜索引擎是我們最大的強(qiáng)項(xiàng)。
同步讀取
首先我們來看設(shè)置AllowSynchronousIO
為true
的方式,看名字也知道是允許同步IO,設(shè)置方式大致有兩種,待會(huì)我們會(huì)通過源碼來探究一下它們直接有何不同,我們先來看一下如何設(shè)置AllowSynchronousIO
的值。第一種方式是在ConfigureServices
中配置,操作如下
services.Configure<KestrelServerOptions>(options => { options.AllowSynchronousIO = true; });
這種方式和在配置文件中配置Kestrel選項(xiàng)配置是一樣的只是方式不同,設(shè)置完之后即可,運(yùn)行不在報(bào)錯(cuò)。還有一種方式,可以不用在ConfigureServices
中設(shè)置,通過IHttpBodyControlFeature
的方式設(shè)置,具體如下
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的時(shí)候都去設(shè)置,只要在準(zhǔn)備讀取Body之前設(shè)置一次即可。這兩種方式都是去設(shè)置AllowSynchronousIO
為true
,但是我們需要思考一點(diǎn),微軟為何設(shè)置AllowSynchronousIO
默認(rèn)為false
,說明微軟并不希望我們?nèi)ネ阶x取Body。通過查找資料得出了這么一個(gè)結(jié)論
Kestrel:默認(rèn)情況下禁用 AllowSynchronousIO(同步IO),線程不足會(huì)導(dǎo)致應(yīng)用崩潰,而同步I/O API(例如HttpRequest.Body.Read)是導(dǎo)致線程不足的常見原因。
由此可以知道,這種方式雖然能解決問題,但是性能并不是不好,微軟也不建議這么操作,當(dāng)程序流量比較大的時(shí)候,很容易導(dǎo)致程序不穩(wěn)定甚至崩潰。
異步讀取
通過上面我們了解到微軟并不希望我們通過設(shè)置AllowSynchronousIO
的方式去操作,因?yàn)闀?huì)影響性能。那我們可以使用異步的方式去讀取,這里所說的異步方式其實(shí)就是使用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); }
就這么簡(jiǎn)單,不需要額外設(shè)置其他的東西,僅僅通過ReadToEndAsync
的異步方法去操作。ASP.NET Core中許多操作都是異步操作,甚至是過濾器或中間件都可以直接返回Task類型的方法,因此我們可以直接使用異步操作
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); await next(); }
這兩種方式的操作優(yōu)點(diǎn)是不需要額外設(shè)置別的,只是通過異步方法讀取即可,也是我們比較推薦的做法。比較神奇的是我們只是將StreamReader
的ReadToEnd
替換成ReadToEndAsync
方法就皆大歡喜了,有沒有感覺到比較神奇。當(dāng)我們感到神奇的時(shí)候,是因?yàn)槲覀儗?duì)它還不夠了解,接下來我們就通過源碼的方式,一步一步的揭開它神秘的面紗。
重復(fù)讀取
上面我們演示了使用同步方式和異步方式讀取RequestBody,但是這樣真的就可以了嗎?其實(shí)并不行,這種方式每次請(qǐng)求只能讀取一次正確的Body結(jié)果,如果繼續(xù)對(duì)RequestBody這個(gè)Stream進(jìn)行讀取,將讀取不到任何內(nèi)容,首先來舉個(gè)例子
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); StreamReader stream2 = new StreamReader(context.HttpContext.Request.Body); string body2 = await stream2.ReadToEndAsync(); _logger.LogDebug("body2 content:" + body2); await next(); }
上面的例子中body里有正確的RequestBody的結(jié)果,但是body2中是空字符串。這個(gè)情況是比較糟糕的,為啥這么說呢?如果你是在Middleware中讀取的RequestBody,而這個(gè)中間件的執(zhí)行是在模型綁定之前,那么將會(huì)導(dǎo)致模型綁定失敗,因?yàn)槟P徒壎ㄓ械臅r(shí)候也需要讀取RequestBody獲取http請(qǐng)求內(nèi)容。至于為什么會(huì)這樣相信大家也有了一定的了解,因?yàn)槲覀冊(cè)谧x取完Stream之后,此時(shí)的Stream指針位置已經(jīng)在Stream的結(jié)尾處,即Position此時(shí)不為0,而Stream讀取正是依賴Position來標(biāo)記外部讀取Stream到啥位置,所以我們?cè)俅巫x取的時(shí)候會(huì)從結(jié)尾開始讀,也就讀取不到任何信息了。所以我們要想重復(fù)讀取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(); }
寫完之后,開開心心的運(yùn)行起來看一下效果,發(fā)現(xiàn)報(bào)了一個(gè)錯(cuò)System.NotSupportedException: Specified method is not supported.at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpRequestStream.Seek(Int64 offset, SeekOrigin origin)
大致可以理解起來不支持這個(gè)操作,至于為啥,一會(huì)解析源碼的時(shí)候咱們一起看一下。說了這么多,那到底該如何解決呢?也很簡(jiǎn)單,微軟知道自己刨下了坑,自然給我們提供了解決辦法,用起來也很簡(jiǎn)單就是加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()
我們就可以重復(fù)的讀取RequestBody了,看名字我們可以大概的猜出來,他是和緩存RequestBody有關(guān),需要注意的是Request.EnableBuffering()
要加在準(zhǔn)備讀取RequestBody之前才有效果,否則將無效,而且每次請(qǐng)求只需要添加一次即可
。而且大家看到了我第二次讀取Body的時(shí)候使用了同步的方式去讀取的RequestBody,是不是很神奇,待會(huì)的時(shí)候我們會(huì)從源碼的角度分析這個(gè)問題。
源碼探究
上面我們看到了通過StreamReader
的ReadToEnd
同步讀取Request.Body需要設(shè)置AllowSynchronousIO
為true
才能操作,但是使用StreamReader
的ReadToEndAsync
方法卻可以直接操作。
StreamReader和Stream的關(guān)系
我們看到了都是通過操作StreamReader
的方法即可,那關(guān)我Request.Body啥事,別急咱們先看一看這里的操作,首先來大致看下ReadToEnd
的實(shí)現(xiàn)了解一下StreamReader
到底和Stream有啥關(guān)聯(lián),找到ReadToEnd方法[點(diǎn)擊查看源碼👈]
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(); }
通過這段源碼我們了解到了這么個(gè)信息,一個(gè)是StreamReader
的ReadToEnd
其實(shí)本質(zhì)是通過循環(huán)讀取ReadBuffer然后通過StringBuilder去拼接讀取的內(nèi)容,核心是讀取ReadBuffer方法,由于代碼比較多,我們找到大致呈現(xiàn)一下核心操作[點(diǎn)擊查看源碼👈]
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
其實(shí)是工具類,只是封裝了對(duì)Stream的原始操作,簡(jiǎn)化我們的代碼ReadToEnd
方法本質(zhì)是讀取Stream的Read
方法。接下來我們看一下ReadToEndAsync
方法的具體實(shí)現(xiàn)[點(diǎn)擊查看源碼👈]
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(); }
通過這個(gè)我們可以看到核心操作是ReadBufferAsync
方法,代碼比較多我們同樣看一下核心實(shí)現(xiàn)[點(diǎn)擊查看源碼👈]
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的關(guān)系,否則怕大家誤解這波操作是StreamReader的里的實(shí)現(xiàn),而不是Request.Body的問題,其實(shí)并不是這樣的所有的一切都是指向Stream的Request的Body就是Stream
這個(gè)大家可以自己查看一下,了解到這一步我們就可以繼續(xù)了。
HttpRequest的Body
上面我們說到了Request的Body本質(zhì)就是Stream,Stream本身是抽象類,所以Request.Body是Stream的實(shí)現(xiàn)類。默認(rèn)情況下Request.Body的是HttpRequestStream的實(shí)例[點(diǎn)擊查看源碼👈],我們這里說了是默認(rèn),因?yàn)樗强梢愿淖兊模覀円粫?huì)再說。我們從上面StreamReader的結(jié)論中得到ReadToEnd本質(zhì)還是調(diào)用的Stream的Read方法,即這里的HttpRequestStream的Read方法,我們來看一下具體實(shí)現(xiàn)[點(diǎn)擊查看源碼👈]
public override int Read(byte[] buffer, int offset, int count) { //知道同步讀取Body為啥報(bào)錯(cuò)了吧 if (!_bodyControl.AllowSynchronousIO) { throw new InvalidOperationException(CoreStrings.SynchronousReadsDisallowed); } //本質(zhì)是調(diào)用ReadAsync return ReadAsync(buffer, offset, count).GetAwaiter().GetResult(); }
通過這段代碼我們就可以知道了為啥在不設(shè)置AllowSynchronousIO為true的情下讀取Body會(huì)拋出異常了吧,這個(gè)是程序級(jí)別的控制,而且我們還了解到Read的本質(zhì)還是在調(diào)用ReadAsync異步方法
public override ValueTask<int> ReadAsync(Memory<byte> destination, CancellationToken cancellationToken = default) { return ReadAsyncWrapper(destination, cancellationToken); }
ReadAsync本身并無特殊限制,所以直接操作ReadAsync不會(huì)存在類似Read的異常。
通過這個(gè)我們得出了結(jié)論Request.Body即HttpRequestStream的同步讀取Read會(huì)拋出異常,而異步讀取ReadAsync并不會(huì)拋出異常只和HttpRequestStream的Read方法本身存在判斷AllowSynchronousIO的值有關(guān)系。
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
肯定是有關(guān)系的,因?yàn)槲覀冎慌渲肒estrelServerOptions的是HttpRequestStream的Read是不報(bào)異常的,而HttpRequestStream的Read只依賴了IHttpBodyControlFeature的AllowSynchronousIO屬性。Kestrel中HttpRequestStream初始化的地方在BodyControl[點(diǎn)擊查看源碼👈]
private readonly HttpRequestStream _request; public BodyControl(IHttpBodyControlFeature bodyControl, IHttpResponseControl responseControl) { _request = new HttpRequestStream(bodyControl, _requestReader); }
而初始化BodyControl的地方在HttpProtocol中,我們找到初始化BodyControl的InitializeBodyControl方法[點(diǎn)擊查看源碼👈]
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當(dāng)前實(shí)例。也就是說HttpProtocol是實(shí)現(xiàn)了IHttpBodyControlFeature接口,HttpProtocol本身是partial的,我們?cè)谄渲幸粋€(gè)分布類HttpProtocol.FeatureCollection中看到了實(shí)現(xiàn)關(guān)系
[點(diǎn)擊查看源碼👈]
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; } }
通過這個(gè)可以看出HttpProtocol確實(shí)實(shí)現(xiàn)了IHttpBodyControlFeature接口,接下來我們找到初始化AllowSynchronousIO的地方,找到了AllowSynchronousIO = ServerOptions.AllowSynchronousIO;
這段代碼說明來自于ServerOptions這個(gè)屬性,找到初始化ServerOptions的地方[點(diǎn)擊查看源碼👈]
private HttpConnectionContext _context; //ServiceContext初始化來自HttpConnectionContext public ServiceContext ServiceContext => _context.ServiceContext; protected KestrelServerOptions ServerOptions { get; set; } = default!; public void Initialize(HttpConnectionContext context) { _context = context; //來自ServiceContext ServerOptions = ServiceContext.ServerOptions; Reset(); HttpResponseControl = this; }
通過這個(gè)我們知道ServerOptions來自于ServiceContext的ServerOptions屬性,我們找到給ServiceContext賦值的地方,在KestrelServerImpl的CreateServiceContext方法里[點(diǎn)擊查看源碼👈]精簡(jiǎn)一下邏輯,抽出來核心內(nèi)容大致實(shí)現(xiàn)如下
public KestrelServerImpl( IOptions<KestrelServerOptions> options, IEnumerable<IConnectionListenerFactory> transportFactories, ILoggerFactory loggerFactory) //注入進(jìn)來的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>()
配置的值,總之得到了這么一個(gè)結(jié)論
如果配置了KestrelServerOptions即services.Configure
AllowSynchronousIO屬性能得到相同的效果,畢竟HttpRequestStream是直接依賴的IHttpBodyControlFeature實(shí)例。
EnableBuffering神奇的背后
我們?cè)谏厦娴氖纠锌吹搅?,如果不添加EnableBuffering的話直接設(shè)置RequestBody的Position會(huì)報(bào)NotSupportedException這么一個(gè)錯(cuò)誤,而且加了它之后我居然可以直接使用同步的方式去讀取RequestBody,首先我們來看一下為啥會(huì)報(bào)錯(cuò),我們從上面的錯(cuò)誤了解到錯(cuò)誤來自于HttpRequestStream這個(gè)類[點(diǎn)擊查看源碼👈],上面我們也說了這個(gè)類繼承了Stream抽象類,通過源碼我們可以看到如下相關(guān)代碼
//不能使用Seek操作 public override bool CanSeek => false; //允許讀 public override bool CanRead => true; //不允許寫 public override bool CanWrite => false; //不能獲取長(zhǎng)度 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(); }
相信通過這些我們可以清楚的看到針對(duì)HttpRequestStream的設(shè)置或者寫相關(guān)的操作是不被允許的,這也是為啥我們上面直接通過Seek設(shè)置Position的時(shí)候?yàn)樯稌?huì)報(bào)錯(cuò),還有一些其他操作的限制,總之默認(rèn)是不希望我們對(duì)HttpRequestStream做過多的操作,特別是設(shè)置或者寫相關(guān)的操作。但是我們使用EnableBuffering的時(shí)候卻沒有這些問題,究竟是為什么?接下來我們要揭開它的什么面紗了。首先我們從Request.EnableBuffering()
這個(gè)方法入手,找到源碼位置在HttpRequestRewindExtensions擴(kuò)展類中[點(diǎn)擊查看源碼👈],我們從最簡(jiǎn)單的無參方法開始看到如下定義
/// <summary> /// 確保Request.Body可以被多次讀取 /// </summary> /// <param name="request"></param> public static void EnableBuffering(this HttpRequest request) { BufferingHelper.EnableRewind(request); }
上面的方法是最簡(jiǎn)單的形式,還有一個(gè)EnableBuffering的擴(kuò)展方法是參數(shù)最全的擴(kuò)展方法,這個(gè)方法可以控制讀取的大小和控制是否存儲(chǔ)到磁盤的限定大小
/// <summary> /// 確保Request.Body可以被多次讀取 /// </summary> /// <param name="request"></param> /// <param name="bufferThreshold">內(nèi)存中用于緩沖流的最大大?。ㄗ止?jié))。較大的請(qǐng)求主體被寫入磁盤。</param> /// <param name="bufferLimit">請(qǐng)求正文的最大大?。ㄗ止?jié))。嘗試讀取超過此限制將導(dǎo)致異常</param> public static void EnableBuffering(this HttpRequest request, int bufferThreshold, long bufferLimit) { BufferingHelper.EnableRewind(request, bufferThreshold, bufferLimit); }
無論那種形式,最終都是在調(diào)用BufferingHelper.EnableRewind
這個(gè)方法,話不多說直接找到BufferingHelper這個(gè)類,找到類的位置[點(diǎn)擊查看源碼👈]代碼不多而且比較簡(jiǎn)潔,咱們就把EnableRewind的實(shí)現(xiàn)粘貼出來
//默認(rèn)內(nèi)存中可緩存的大小為30K,超過這個(gè)大小將會(huì)被存儲(chǔ)到磁盤 internal const int DefaultBufferThreshold = 1024 * 30; /// <summary> /// 這個(gè)方法也是HttpRequest擴(kuò)展方法 /// </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 Body var body = request.Body; //默認(rèn)情況Body是HttpRequestStream這個(gè)類CanSeek是false所以肯定會(huì)執(zhí)行到if邏輯里面 if (!body.CanSeek) { //實(shí)例化了FileBufferingReadStream這個(gè)類,看來這是關(guān)鍵所在 var fileStream = new FileBufferingReadStream(body, bufferThreshold,bufferLimit,AspNetCoreTempDirectory.TempDirectoryFactory); //賦值給Body,也就是說開啟了EnableBuffering之后Request.Body類型將會(huì)是FileBufferingReadStream request.Body = fileStream; //這里要把fileStream注冊(cè)給Response便于釋放 request.HttpContext.Response.RegisterForDispose(fileStream); } return request; }
從上面這段源碼實(shí)現(xiàn)中我們可以大致得到兩個(gè)結(jié)論
- BufferingHelper的EnableRewind方法也是HttpRequest的擴(kuò)展方法,可以直接通過
Request.EnableRewind
的形式調(diào)用,效果等同于調(diào)用Request.EnableBuffering
因?yàn)镋nableBuffering也是調(diào)用的EnableRewind - 啟用了EnableBuffering這個(gè)操作之后實(shí)際上會(huì)使用FileBufferingReadStream替換掉默認(rèn)的HttpRequestStream,所以后續(xù)處理RequestBody的操作將會(huì)是FileBufferingReadStream實(shí)例
通過上面的分析我們也清楚的看到了,核心操作在于FileBufferingReadStream
這個(gè)類,而且從名字也能看出來它肯定是也繼承了Stream抽象類,那還等啥直接找到FileBufferingReadStream的實(shí)現(xiàn)[點(diǎn)擊查看源碼👈],首先來看他類的定義
public class FileBufferingReadStream : Stream { }
毋庸置疑確實(shí)是繼承自Steam類,我們上面也看到了使用了Request.EnableBuffering之后就可以設(shè)置和重復(fù)讀取RequestBody,說明進(jìn)行了一些重寫操作,具體我們來看一下
/// <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> /// 可以獲取長(zhǎng)度 /// </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)沒讀取完成但是原始位置信息和當(dāng)前位置信息不一致則直接拋出異常 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的Seek return _buffer.Seek(offset, origin); }
因?yàn)橹貙懥艘恍╆P(guān)鍵設(shè)置,所以我們可以設(shè)置一些流相關(guān)的操作。從Seek方法中我們看到了兩個(gè)比較重要的參數(shù)_completelyBuffered
和_buffer
,_completelyBuffered用來判斷原始的HttpRequestStream是否讀取完成,因?yàn)镕ileBufferingReadStream歸根結(jié)底還是先讀取了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) { //即使我們?cè)O(shè)置memoryThreshold那么它最大也不能超過1MB否則也會(huì)存儲(chǔ)在磁盤上 if (memoryThreshold <= _maxRentedBufferSize) { _rentedBuffer = bytePool.Rent(memoryThreshold); _buffer = new MemoryStream(_rentedBuffer); _buffer.SetLength(0); } else { //超過1M將緩存到磁盤所以僅僅初始化 _buffer = new MemoryStream(); } }
這些都是一些初始化的操作,核心操作當(dāng)然還是在FileBufferingReadStream的Read方法里,因?yàn)檎嬲x取的地方就在這,我們找到Read方法位置[點(diǎn)擊查看源碼👈]
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); } //未讀取完成才會(huì)走到這里 //_inner正是接收的原始的RequestBody //讀取的RequestBody放入buffer中 var read = _inner.Read(buffer); //超過設(shè)定的長(zhǎng)度則會(huì)拋出異常 if (_bufferLimit.HasValue && _bufferLimit - read < _buffer.Length) { throw new IOException("Buffer limit exceeded."); } //如果設(shè)定存儲(chǔ)在內(nèi)存中并且Body長(zhǎng)度大于設(shè)定的可存儲(chǔ)在內(nèi)存中的長(zhǎng)度,則存儲(chǔ)到磁盤中 if (_inMemory && _memoryThreshold - read < _buffer.Length) { _inMemory = false; //緩存原始的Body流 var oldBuffer = _buffer; //創(chuàng)建緩存文件 _buffer = CreateTempFile(); //超過內(nèi)存存儲(chǔ)限制,但是還未寫入過臨時(shí)文件 if (_rentedBuffer == null) { oldBuffer.Position = 0; var rentedBuffer = _bytePool.Rent(Math.Min((int)oldBuffer.Length, _maxRentedBufferSize)); try { //將Body流讀取到緩存文件流中 var copyRead = oldBuffer.Read(rentedBuffer); //判斷是否讀取到結(jié)尾 while (copyRead > 0) { //將oldBuffer寫入到緩存文件流_buffer當(dāng)中 _buffer.Write(rentedBuffer.AsSpan(0, copyRead)); copyRead = oldBuffer.Read(rentedBuffer); } } finally { //讀取完成之后歸還臨時(shí)緩沖區(qū)到ArrayPool中 _bytePool.Return(rentedBuffer); } } else { _buffer.Write(_rentedBuffer.AsSpan(0, (int)oldBuffer.Length)); _bytePool.Return(_rentedBuffer); _rentedBuffer = null; } } //如果讀取RequestBody未到結(jié)尾,則一直寫入到緩存區(qū) if (read > 0) { _buffer.Write(buffer.Slice(0, read)); } else { //如果已經(jīng)讀取RequestBody完畢,也就是寫入到緩存完畢則更新_completelyBuffered //標(biāo)記為以全部讀取RequestBody完成,后續(xù)在讀取RequestBody則直接在_buffer中讀取 _completelyBuffered = true; } //返回讀取的byte個(gè)數(shù)用于外部StreamReader判斷讀取是否完成 return read; }
代碼比較多看著也比較復(fù)雜,其實(shí)核心思路還是比較清晰的,我們來大致的總結(jié)一下
- 首先判斷是否完全的讀取過原始的RequestBody,如果完全完整的讀取過RequestBody則直接在緩沖區(qū)中獲取返回
- 如果RequestBody長(zhǎng)度大于設(shè)定的內(nèi)存存儲(chǔ)限定,則將緩沖寫入磁盤臨時(shí)文件中
- 如果是首次讀取或?yàn)橥耆暾淖x取完成RequestBody,那么將RequestBody的內(nèi)容寫入到緩沖區(qū),知道讀取完成
其中CreateTempFile這是創(chuàng)建臨時(shí)文件的操作流,目的是為了將RequestBody的信息寫入到臨時(shí)文件中。可以指定臨時(shí)文件的地址,若如果不指定則使用系統(tǒng)默認(rèn)目錄,它的實(shí)現(xiàn)如下[點(diǎn)擊查看源碼👈]
private Stream CreateTempFile() { //判斷是否制定過緩存目錄,沒有的話則使用系統(tǒng)臨時(shí)文件目錄 if (_tempFileDirectory == null) { Debug.Assert(_tempFileDirectoryAccessor != null); _tempFileDirectory = _tempFileDirectoryAccessor(); Debug.Assert(_tempFileDirectory != null); } //臨時(shí)文件的完整路徑 _tempFileName = Path.Combine(_tempFileDirectory, "ASPNETCORE_" + Guid.NewGuid().ToString() + ".tmp"); //返回臨時(shí)文件的操作流 return new FileStream(_tempFileName, FileMode.Create, FileAccess.ReadWrite, FileShare.Delete, 1024 * 16, FileOptions.Asynchronous | FileOptions.DeleteOnClose | FileOptions.SequentialScan); }
我們上面分析了FileBufferingReadStream的Read方法這個(gè)方法是同步讀取的方法可供StreamReader的ReadToEnd方法使用,當(dāng)然它還存在一個(gè)異步讀取方法ReadAsync供StreamReader的ReadToEndAsync方法使用。這兩個(gè)方法的實(shí)現(xiàn)邏輯是完全一致的,只是讀取和寫入操作都是異步的操作,這里咱們就不介紹那個(gè)方法了,有興趣的同學(xué)可以自行了解一下ReadAsync
方法的實(shí)現(xiàn)[點(diǎn)擊查看源碼👈]
當(dāng)開啟EnableBuffering的時(shí)候,無論首次讀取是設(shè)置了AllowSynchronousIO為true的ReadToEnd同步讀取方式,還是直接使用ReadToEndAsync的異步讀取方式,那么再次使用ReadToEnd同步方式去讀取Request.Body也便無需去設(shè)置AllowSynchronousIO為true。因?yàn)槟J(rèn)的Request.Body已經(jīng)由HttpRequestStream實(shí)例替換為FileBufferingReadStream實(shí)例,而FileBufferingReadStream重寫了Read和ReadAsync方法,并不存在不允許同步讀取的限制。
總結(jié)
本篇文章篇幅比較多,如果你想深入的研究相關(guān)邏輯,希望本文能給你帶來一些閱讀源碼的指導(dǎo)。為了防止大家深入文章當(dāng)中而忘記了具體的流程邏輯,在這里我們就大致的總結(jié)一下關(guān)于正確讀取RequestBody的全部結(jié)論
- 首先關(guān)于同步讀取Request.Body由于默認(rèn)的RequestBody的實(shí)現(xiàn)是HttpRequestStream,但是HttpRequestStream在重寫Read方法的時(shí)候會(huì)判斷是否開啟AllowSynchronousIO,如果未開啟則直接拋出異常。但是HttpRequestStream的ReadAsync方法并無這種限制,所以使用異步方式的讀取RequestBody并無異常。
- 雖然通過設(shè)置AllowSynchronousIO或使用ReadAsync的方式我們可以讀取RequestBody,但是RequestBody無法重復(fù)讀取,這是因?yàn)镠ttpRequestStream的Position和Seek都是不允許進(jìn)行修改操作的,設(shè)置了會(huì)直接拋出異常。為了可以重復(fù)讀取,我們引入了Request的擴(kuò)展方法EnableBuffering通過這個(gè)方法我們可以重置讀取位置來實(shí)現(xiàn)RequestBody的重復(fù)讀取。
- 關(guān)于開啟EnableBuffering方法每次請(qǐng)求設(shè)置一次即可,即在準(zhǔn)備讀取RequestBody之前設(shè)置。其本質(zhì)其實(shí)是使用FileBufferingReadStream代替默認(rèn)RequestBody的默認(rèn)類型HttpRequestStream,這樣我們?cè)谝淮蜨ttp請(qǐng)求中操作Body的時(shí)候其實(shí)是操作FileBufferingReadStream,這個(gè)類重寫Stream的時(shí)候Position和Seek都是可以設(shè)置的,這樣我們就實(shí)現(xiàn)了重復(fù)讀取。
- FileBufferingReadStream帶給我們的不僅僅是可重復(fù)讀取,還增加了對(duì)RequestBody的緩存功能,使得我們?cè)谝淮握?qǐng)求中重復(fù)讀取RequestBody的時(shí)候可以在Buffer里直接獲取緩存內(nèi)容而Buffer本身是一個(gè)MemoryStream。當(dāng)然我們也可以自己實(shí)現(xiàn)一套邏輯來替換Body,只要我們重寫的時(shí)候讓這個(gè)Stream支持重置讀取位置即可。
到此這篇關(guān)于ASP.NET Core讀取Request.Body的正確方法的文章就介紹到這了,更多相關(guān)ASP.NET Core讀取Request.Body內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
- ASP.NET Core如何注入多個(gè)服務(wù)實(shí)現(xiàn)類
- 理解ASP.NET Core 依賴注入(Dependency Injection)
- asp.net core3.1cookie和jwt混合認(rèn)證授權(quán)實(shí)現(xiàn)多種身份驗(yàn)證方案
- 理解ASP.NET Core 啟動(dòng)類(Startup)
- 理解ASP.NET Core 中間件(Middleware)
- 關(guān)于Jenkins + Docker + ASP.NET Core自動(dòng)化部署的問題(避免踩坑)
- asp.net core MVC之實(shí)現(xiàn)基于token的認(rèn)證
- ASP.NET Core 集成 React SPA應(yīng)用的步驟
- ASP.NET Core 文件響應(yīng)壓縮的常見使用誤區(qū)
- ASP.NET Core中間件初始化的實(shí)現(xiàn)
- ASP.NET Core Web API 教程Project Configuration
相關(guān)文章
Asp.net內(nèi)置對(duì)象之Server對(duì)象(概述及應(yīng)用)
Server對(duì)象提供對(duì)服務(wù)器上的方法和屬性的訪問以及進(jìn)行HTML編碼的功能,本文主要圍繞server對(duì)象介紹詳細(xì)功能及常用屬性和主要方法,感興趣的朋友可以了解下,或許對(duì)你學(xué)習(xí)server對(duì)象有所幫助2013-02-02.NetCore使用ImageSharp進(jìn)行圖片的生成
ImageSharp是對(duì)NetCore平臺(tái)擴(kuò)展的一個(gè)圖像處理方案,以往網(wǎng)上的案例多以生成文字及畫出簡(jiǎn)單圖形、驗(yàn)證碼等方式進(jìn)行探討和實(shí)踐,今天我分享一下所在公司項(xiàng)目的實(shí)際應(yīng)用案例,導(dǎo)出微信二維碼圖片,圓形頭像,感興趣的朋友一起看看吧2022-06-06DataTable數(shù)據(jù)導(dǎo)出成Excel文件的小例子
DataTable數(shù)據(jù)導(dǎo)出成Excel文件的小例子,需要的朋友可以參考一下2013-04-04ASP.NET Core應(yīng)用錯(cuò)誤處理之StatusCodePagesMiddleware中間件針對(duì)響應(yīng)碼呈現(xiàn)錯(cuò)誤頁(yè)面
這篇文章主要給大家介紹了關(guān)于ASP.NET Core應(yīng)用錯(cuò)誤處理之StatusCodePagesMiddleware中間件針對(duì)響應(yīng)碼呈現(xiàn)錯(cuò)誤頁(yè)面的相關(guān)資料,需要的朋友可以參考下2019-01-01.NET Core讀取配置文件方式詳細(xì)總結(jié)
這篇文章主要為大家詳細(xì)總結(jié)了.NET Core讀取配置文件方式,具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2018-08-08使用SNK密鑰文件保護(hù)你的DLL和代碼不被反編譯教程
這篇文章主要介紹了使用SNK密鑰文件保護(hù)你的DLL和代碼不被反編譯教程, SNK,作為程序后綴的時(shí)候,是.net中的強(qiáng)密匙加密文件,需要的朋友可以參考下2014-09-09