|
目录8 M! P$ ]' ~ M* l- X$ A
0 h; c% @6 F4 p6 U) x
) g" |: g& a+ X/ r- 前言
5 w% L+ l3 y1 p0 J - 常用读取方式' [3 ^4 V' \0 Q4 P0 W1 s9 y5 C
- 同步读取, N3 O5 R2 @2 s' Y! v
- 异步读取/ Y, f: s# m( @ v8 ?2 \
- 重复读取0 p7 {$ I; t' j2 f( N1 Z
- 源码探究
m$ Z( `( R$ q0 k7 ^* l2 P6 h+ @
- StreamReader和Stream的关系
7 ^+ `! R \& x5 D" u - HttpRequest的Body
) n8 ^* p9 F: p7 w - AllowSynchronousIO本质来源
5 p. p9 l4 j7 i8 Q# c4 e! N% a - EnableBuffering神奇的背后" T, l* z1 t: b, E! P
4 ]2 Z8 c6 I; ]: j4 h9 [' z* b
- 总结
! P2 v0 \ r" ~! c, x
0 D7 M: F: u/ ~; }前言. [, x# H! S! D! y
, k0 K0 M9 Y. }/ M相信大家在使用ASP.NET Core进行开发的时候,肯定会涉及到读取Request.Body的场景,毕竟我们大部分的POST请求都是将数据存放到Http的Body当中。因为笔者日常开发所使用的主要也是ASP.NET Core所以笔者也遇到这这种场景,关于本篇文章所套路的内容,来自于在开发过程中我遇到的关于Request.Body的读取问题。在之前的使用的时候,基本上都是借助搜索引擎搜索的答案,并没有太关注这个,发现自己理解的和正确的使用之间存在很大的误区。故有感而发,便写下此文,以作记录。学无止境,愿与君共勉。
, I8 ~: d1 F9 p c6 r; Y; ]: |/ z* s }9 J( v
常用读取方式
m! s [3 U4 o: T4 ~! k/ P. l/ U9 | t0 v& g( B* R
当我们要读取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,不过我们借助搜索引擎是我们最大的强项。6 u! e4 t4 X5 n+ S/ V2 l2 M+ b- \
6 {+ ~% ]$ W- Z* q
同步读取
! ?4 _4 K% e3 s% Z: l
5 q8 Y/ y. ~# }4 {首先我们来看设置AllowSynchronousIO为true的方式,看名字也知道是允许同步IO,设置方式大致有两种,待会我们会通过源码来探究一下它们直接有何不同,我们先来看一下如何设置AllowSynchronousIO的值。第一种方式是在ConfigureServices中配置,操作如下- services.Configure(options =>{ options.AllowSynchronousIO = true;});
复制代码 这种方式和在配置文件中配置Kestrel选项配置是一样的只是方式不同,设置完之后即可,运行不在报错。还有一种方式,可以不用在ConfigureServices中设置,通过IHttpBodyControlFeature的方式设置,具体如下- public override void OnActionExecuting(ActionExecutingContext context){ var syncIOFeature = context.HttpContext.Features.Get(); 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。通过查找资料得出了这么一个结论
, m' H, L. X) z% B; _0 E7 QKestrel:默认情况下禁用 AllowSynchronousIO(同步IO),线程不足会导致应用崩溃,而同步I/O API(例如HttpRequest.Body.Read)是导致线程不足的常见原因。
& y2 a1 ` x% C" Q- l 由此可以知道,这种方式虽然能解决问题,但是性能并不是不好,微软也不建议这么操作,当程序流量比较大的时候,很容易导致程序不稳定甚至崩溃。
8 I) d3 y5 l: q4 w i3 q: [
0 k0 T: o0 G; O* d$ ^+ n异步读取2 D- b/ G2 p% V( _
$ T7 n8 ~0 u: ~( ]通过上面我们了解到微软并不希望我们通过设置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方法就皆大欢喜了,有没有感觉到比较神奇。当我们感到神奇的时候,是因为我们对它还不够了解,接下来我们就通过源码的方式,一步一步的揭开它神秘的面纱。! ]7 \- N H5 c: y j
% p+ n) L o1 \ r# E/ y# i. \重复读取
1 h3 n/ w! p$ @- W! M% b1 R. f& t/ P& F- E
上面我们演示了使用同步方式和异步方式读取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,是不是很神奇,待会的时候我们会从源码的角度分析这个问题。
t0 ~0 J8 Z3 D6 A& O& O- |$ G0 Y1 h, B* h$ F/ B
源码探究
# z0 K" U/ w7 _: G7 f' I' S4 Z6 M2 |
上面我们看到了通过StreamReader的ReadToEnd同步读取Request.Body需要设置AllowSynchronousIO为true才能操作,但是使用StreamReader的ReadToEndAsync方法却可以直接操作。3 M5 ~4 t5 V6 |# S: Z, ?5 Z
; p; G/ j! A1 _' R% }
StreamReader和Stream的关系
8 b$ |/ n. ]. Q7 l( r
& ^$ c n! S2 J) s( B0 N# ~$ n+ _$ J j; q# h) f
我们看到了都是通过操作StreamReader的方法即可,那关我Request.Body啥事,别急咱们先看一看这里的操作,首先来大致看下ReadToEnd的实现了解一下StreamReader到底和Stream有啥关联,找到ReadToEnd方法[点击查看源码8 J# r% N4 a3 d. {0 t5 R
来源:http://www.jb51.net/article/213540.htm3 m! z1 |9 ^- o
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作! |
|