亚洲乱码中文字幕综合,中国熟女仑乱hd,亚洲精品乱拍国产一区二区三区,一本大道卡一卡二卡三乱码全集资源,又粗又黄又硬又爽的免费视频

ASP.NET Core讀取Request.Body的正確方法

 更新時(shí)間:2021年05月28日 10:48:46   作者:yi念之間  
相信大家在使用ASP.NET Core進(jìn)行開發(fā)的時(shí)候,肯定會(huì)涉及到讀取Request.Body的場(chǎng)景,畢竟我們大部分的POST請(qǐng)求都是將數(shù)據(jù)存放到Http的Body當(dāng)中,本文就介紹一下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è)置AllowSynchronousIOtrue的方式,看名字也知道是允許同步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è)置AllowSynchronousIOtrue,但是我們需要思考一點(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è)置別的,只是通過異步方法讀取即可,也是我們比較推薦的做法。比較神奇的是我們只是將StreamReaderReadToEnd替換成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è)問題。

源碼探究

上面我們看到了通過StreamReaderReadToEnd同步讀取Request.Body需要設(shè)置AllowSynchronousIOtrue才能操作,但是使用StreamReaderReadToEndAsync方法卻可以直接操作。

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è)是StreamReaderReadToEnd其實(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來自于KestrelServerOptions。即IHttpBodyControlFeature的AllowSynchronousIO屬性來自于KestrelServerOptions。如果沒有配置,那么直接通過修改IHttpBodyControlFeature實(shí)例的
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)文章希望大家以后多多支持腳本之家!

相關(guān)文章

最新評(píng)論