asp.net core讀取request.body的正確方法
前言
相信大家在使用asp.net core進(jìn)行開(kāi)發(fā)的時(shí)候，肯定會(huì)涉及到讀取request.body的場(chǎng)景，畢竟我們大部分的post請(qǐng)求都是將數(shù)據(jù)存放到http的body當(dāng)中。因?yàn)楣P者日常開(kāi)發(fā)所使用的主要也是asp.net core所以筆者也遇到這這種場(chǎng)景，關(guān)于本篇文章所套路的內(nèi)容，來(lái)自于在開(kāi)發(fā)過(guò)程中我遇到的關(guān)于request.body的讀取問(wèn)題。在之前的使用的時(shí)候，基本上都是借助搜索引擎搜索的答案，并沒(méi)有太關(guān)注這個(gè)，發(fā)現(xiàn)自己理解的和正確的使用之間存在很大的誤區(qū)。故有感而發(fā)，便寫(xiě)下此文，以作記錄。學(xué)無(wú)止境，愿與君共勉。
常用讀取方式
當(dāng)我們要讀取request body的時(shí)候，相信大家第一直覺(jué)和筆者是一樣的，這有啥難的，直接幾行代碼寫(xiě)完，這里我們模擬在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);
}
寫(xiě)完之后，也沒(méi)多想，畢竟這么常規(guī)的操作，信心滿滿，運(yùn)行起來(lái)調(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。雖然沒(méi)說(shuō)怎么設(shè)置allowsynchronousio，不過(guò)我們借助搜索引擎是我們最大的強(qiáng)項(xiàng)。
同步讀取
首先我們來(lái)看設(shè)置allowsynchronousio為true的方式，看名字也知道是允許同步io，設(shè)置方式大致有兩種，待會(huì)我們會(huì)通過(guò)源碼來(lái)探究一下它們直接有何不同，我們先來(lái)看一下如何設(shè)置allowsynchronousio的值。第一種方式是在configureservices中配置，操作如下
services.configure<kestrelserveroptions>(options =>
{
options.allowsynchronousio = true;
});
這種方式和在配置文件中配置kestrel選項(xiàng)配置是一樣的只是方式不同，設(shè)置完之后即可，運(yùn)行不在報(bào)錯(cuò)。還有一種方式，可以不用在configureservices中設(shè)置，通過(guò)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);
}
這種方式同樣有效，通過(guò)這種方式操作，不需要每次讀取body的時(shí)候都去設(shè)置，只要在準(zhǔn)備讀取body之前設(shè)置一次即可。這兩種方式都是去設(shè)置allowsynchronousio為true，但是我們需要思考一點(diǎn)，微軟為何設(shè)置allowsynchronousio默認(rèn)為false，說(shuō)明微軟并不希望我們?nèi)ネ阶x取body。通過(guò)查找資料得出了這么一個(gè)結(jié)論
kestrel：默認(rèn)情況下禁用 allowsynchronousio（同步io），線程不足會(huì)導(dǎo)致應(yīng)用崩潰，而同步i/o api（例如httprequest.body.read）是導(dǎo)致線程不足的常見(jiàn)原因。
由此可以知道，這種方式雖然能解決問(wèn)題，但是性能并不是不好，微軟也不建議這么操作，當(dāng)程序流量比較大的時(shí)候，很容易導(dǎo)致程序不穩(wěn)定甚至崩潰。
異步讀取
通過(guò)上面我們了解到微軟并不希望我們通過(guò)設(shè)置allowsynchronousio的方式去操作，因?yàn)闀?huì)影響性能。那我們可以使用異步的方式去讀取，這里所說(shuō)的異步方式其實(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è)置其他的東西，僅僅通過(guò)readtoendasync的異步方法去操作。asp.net core中許多操作都是異步操作，甚至是過(guò)濾器或中間件都可以直接返回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è)置別的，只是通過(guò)異步方法讀取即可，也是我們比較推薦的做法。比較神奇的是我們只是將streamreader的readtoend替換成readtoendasync方法就皆大歡喜了，有沒(méi)有感覺(jué)到比較神奇。當(dāng)我們感到神奇的時(shí)候，是因?yàn)槲覀儗?duì)它還不夠了解，接下來(lái)我們就通過(guò)源碼的方式，一步一步的揭開(kāi)它神秘的面紗。
重復(fù)讀取
上面我們演示了使用同步方式和異步方式讀取requestbody，但是這樣真的就可以了嗎？其實(shí)并不行，這種方式每次請(qǐng)求只能讀取一次正確的body結(jié)果，如果繼續(xù)對(duì)requestbody這個(gè)stream進(jìn)行讀取，將讀取不到任何內(nèi)容，首先來(lá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è)情況是比較糟糕的，為啥這么說(shuō)呢？如果你是在middleware中讀取的requestbody，而這個(gè)中間件的執(zhí)行是在模型綁定之前，那么將會(huì)導(dǎo)致模型綁定失敗，因?yàn)槟Ｐ徒壎ㄓ械臅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來(lái)標(biāo)記外部讀取stream到啥位置，所以我們?cè)俅巫x取的時(shí)候會(huì)從結(jié)尾開(kāi)始讀，也就讀取不到任何信息了。所以我們要想重復(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();
}
寫(xiě)完之后，開(kāi)開(kāi)心心的運(yùn)行起來(lái)看一下效果，發(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)大致可以理解起來(lái)不支持這個(gè)操作，至于為啥，一會(huì)解析源碼的時(shí)候咱們一起看一下。說(shuō)了這么多，那到底該如何解決呢？也很簡(jiǎn)單，微軟知道自己刨下了坑，自然給我們提供了解決辦法，用起來(lái)也很簡(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();
}
通過(guò)添加request.enablebuffering()我們就可以重復(fù)的讀取requestbody了，看名字我們可以大概的猜出來(lái)，他是和緩存requestbody有關(guān)，需要注意的是request.enablebuffering()要加在準(zhǔn)備讀取requestbody之前才有效果，否則將無(wú)效，而且每次請(qǐng)求只需要添加一次即可。而且大家看到了我第二次讀取body的時(shí)候使用了同步的方式去讀取的requestbody，是不是很神奇，待會(huì)的時(shí)候我們會(huì)從源碼的角度分析這個(gè)問(wèn)題。
源碼探究
上面我們看到了通過(guò)streamreader的readtoend同步讀取request.body需要設(shè)置allowsynchronousio為true才能操作，但是使用streamreader的readtoendasync方法卻可以直接操作。
streamreader和stream的關(guān)系
我們看到了都是通過(guò)操作streamreader的方法即可，那關(guān)我request.body啥事，別急咱們先看一看這里的操作，首先來(lái)大致看下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();
}
通過(guò)這段源碼我們了解到了這么個(gè)信息，一個(gè)是streamreader的readtoend其實(shí)本質(zhì)是通過(guò)循環(huán)讀取readbuffer然后通過(guò)stringbuilder去拼接讀取的內(nèi)容，核心是讀取readbuffer方法，由于代碼比較多，我們找到大致呈現(xiàn)一下核心操作[點(diǎn)擊查看源碼👈]
if (_checkpreamble)
{
//通過(guò)這里我們可以知道本質(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
{
//通過(guò)這里我們可以知道本質(zhì)就是使用要讀取的stream里的read方法
_bytelen = _stream.read(_bytebuffer, 0, _bytebuffer.length);
if (_bytelen == 0)
{
return _charlen;
}
}
通過(guò)上面的代碼我們可以了解到streamreader其實(shí)是工具類，只是封裝了對(duì)stream的原始操作，簡(jiǎn)化我們的代碼readtoend方法本質(zhì)是讀取stream的read方法。接下來(lái)我們看一下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();
}
通過(guò)這個(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;
}
}
通過(guò)上面代碼我可以了解到streamreader的本質(zhì)就是讀取stream的包裝，核心方法還是來(lái)自stream本身。我們之所以大致介紹了streamreader類，就是為了給大家呈現(xiàn)出streamreader和stream的關(guān)系，否則怕大家誤解這波操作是streamreader的里的實(shí)現(xiàn)，而不是request.body的問(wèn)題，其實(shí)并不是這樣的所有的一切都是指向stream的request的body就是stream這個(gè)大家可以自己查看一下，了解到這一步我們就可以繼續(xù)了。
httprequest的body
上面我們說(shuō)到了request的body本質(zhì)就是stream，stream本身是抽象類，所以request.body是stream的實(shí)現(xiàn)類。默認(rèn)情況下request.body的是httprequeststream的實(shí)例[點(diǎn)擊查看源碼👈]，我們這里說(shuō)了是默認(rèn)，因?yàn)樗强梢愿淖兊?，我們一?huì)再說(shuō)。我們從上面streamreader的結(jié)論中得到readtoend本質(zhì)還是調(diào)用的stream的read方法，即這里的httprequeststream的read方法，我們來(lái)看一下具體實(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();
}
通過(guò)這段代碼我們就可以知道了為啥在不設(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本身并無(wú)特殊限制，所以直接操作readasync不會(huì)存在類似read的異常。
通過(guò)這個(gè)我們得出了結(jié)論request.body即httprequeststream的同步讀取read會(huì)拋出異常，而異步讀取readasync并不會(huì)拋出異常只和httprequeststream的read方法本身存在判斷allowsynchronousio的值有關(guān)系。
allowsynchronousio本質(zhì)來(lái)源
通過(guò)httprequeststream的read方法我們可以知道allowsynchronousio控制了同步讀取的方式。而且我們還了解到了allowsynchronousio有幾種不同方式的去配置，接下來(lái)我們來(lái)大致看下幾種方式的本質(zhì)是哪一種。通過(guò)httprequeststream我們知道read方法中的allowsynchronousio的屬性是來(lái)自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í)例。也就是說(shuō)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;
}
}
通過(guò)這個(gè)可以看出httpprotocol確實(shí)實(shí)現(xiàn)了ihttpbodycontrolfeature接口，接下來(lái)我們找到初始化allowsynchronousio的地方，找到了allowsynchronousio = serveroptions.allowsynchronousio;這段代碼說(shuō)明來(lái)自于serveroptions這個(gè)屬性，找到初始化serveroptions的地方[點(diǎn)擊查看源碼👈]
private httpconnectioncontext _context;
//servicecontext初始化來(lái)自httpconnectioncontext
public servicecontext servicecontext => _context.servicecontext;
protected kestrelserveroptions serveroptions { get; set; } = default!;
public void initialize(httpconnectioncontext context)
{
_context = context;
//來(lái)自servicecontext
serveroptions = servicecontext.serveroptions;
reset();
httpresponsecontrol = this;
}
通過(guò)這個(gè)我們知道serveroptions來(lái)自于servicecontext的serveroptions屬性，我們找到給servicecontext賦值的地方，在kestrelserverimpl的createservicecontext方法里[點(diǎn)擊查看源碼👈]精簡(jiǎn)一下邏輯，抽出來(lái)核心內(nèi)容大致實(shí)現(xiàn)如下
public kestrelserverimpl(
ioptions<kestrelserveroptions> options,
ienumerable<iconnectionlistenerfactory> transportfactories,
iloggerfactory loggerfactory)
//注入進(jìn)來(lái)的ioptions<kestrelserveroptions>調(diào)用了createservicecontext
: this(transportfactories, null, createservicecontext(options, loggerfactory))
{
}
private static servicecontext createservicecontext(ioptions<kestrelserveroptions> options, iloggerfactory loggerfactory)
{
//值來(lái)自于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,
};
}
通過(guò)上面的代碼我們可以看到如果配置了kestrelserveroptions那么servicecontext的serveroptions屬性就來(lái)自于kestrelserveroptions，即我們通過(guò)services.configure<kestrelserveroptions>()配置的值，總之得到了這么一個(gè)結(jié)論
如果配置了kestrelserveroptions即services.configure()，那么allowsynchronousio來(lái)自于kestrelserveroptions。即ihttpbodycontrolfeature的allowsynchronousio屬性來(lái)自于kestrelserveroptions。如果沒(méi)有配置，那么直接通過(guò)修改ihttpbodycontrolfeature實(shí)例的
allowsynchronousio屬性能得到相同的效果，畢竟httprequeststream是直接依賴的ihttpbodycontrolfeature實(shí)例。
enablebuffering神奇的背后
我們?cè)谏厦娴氖纠锌吹搅?，如果不添加enablebuffering的話直接設(shè)置requestbody的position會(huì)報(bào)notsupportedexception這么一個(gè)錯(cuò)誤，而且加了它之后我居然可以直接使用同步的方式去讀取requestbody，首先我們來(lái)看一下為啥會(huì)報(bào)錯(cuò)，我們從上面的錯(cuò)誤了解到錯(cuò)誤來(lái)自于httprequeststream這個(gè)類[點(diǎn)擊查看源碼👈]，上面我們也說(shuō)了這個(gè)類繼承了stream抽象類,通過(guò)源碼我們可以看到如下相關(guān)代碼
//不能使用seek操作
public override bool canseek => false;
//允許讀
public override bool canread => true;
//不允許寫(xiě)
public override bool canwrite => false;
//不能獲取長(zhǎng)度
public override long length => throw new notsupportedexception();
//不能讀寫(xiě)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();
}
相信通過(guò)這些我們可以清楚的看到針對(duì)httprequeststream的設(shè)置或者寫(xiě)相關(guān)的操作是不被允許的，這也是為啥我們上面直接通過(guò)seek設(shè)置position的時(shí)候?yàn)樯稌?huì)報(bào)錯(cuò)，還有一些其他操作的限制，總之默認(rèn)是不希望我們對(duì)httprequeststream做過(guò)多的操作，特別是設(shè)置或者寫(xiě)相關(guān)的操作。但是我們使用enablebuffering的時(shí)候卻沒(méi)有這些問(wèn)題，究竟是為什么?接下來(lái)我們要揭開(kāi)它的什么面紗了。首先我們從request.enablebuffering()這個(gè)方法入手，找到源碼位置在httprequestrewindextensions擴(kuò)展類中[點(diǎn)擊查看源碼👈]，我們從最簡(jiǎn)單的無(wú)參方法開(kāi)始看到如下定義
/// <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ǔ)到磁盤(pán)的限定大小
/// <summary>
/// 確保request.body可以被多次讀取
/// </summary>
/// <param name="request"></param>
/// <param name="bufferthreshold">內(nèi)存中用于緩沖流的最大大?。ㄗ止?jié)）。較大的請(qǐng)求主體被寫(xiě)入磁盤(pán)。</param>
/// <param name="bufferlimit">請(qǐng)求正文的最大大小（字節(jié)）。嘗試讀取超過(guò)此限制將導(dǎo)致異常</param>
public static void enablebuffering(this httprequest request, int bufferthreshold, long bufferlimit)
{
bufferinghelper.enablerewind(request, bufferthreshold, bufferlimit);
}
無(wú)論那種形式，最終都是在調(diào)用bufferinghelper.enablerewind這個(gè)方法，話不多說(shuō)直接找到bufferinghelper這個(gè)類，找到類的位置[點(diǎn)擊查看源碼👈]代碼不多而且比較簡(jiǎn)潔，咱們就把enablerewind的實(shí)現(xiàn)粘貼出來(lái)
//默認(rèn)內(nèi)存中可緩存的大小為30k,超過(guò)這個(gè)大小將會(huì)被存儲(chǔ)到磁盤(pán)
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è)類，看來(lái)這是關(guān)鍵所在
var filestream = new filebufferingreadstream(body, bufferthreshold,bufferlimit,aspnetcoretempdirectory.tempdirectoryfactory);
//賦值給body，也就是說(shuō)開(kāi)啟了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ò)展方法，可以直接通過(guò)
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í)例
通過(guò)上面的分析我們也清楚的看到了，核心操作在于filebufferingreadstream這個(gè)類，而且從名字也能看出來(lái)它肯定是也繼承了stream抽象類，那還等啥直接找到filebufferingreadstream的實(shí)現(xiàn)[點(diǎn)擊查看源碼👈]，首先來(lái)看他類的定義
public class filebufferingreadstream : stream
{
}
毋庸置疑確實(shí)是繼承自steam類，我們上面也看到了使用了request.enablebuffering之后就可以設(shè)置和重復(fù)讀取requestbody，說(shuō)明進(jìn)行了一些重寫(xiě)操作，具體我們來(lái)看一下
/// <summary>
/// 允許讀
/// </summary>
public override bool canread
{
get { return true; }
}
/// <summary>
/// 允許seek
/// </summary>
public override bool canseek
{
get { return true; }
}
/// <summary>
/// 不允許寫(xiě)
/// </summary>
public override bool canwrite
{
get { return false; }
}
/// <summary>
/// 可以獲取長(zhǎng)度
/// </summary>
public override long length
{
get { return _buffer.length; }
}
/// <summary>
/// 可以讀寫(xiě)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)沒(méi)讀取完成但是原始位置信息和當(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)橹貙?xiě)了一些關(guān)鍵設(shè)置，所以我們可以設(shè)置一些流相關(guān)的操作。從seek方法中我們看到了兩個(gè)比較重要的參數(shù)_completelybuffered和_buffer，_completelybuffered用來(lái)判斷原始的httprequeststream是否讀取完成，因?yàn)閒ilebufferingreadstream歸根結(jié)底還是先讀取了httprequeststream的內(nèi)容。_buffer正是承載從httprequeststream讀取的內(nèi)容,我們大致抽離一下邏輯看一下，切記這不是全部邏輯，是抽離出來(lái)的大致思想
private readonly arraypool<byte> _bytepool;
private const int _maxrentedbuffersize = 1024 * 1024; //1mb
private stream _buffer;
public filebufferingreadstream(int memorythreshold)
{
//即使我們?cè)O(shè)置memorythreshold那么它最大也不能超過(guò)1mb否則也會(huì)存儲(chǔ)在磁盤(pán)上
if (memorythreshold <= _maxrentedbuffersize)
{
_rentedbuffer = bytepool.rent(memorythreshold);
_buffer = new memorystream(_rentedbuffer);
_buffer.setlength(0);
}
else
{
//超過(guò)1m將緩存到磁盤(pán)所以僅僅初始化
_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();
//如果讀取完成過(guò)則直接在buffer中獲取信息直接返回
if (_buffer.position < _buffer.length || _completelybuffered)
{
return _buffer.read(buffer);
}
//未讀取完成才會(huì)走到這里
//_inner正是接收的原始的requestbody
//讀取的requestbody放入buffer中
var read = _inner.read(buffer);
//超過(guò)設(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ǔ)到磁盤(pán)中
if (_inmemory && _memorythreshold - read < _buffer.length)
{
_inmemory = false;
//緩存原始的body流
var oldbuffer = _buffer;
//創(chuàng)建緩存文件
_buffer = createtempfile();
//超過(guò)內(nèi)存存儲(chǔ)限制，但是還未寫(xiě)入過(guò)臨時(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寫(xiě)入到緩存文件流_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é)尾,則一直寫(xiě)入到緩存區(qū)
if (read > 0)
{
_buffer.write(buffer.slice(0, read));
}
else
{
//如果已經(jīng)讀取requestbody完畢，也就是寫(xiě)入到緩存完畢則更新_completelybuffered
//標(biāo)記為以全部讀取requestbody完成，后續(xù)在讀取requestbody則直接在_buffer中讀取
_completelybuffered = true;
}
//返回讀取的byte個(gè)數(shù)用于外部streamreader判斷讀取是否完成
return read;
}
代碼比較多看著也比較復(fù)雜，其實(shí)核心思路還是比較清晰的，我們來(lái)大致的總結(jié)一下
- 首先判斷是否完全的讀取過(guò)原始的requestbody,如果完全完整的讀取過(guò)requestbody則直接在緩沖區(qū)中獲取返回
- 如果requestbody長(zhǎng)度大于設(shè)定的內(nèi)存存儲(chǔ)限定，則將緩沖寫(xiě)入磁盤(pán)臨時(shí)文件中
- 如果是首次讀取或?yàn)橥耆暾淖x取完成requestbody，那么將requestbody的內(nèi)容寫(xiě)入到緩沖區(qū)，知道讀取完成
其中createtempfile這是創(chuàng)建臨時(shí)文件的操作流，目的是為了將requestbody的信息寫(xiě)入到臨時(shí)文件中?？梢灾付ㄅR時(shí)文件的地址，若如果不指定則使用系統(tǒng)默認(rèn)目錄，它的實(shí)現(xiàn)如下[點(diǎn)擊查看源碼👈]
private stream createtempfile()
{
//判斷是否制定過(guò)緩存目錄，沒(méi)有的話則使用系統(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)邏輯是完全一致的，只是讀取和寫(xiě)入操作都是異步的操作，這里咱們就不介紹那個(gè)方法了，有興趣的同學(xué)可以自行了解一下readasync方法的實(shí)現(xiàn)[點(diǎn)擊查看源碼👈]
當(dāng)開(kāi)啟enablebuffering的時(shí)候，無(wú)論首次讀取是設(shè)置了allowsynchronousio為true的readtoend同步讀取方式，還是直接使用readtoendasync的異步讀取方式，那么再次使用readtoend同步方式去讀取request.body也便無(wú)需去設(shè)置allowsynchronousio為true。因?yàn)槟J(rèn)的request.body已經(jīng)由httprequeststream實(shí)例替換為filebufferingreadstream實(shí)例，而filebufferingreadstream重寫(xiě)了read和readasync方法，并不存在不允許同步讀取的限制。
總結(jié)
本篇文章篇幅比較多，如果你想深入的研究相關(guān)邏輯，希望本文能給你帶來(lái)一些閱讀源碼的指導(dǎo)。為了防止大家深入文章當(dāng)中而忘記了具體的流程邏輯，在這里我們就大致的總結(jié)一下關(guān)于正確讀取requestbody的全部結(jié)論
- 首先關(guān)于同步讀取request.body由于默認(rèn)的requestbody的實(shí)現(xiàn)是httprequeststream，但是httprequeststream在重寫(xiě)read方法的時(shí)候會(huì)判斷是否開(kāi)啟allowsynchronousio，如果未開(kāi)啟則直接拋出異常。但是httprequeststream的readasync方法并無(wú)這種限制，所以使用異步方式的讀取requestbody并無(wú)異常。
- 雖然通過(guò)設(shè)置allowsynchronousio或使用readasync的方式我們可以讀取requestbody，但是requestbody無(wú)法重復(fù)讀取，這是因?yàn)閔ttprequeststream的position和seek都是不允許進(jìn)行修改操作的，設(shè)置了會(huì)直接拋出異常。為了可以重復(fù)讀取，我們引入了request的擴(kuò)展方法enablebuffering通過(guò)這個(gè)方法我們可以重置讀取位置來(lái)實(shí)現(xiàn)requestbody的重復(fù)讀取。
- 關(guān)于開(kāi)啟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è)類重寫(xiě)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)一套邏輯來(lái)替換body，只要我們重寫(xiě)的時(shí)候讓這個(gè)stream支持重置讀取位置即可。
關(guān)于asp.net core讀取request.body的正確方法的文章就介紹至此，更多相關(guān)asp.net core讀取request.body內(nèi)容請(qǐng)搜索碩編程以前的文章，希望大家多多支持碩編程！
C++實(shí)戰(zhàn)