深入探究ASP.NET Core讀取Request.Body的正確方式

前言

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

常用讀取方式

當我們要讀取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);
}

寫完之後，也沒多想，畢竟這麼常規的操作，信心滿滿，運行起來調試一把，發現直接報一個這個錯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，說明微軟並不希望我們去同步讀取Body。通過查找資料得出了這麼一個結論

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

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

異步讀取

通過上面我們瞭解到微軟並不希望我們通過設置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類型的方法，因此我們可以直接使用異步操作

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();
}

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

重複讀取

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

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的結果，但是body2中是空字符串。這個情況是比較糟糕的，爲啥這麼說呢？如果你是在Middleware中讀取的RequestBody，而這個中間件的執行是在模型綁定之前，那麼將會導致模型綁定失敗，因爲模型綁定有的時候也需要讀取RequestBody獲取http請求內容。至於爲什麼會這樣相信大家也有了一定的瞭解，因爲我們在讀取完Stream之後，此時的Stream指針位置已經在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;
    //如果你確定上次讀取完之後已經重置了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();
}

寫完之後，開開心心的運行起來看一下效果，發現報了一個錯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);
    //注意這裏！！！我已經使用了同步讀取的方式
    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的實現瞭解一下StreamReader到底和Stream有啥關聯，找到ReadToEnd方法[點擊查看源碼👈]

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

通過這段源碼我們瞭解到了這麼個信息，一個是StreamReader的ReadToEnd其實本質是通過循環讀取ReadBuffer然後通過StringBuilder去拼接讀取的內容，核心是讀取ReadBuffer方法，由於代碼比較多，我們找到大致呈現一下核心操作[點擊查看源碼👈]

if (_checkPreamble)
{
    //通過這裏我們可以知道本質就是使用要讀取的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
{
    //通過這裏我們可以知道本質就是使用要讀取的Stream裏的Read方法
    _byteLen = _stream.Read(_byteBuffer, 0, _byteBuffer.Length);
    if (_byteLen == 0) 
    {
        return _charLen;
    }
}

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

public override Task<string> ReadToEndAsync()
{
    if (GetType() != typeof(StreamReader))
    {
        return base.ReadToEndAsync();
    }
    ThrowIfDisposed();
    CheckAsyncTaskInProgress();
    //本質是ReadToEndAsyncInternal方法
    Task<string> task = ReadToEndAsyncInternal();
    _asyncReadTask = task;

    return task;
}

private async Task<string> ReadToEndAsyncInternal()
{
    //也是循環拼接讀取的內容
    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方法，代碼比較多我們同樣看一下核心實現[點擊查看源碼👈]

byte[] tmpByteBuffer = _byteBuffer;
//Stream賦值給tmpStream 
Stream tmpStream = _stream;
if (_checkPreamble)
{
    int tmpBytePos = _bytePos;
    //本質是調用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
{
    //本質是調用Stream的ReadAsync方法
    _byteLen = await tmpStream.ReadAsync(new Memory<byte>(tmpByteBuffer), cancellationToken).ConfigureAwait(false);
    if (_byteLen == 0) 
    {
        return _charLen;
    }
}

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

HttpRequest的Body

上面我們說到了Request的Body本質就是Stream，Stream本身是抽象類，所以Request.Body是Stream的實現類。默認情況下Request.Body的是HttpRequestStream的實例[點擊查看源碼👈]，我們這裏說了是默認，因爲它是可以改變的，我們一會再說。我們從上面StreamReader的結論中得到ReadToEnd本質還是調用的Stream的Read方法，即這裏的HttpRequestStream的Read方法，我們來看一下具體實現[點擊查看源碼👈]

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

通過這段代碼我們就可以知道了爲啥在不設置AllowSynchronousIO爲true的情下讀取Body會拋出異常了吧，這個是程序級別的控制，而且我們還了解到Read的本質還是在調用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本質來源

通過HttpRequestStream的Read方法我們可以知道AllowSynchronousIO控制了同步讀取的方式。而且我們還了解到了AllowSynchronousIO有幾種不同方式的去配置，接下來我們來大致看下幾種方式的本質是哪一種。通過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[點擊查看源碼👈]

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

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

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是實現了IHttpBodyControlFeature接口，HttpProtocol本身是partial的，我們在其中一個分佈類HttpProtocol.FeatureCollection中看到了實現關係
[點擊查看源碼👈]

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確實實現了IHttpBodyControlFeature接口，接下來我們找到初始化AllowSynchronousIO的地方，找到了AllowSynchronousIO = ServerOptions.AllowSynchronousIO;這段代碼說明來自於ServerOptions這個屬性，找到初始化ServerOptions的地方[點擊查看源碼👈]

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;
}

通過這個我們知道ServerOptions來自於ServiceContext的ServerOptions屬性，我們找到給ServiceContext賦值的地方，在KestrelServerImpl的CreateServiceContext方法裏[點擊查看源碼👈]精簡一下邏輯，抽出來核心內容大致實現如下

public KestrelServerImpl(
   IOptions<KestrelServerOptions> options,
   IEnumerable<IConnectionListenerFactory> transportFactories,
   ILoggerFactory loggerFactory)     
   //注入進來的IOptions<KestrelServerOptions>調用了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這個類[點擊查看源碼👈]，上面我們也說了這個類繼承了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擴展類中[點擊查看源碼👈]，我們從最簡單的無參方法開始看到如下定義

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

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

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

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

//默認內存中可緩存的大小爲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 Body
    var body = request.Body;
    //默認情況Body是HttpRequestStream這個類CanSeek是false所以肯定會執行到if邏輯裏面
    if (!body.CanSeek)
    {
        //實例化了FileBufferingReadStream這個類，看來這是關鍵所在
        var fileStream = new FileBufferingReadStream(body, bufferThreshold,bufferLimit,AspNetCoreTempDirectory.TempDirectoryFactory);
        //賦值給Body，也就是說開啓了EnableBuffering之後Request.Body類型將會是FileBufferingReadStream
        request.Body = fileStream;
        //這裏要把fileStream註冊給Response便於釋放
        request.HttpContext.Response.RegisterForDispose(fileStream);
    }
    return request;
}

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

• BufferingHelper的EnableRewind方法也是HttpRequest的擴展方法，可以直接通過Request.EnableRewind的形式調用，效果等同於調用Request.EnableBuffering因爲EnableBuffering也是調用的EnableRewind
• 啓用了EnableBuffering這個操作之後實際上會使用FileBufferingReadStream替換掉默認的HttpRequestStream，所以後續處理RequestBody的操作將會是FileBufferingReadStream實例

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

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
    //出現沒讀取完成但是原始位置信息和當前位置信息不一致則直接拋出異常
    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);
}

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

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方法位置[點擊查看源碼👈]

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.");
    }
    //如果設定存儲在內存中並且Body長度大於設定的可存儲在內存中的長度,則存儲到磁盤中
    if (_inMemory && _memoryThreshold - read < _buffer.Length)
    {
        _inMemory = false;
        //緩存原始的Body流
        var oldBuffer = _buffer;
        //創建緩存文件
        _buffer = CreateTempFile();
        //超過內存存儲限制，但是還未寫入過臨時文件
        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
            {
                //讀取完成之後歸還臨時緩衝區到ArrayPool中
                _bytePool.Return(rentedBuffer);
            }
        }
        else
        {
            
            _buffer.Write(_rentedBuffer.AsSpan(0, (int)oldBuffer.Length));
            _bytePool.Return(_rentedBuffer);
            _rentedBuffer = null;
        }
    }

    //如果讀取RequestBody未到結尾,則一直寫入到緩存區
    if (read > 0)
    {
        _buffer.Write(buffer.Slice(0, read));
    }
    else
    {
        //如果已經讀取RequestBody完畢，也就是寫入到緩存完畢則更新_completelyBuffered
        //標記爲以全部讀取RequestBody完成，後續在讀取RequestBody則直接在_buffer中讀取
        _completelyBuffered = true;
    }
    //返回讀取的byte個數用於外部StreamReader判斷讀取是否完成
    return read;
}

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

• 首先判斷是否完全的讀取過原始的RequestBody,如果完全完整的讀取過RequestBody則直接在緩衝區中獲取返回
• 如果RequestBody長度大於設定的內存存儲限定，則將緩衝寫入磁盤臨時文件中
• 如果是首次讀取或爲完全完整的讀取完成RequestBody，那麼將RequestBody的內容寫入到緩衝區，知道讀取完成

其中CreateTempFile這是創建臨時文件的操作流，目的是爲了將RequestBody的信息寫入到臨時文件中。可以指定臨時文件的地址，若如果不指定則使用系統默認目錄，它的實現如下[點擊查看源碼👈]

private Stream CreateTempFile()
{
    //判斷是否制定過緩存目錄，沒有的話則使用系統臨時文件目錄
    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方法使用。這兩個方法的實現邏輯是完全一致的，只是讀取和寫入操作都是異步的操作，這裏咱們就不介紹那個方法了，有興趣的同學可以自行了解一下ReadAsync方法的實現[點擊查看源碼👈]

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

總結

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

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

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

👇歡迎掃碼關注我的公衆號👇