ASP.NET Core讀取Request.Body的正確方法
前言
相信大家在使用ASP.NET Core進行開發(fā)的時候，肯定會涉及到讀取Request.Body的場景，畢竟我們大部分的POST請求都是將數據存放到Http的Body當中。因為筆者日常開發(fā)所使用的主要也是ASP.NET Core所以筆者也遇到這這種場景，關于本篇文章所套路的內容，來自于在開發(fā)過程中我遇到的關于Request.Body的讀取問題。在之前的使用的時候，基本上都是借助搜索引擎搜索的答案，并沒有太關注這個，發(fā)現自己理解的和正確的使用之間存在很大的誤區(qū)。故有感而發(fā)，便寫下此文，以作記錄。學無止境，愿與君共勉。
常用讀取方式
當我們要讀取Request Body的時候，相信大家第一直覺和筆者是一樣的，這有啥難的，直接幾行代碼寫完，這里我們模擬在Filter中讀取Request Body，在Action或Middleware或其他地方讀取類似，有Request的地方就有Body，如下所示
public override void OnActionExecuting(ActionExecutingContext context)
{
//在ASP.NET Core中Request Body是Stream的形式
StreamReader stream = new StreamReader(context.HttpContext.Request.Body);
string body = stream.ReadToEnd();
_logger.LogDebug("body content:" + body);
base.OnActionExecuting(context);
}
寫完之后，也沒多想，畢竟這么常規(guī)的操作，信心滿滿，運行起來調試一把，發(fā)現直接報一個這個錯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）是導致線程不足的常見原因。
由此可以知道，這種方式雖然能解決問題，但是性能并不是不好，微軟也不建議這么操作，當程序流量比較大的時候，很容易導致程序不穩(wěn)定甚至崩潰。
異步讀取
通過上面我們了解到微軟并不希望我們通過設置AllowSynchronousIO的方式去操作，因為會影響性能。那我們可以使用異步的方式去讀取，這里所說的異步方式其實就是使用Stream自帶的異步方法去讀取，如下所示
public override void OnActionExecuting(ActionExecutingContext context)
{
StreamReader stream = new StreamReader(context.HttpContext.Request.Body);
string body = stream.ReadToEndAsync().GetAwaiter().GetResult();
_logger.LogDebug("body content:" + body);
base.OnActionExecuting(context);
}
就這么簡單，不需要額外設置其他的東西，僅僅通過ReadToEndAsync的異步方法去操作。ASP.NET Core中許多操作都是異步操作，甚至是過濾器或中間件都可以直接返回Task類型的方法，因此我們可以直接使用異步操作
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)點是不需要額外設置別的，只是通過異步方法讀取即可，也是我們比較推薦的做法。比較神奇的是我們只是將StreamReader的ReadToEnd替換成ReadToEndAsync方法就皆大歡喜了，有沒有感覺到比較神奇。當我們感到神奇的時候，是因為我們對它還不夠了解，接下來我們就通過源碼的方式，一步一步的揭開它神秘的面紗。
重復讀取
上面我們演示了使用同步方式和異步方式讀取RequestBody，但是這樣真的就可以了嗎？其實并不行，這種方式每次請求只能讀取一次正確的Body結果，如果繼續(xù)對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，而這個中間件的執(zhí)行是在模型綁定之前，那么將會導致模型綁定失敗，因為模型綁定有的時候也需要讀取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();
}
寫完之后，開開心心的運行起來看一下效果，發(fā)現報了一個錯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
{
//循環(huán)拼接讀取內容
sb.Append(_charBuffer, _charPos, _charLen - _charPos);
_charPos = _charLen;
//讀取buffer，這是核心操作
ReadBuffer();
} while (_charLen > 0);
//返回讀取內容
return sb.ToString();
}
通過這段源碼我們了解到了這么個信息，一個是StreamReader的ReadToEnd其實本質是通過循環(huán)讀取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()
{
//也是循環(huán)拼接讀取的內容
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這個大家可以自己查看一下，了解到這一步我們就可以繼續(xù)了。
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屬性能得到相同的效果，畢竟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">內存中用于緩沖流的最大大?。ㄗ止?jié)）。較大的請求主體被寫入磁盤。</param>
/// <param name="bufferLimit">請求正文的最大大小（字節(jié)）。嘗試讀取超過此限制將導致異常</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所以肯定會執(zhí)行到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，所以后續(xù)處理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;
//創(chuàng)建緩存文件
_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
{
//讀取完成之后歸還臨時緩沖區(qū)到ArrayPool中
_bytePool.Return(rentedBuffer);
}
}
else
{
_buffer.Write(_rentedBuffer.AsSpan(0, (int)oldBuffer.Length));
_bytePool.Return(_rentedBuffer);
_rentedBuffer = null;
}
}
//如果讀取RequestBody未到結尾,則一直寫入到緩存區(qū)
if (read > 0)
{
_buffer.Write(buffer.Slice(0, read));
}
else
{
//如果已經讀取RequestBody完畢，也就是寫入到緩存完畢則更新_completelyBuffered
//標記為以全部讀取RequestBody完成，后續(xù)在讀取RequestBody則直接在_buffer中讀取
_completelyBuffered = true;
}
//返回讀取的byte個數用于外部StreamReader判斷讀取是否完成
return read;
}
代碼比較多看著也比較復雜，其實核心思路還是比較清晰的，我們來大致的總結一下
- 首先判斷是否完全的讀取過原始的RequestBody,如果完全完整的讀取過RequestBody則直接在緩沖區(qū)中獲取返回
- 如果RequestBody長度大于設定的內存存儲限定，則將緩沖寫入磁盤臨時文件中
- 如果是首次讀取或為完全完整的讀取完成RequestBody，那么將RequestBody的內容寫入到緩沖區(qū)，知道讀取完成
其中CreateTempFile這是創(chuàng)建臨時文件的操作流，目的是為了將RequestBody的信息寫入到臨時文件中。可以指定臨時文件的地址，若如果不指定則使用系統(tǒng)默認目錄，它的實現如下[點擊查看源碼👈]
private Stream CreateTempFile()
{
//判斷是否制定過緩存目錄，沒有的話則使用系統(tǒng)臨時文件目錄
if (_tempFileDirectory == null)
{
Debug.Assert(_tempFileDirectoryAccessor != null);
_tempFileDirectory = _tempFileDirectoryAccessor();
Debug.Assert(_tempFileDirectory != null);
}
//臨時文件的完整路徑
_tempFileName = Path.Combine(_tempFileDirectory, "ASPNETCORE_" + Guid.NewGuid().ToString() + ".tmp");
//返回臨時文件的操作流
return new FileStream(_tempFileName, FileMode.Create, FileAccess.ReadWrite, FileShare.Delete, 1024 * 16,
FileOptions.Asynchronous | FileOptions.DeleteOnClose | FileOptions.SequentialScan);
}
我們上面分析了FileBufferingReadStream的Read方法這個方法是同步讀取的方法可供StreamReader的ReadToEnd方法使用，當然它還存在一個異步讀取方法ReadAsync供StreamReader的ReadToEndAsync方法使用。這兩個方法的實現邏輯是完全一致的，只是讀取和寫入操作都是異步的操作，這里咱們就不介紹那個方法了，有興趣的同學可以自行了解一下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支持重置讀取位置即可。
到此這篇關于ASP.NET Core讀取Request.Body的正確方法的文章就介紹到這了,更多相關ASP.NET Core讀取Request.Body內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！
- ASP.NET Core如何注入多個服務實現類
- 理解ASP.NET Core 依賴注入(Dependency Injection)
- asp.net core3.1cookie和jwt混合認證授權實現多種身份驗證方案
- 理解ASP.NET Core 啟動類(Startup)
- 理解ASP.NET Core 中間件(Middleware)
- 關于Jenkins + Docker + ASP.NET Core自動化部署的問題(避免踩坑)
- asp.net core MVC之實現基于token的認證
- ASP.NET Core 集成 React SPA應用的步驟
- ASP.NET Core 文件響應壓縮的常見使用誤區(qū)
- ASP.NET Core中間件初始化的實現
- ASP.NET Core Web API 教程Project Configuration
相關文章
Server對象提供對服務器上的方法和屬性的訪問以及進行HTML編碼的功能,本文主要圍繞server對象介紹詳細功能及常用屬性和主要方法，感興趣的朋友可以了解下，或許對你學習server對象有所幫助2013-02-02
ImageSharp是對NetCore平臺擴展的一個圖像處理方案，以往網上的案例多以生成文字及畫出簡單圖形、驗證碼等方式進行探討和實踐，今天我分享一下所在公司項目的實際應用案例，導出微信二維碼圖片，圓形頭像，感興趣的朋友一起看看吧2022-06-06
這篇文章主要為大家詳細介紹了MVC4制作網站教程，瀏覽欄目功能實現代碼，具有一定的參考價值，感興趣的小伙伴們可以參考一下2016-08-08
DataTable數據導出成Excel文件的小例子，需要的朋友可以參考一下2013-04-04
ASP.NET Core應用錯誤處理之StatusCodePagesMiddleware中間件針對響應碼呈現錯誤頁面
這篇文章主要給大家介紹了關于ASP.NET Core應用錯誤處理之StatusCodePagesMiddleware中間件針對響應碼呈現錯誤頁面的相關資料,需要的朋友可以參考下2019-01-01
這篇文章主要為大家詳細總結了.NET Core讀取配置文件方式，具有一定的參考價值，感興趣的小伙伴們可以參考一下2018-08-08
本文詳細講解了LINQ的操作語法，文中通過示例代碼介紹的非常詳細。對大家的學習或工作具有一定的參考借鑒價值，需要的朋友可以參考下2022-03-03
這篇文章主要介紹了使用SNK密鑰文件保護你的DLL和代碼不被反編譯教程, SNK,作為程序后綴的時候,是.net中的強密匙加密文件,需要的朋友可以參考下2014-09-09
這篇文章主要給大家介紹了關于.NET下模擬數組越界的相關資料，文中通過圖文介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習學習吧2019-01-01
這篇文章介紹了ASP.NET Core處理錯誤環(huán)境的方法，文中通過示例代碼介紹的非常詳細。對大家的學習或工作具有一定的參考借鑒價值，需要的朋友可以參考下2022-04-04