深入探究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的理解，關於講解內容筆者深知自己能力有限，理解的不一定透徹，甚至理解的不一定對，還望大家多多諒解，也歡迎大家能夠多多交流。

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