ASP.NET Core自定义中间件如何读取Request.Body与Response.Body的内容详解

背景#

最近在徒手造轮子,编写一个ASP.NET Core的日志监控器,其中用到了自定义中间件读取Request.Body和Response.Body的内容,但是编写过程,并不像想象中的一帆风顺,ASP.NET Core针对Request.Body和Response.Body的几个特殊设计,导致了完成以上功能需要绕一些弯路。

原始代码#

为了读取Request.Body和Response.Body的内容,我的实现思路如下:

创建一个LoggerMiddleware的中间件,将它放置在项目中间件管道的头部。因为根据ASP.NET Core的中间件管道设计,只有第一个中间件才能获取到原始的请求信息和最终的响应信息。

Request.Body和Response.Body属性都是Steram类型, 在LoggerMiddleware中间件的InvokeAsync方法中,我们可以分别使用StreamReader读取Request.Body和Response.Body的内容。

根据以上思路,我编写了以下代码。

LoggerMiddleware.cs

	public class LoggerMiddleware
 {
 private readonly RequestDelegate _next;

 public LoggerMiddleware(RequestDelegate next)
 {
  _next = next;
 }

 public async Task InvokeAsync(HttpContext context)
 {
  var requestReader = new StreamReader(context.Request.Body);

 		var requestContent = requestReader.ReadToEnd();
 		Console.WriteLine($"Request Body: {requestContent}");

 		await _next(context);

 		var responseReader = new StreamReader(context.Response.Body);
 		var responseContent = responseReader.ReadToEnd();
 		Console.WriteLine($"Response Body: {responseContent}");
 }
 }

Startup.cs

 public void Configure(IApplicationBuilder app, IHostingEnvironment env)
 {
 if (env.IsDevelopment())
 {
  app.UseMiddleware<LoggerMiddleware>();
  app.UseDeveloperExceptionPage();
 }
 else
 {
  app.UseHsts();
 }

 app.UseHttpsRedirection();
 app.UseMvc();
 }

问题1:Response.Body的Stream不可读#

这里为了测试我创建了一个默认的ASP.NET Core WebApi项目。当运行程序,使用GET方式调用/api/values之后,控制台会返回第一个需要处理的错误。

System.ArgumentException: Stream was not readable.

即ASP.NET Core默认创建的Response.Body属性是不可读的。

这一点我们可以通过打断点看到Response.Body属性的CanRead值是false。

这就很糟糕了,ASP.NET Core默认并不想让我们在中间件中直接读取Response.Body中的信息。

这里看似的无解,但是我们可以转换一下思路,既然ASP.NET Core默认将Response.Body是不可读的,那么我们就使用一个可读可写的Stream对象将其替换掉。这样当所有中间件都依次执行完之后,我们就可以读取Response.Body的内容了。

public async Task InvokeAsync(HttpContext context)
{
	 var requestReader = new StreamReader(context.Request.Body);

 var requestContent = requestReader.ReadToEnd();
 Console.WriteLine($"Request Body: {requestContent}");

 using (var ms = new MemoryStream())
 {
  context.Response.Body = ms;
  await _next(context);

  context.Response.Body.Position = 0;

  var responseReader = new StreamReader(context.Response.Body);

  var responseContent = responseReader.ReadToEnd();
  Console.WriteLine($"Response Body: {responseContent}");

  context.Response.Body.Position = 0;
 }
}

注意:

  • 读取Response.Body的时候,需要设置Position = 0, 这样是为了重置指针,如果不这样做的话,会导致读取的流不正确。
  • 这里千万不要用using包裹StreamReader, 因为StreamReader会在读取完Stream内容之后,将Stream关闭,导致后续由于Stream关闭,而不能再次读取Stream中的内容。如果必须使用,请使用StreamReader的以下重载,将leaveOpen参数设置为true, 确保StreamReader对象被销毁的时候不会自动关闭读取的Stream.
public StreamReader(Stream stream, Encoding encoding, bool detectEncodingFromByteOrderMarks, int bufferSize, bool leaveOpen);

重新启动程序,请求/api/values, 我们就得到的正确的结果。

进一步完善代码#

以上代码实现,看似已经能够读取Response.Body的内容了,但是其实还是有问题的。

回想一下,我们做出以上方案的前提是,当前LoggerMiddleware中间件必须位于中间件管道的头部。

如果不能保证这个约定, 就会出现问题,因为我们在LoggerMiddleware中间件中将Response.Body属性指向了一个新的可读可写的Stream对象。如果LoggerMiddleware中间件之前的某个中间件中设置过Response.Body, 就会导致这部分设置丢失。

因此正确的设置方式应该是这样的:

 public async Task InvokeAsync(HttpContext context)
 {
 var originalResponseStream = context.Response.Body;

 var requestReader = new StreamReader(context.Request.Body);

 var requestContent = requestReader.ReadToEnd();
 Console.WriteLine($"Request Body: {requestContent}");

 using (var ms = new MemoryStream())
 {
  context.Response.Body = ms;
  await _next(context);

  ms.Position = 0;
  var responseReader = new StreamReader(ms);

  var responseContent = responseReader.ReadToEnd();
  Console.WriteLine($"Response Body: {responseContent}");

  ms.Position = 0;

  await ms.CopyToAsync(originalResponseStream);
  context.Response.Body = originalResponseStream;
 }
 }

代码解释:

  • 这里当进入LoggerMiddleware中间件时,我们将之前中间件操作完成之后的Response.Body对象对应的原始Stream, 保存在一个临时变量中
  • 当LoggerMiddelware中间件的任务完成之后,我们需要将后续产生的Response.Body流追加到原始Stream中,然后将Response.Body对象重置为这个新的Stream。

至此Repsonse.Body的问题都解决,下面我们再来看一下Request.Body的问题。

问题2:Request.Body的内容可以正确的显示,但是后续的ModelBinding都失败了#

下面我们来请求POST /api/values, Request.Body里面的内容是字符串"123123"

服务器端返回了400错误, 错误信息

A non-empty request body is required.

这里就很奇怪,为啥请求体是空呢?我们回到中间件部分代码,这里我们在读取完Request.Body中的Stream之后,没有将Stream的指针重置,当前指针已经是Stream的尾部,所以后续ModelBinding的时候,读取不到Stream的内容了。

 public async Task InvokeAsync(HttpContext context)
 {
 ...
 var requestReader = new StreamReader(context.Request.Body);

 var requestContent = requestReader.ReadToEnd();
 Console.WriteLine($"Request Body: {requestContent}");
 ...
 }

于是,这里我们需要采取和Response.Body相同的处理方式,在读取完Request.Body之后,我们需要将Request.Body的Stream指针重置

 public async Task InvokeAsync(HttpContext context)
 {
 ...
 var requestReader = new StreamReader(context.Request.Body);

 var requestContent = requestReader.ReadToEnd();
 Console.WriteLine($"Request Body: {requestContent}");
 context.Request.Body.Position = 0;
 ...
 }

你一定觉着至此问题就解决了,不过ASP.NET Core和你又开了一个玩笑。

当你重新请求POST /api/values之后,你会得到以下结果。

错误原因:

System.NotSupportedException: Specified method is not supported.

翻译过来就是指定方法不支持。到底不支持啥呢?在代码上打上断点,你会发现Request.Body的CanSeek属性是false, 即Request.Body的Stream, 你是不能随便移动指针的,只能按顺序读取一次,默认不支持反复读取。

那么如何解决这个问题呢?

你可以在使用Request对象中的EnableRewind或者EnableBuffering。 这2个方法的作用都是在内存中创建缓冲区存放Request.Body的内容,从而允许反复读取Request.Body的Stream。

说明: 其实EnableBuffering方法内部就只直接调用的EnableRewind方法。

下面我们修改代码

 public async Task InvokeAsync(HttpContext context)
 {
 context.Request.EnableBuffering();
 var requestReader = new StreamReader(context.Request.Body);

 var requestContent = requestReader.ReadToEnd();
 Console.WriteLine($"Request Body: {requestContent}");
 context.Request.Body.Position = 0;

 using (var ms = new MemoryStream())
 {
  context.Response.Body = ms;
  await _next(context);

  ms.Position = 0;
  var responseReader = new StreamReader(ms);

  var responseContent = responseReader.ReadToEnd();
  Console.WriteLine($"Response Body: {responseContent}");

  ms.Position = 0;
 }
 }

再次请求POST /api/values, api请求被正确的处理了。

源代码: https://github.com/lamondlu/webapi-logger

总结

到此这篇关于ASP.NET Core自定义中间件中如何读取Request.Body与Response.Body的内容的文章就介绍到这了,更多相关ASP.NET Core自定义中间件读取Request.Body与Response.Body内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • ASP.NET Core读取Request.Body的正确方法

    前言 相信大家在使用ASP.NET Core进行开发的时候,肯定会涉及到读取Request.Body的场景,毕竟我们大部分的POST请求都是将数据存放到Http的Body当中.因为笔者日常开发所使用的主要也是ASP.NET Core所以笔者也遇到这这种场景,关于本篇文章所套路的内容,来自于在开发过程中我遇到的关于Request.Body的读取问题.在之前的使用的时候,基本上都是借助搜索引擎搜索的答案,并没有太关注这个,发现自己理解的和正确的使用之间存在很大的误区.故有感而发,便写下此文,以作记录

  • ASP.NET Core自定义中间件如何读取Request.Body与Response.Body的内容详解

    背景# 最近在徒手造轮子,编写一个ASP.NET Core的日志监控器,其中用到了自定义中间件读取Request.Body和Response.Body的内容,但是编写过程,并不像想象中的一帆风顺,ASP.NET Core针对Request.Body和Response.Body的几个特殊设计,导致了完成以上功能需要绕一些弯路. 原始代码# 为了读取Request.Body和Response.Body的内容,我的实现思路如下: 创建一个LoggerMiddleware的中间件,将它放置在项目中间件管

  • ASP.NET Core自定义中间件的方式详解

    目录 1.委托形式 2.强类型中间件 2.1.定义中间件的依赖 2.2.定义中间件类型 3.基于约定的中间件 3.1.约定规则 3.2.应用实现 总结 ASP.NET Core应用本质上,其实就是由若干个中间件构建成的请求处理管道.管道相当于一个故事的框架,而中间件就相当于故事中的某些情节.同一个故事框架采用不同的情节拼凑,最终会体现出不同风格的故事.而我们的ASP.NET Core应用也正是如此,同一管道采用不同的中间件组合,最终也会呈现出不同的应用形态. 从上述的概念种可以看出,中间件在AS

  • ASP.NET Core中修改配置文件后自动加载新配置的方法详解

    前言 在 ASP.NET Core 默认的应用程序模板中, 配置文件的处理如下面的代码所示: config.AddJsonFile( path: "appsettings.json", optional: true, reloadOnChange: true ); config.AddJsonFile( path: $"appsettings.{env.EnvironmentName}.json", optional: true, reloadOnChange: t

  • 在 asp.net core 的中间件中返回具体的页面的实现方法

    前言 在 asp.net core 中,存在着中间件这一概念,在中间件中,我们可以比过滤器更早的介入到 http 请求管道,从而实现对每一次的 http 请求.响应做切面处理,从而实现一些特殊的功能 在使用中间件时,我们经常实现的是鉴权.请求日志记录.全局异常处理等等这种非业务性的需求,而如果你有在 asp.net core 中使用过 swashbuckle(swagger).health check.mini profiler 等等这样的组件的话,你会发现,这些第三方的组件往往都提供了页面,允

  • Asp.Net Core控制器如何接收原始请求正文内容详解

    主要目标 在Asp.net Core控制器中,通过自定义格式化程序来映射自定义处理控制器中的"未知"内容.本文将给大家详细介绍关于Asp.Net Core控制器接收原始请求正文内容的相关内容,分享出来供大家参考学习,下面话不多说了,来一起看看详细的介绍吧 简单案例 为了演示这个问题,我们用VS2017创建一个默认的Asp.net Core Web Api项目. [Route("api/[controller]")] [ApiController] public cl

  • SparkSQL读取hive数据本地idea运行的方法详解

    环境准备: hadoop版本:2.6.5 spark版本:2.3.0 hive版本:1.2.2 master主机:192.168.100.201 slave1主机:192.168.100.201 pom.xml依赖如下: <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="

  • 微信小程序request请求后台接口php的实例详解

    微信小程序request请求后台接口php的实例详解 后台php接口:http://www.vueyun.com/good/info 没有处理数据,直接返回了,具体再根据返回格式处理 public function getGoodInfo(Request $request) { $goods_datas = $this->Resource->get(); return response()->json(['status' => 'success','code' => 200,

  • 对django views中 request, response的常用操作详解

    request 获取post请求中的json数据 def hello(request): data = json.loads(request.body) ... json格式还有一些 非表单序列化 的格式,都可以从 request.body 中获取请求体中的数据,对于ajax请求可以使用 request.is_ajax() 来判断 根据请求的信息获取base url(有时候服务的域名比较多,还是需要动态的拼接一下url信息) # url http://wificdn.com:8888/wxpay

  • python中urllib.request和requests的使用及区别详解

    urllib.request 我们都知道,urlopen()方法能发起最基本对的请求发起,但仅仅这些在我们的实际应用中一般都是不够的,可能我们需要加入headers之类的参数,那需要用功能更为强大的Request类来构建了 在不需要任何其他参数配置的时候,可直接通过urlopen()方法来发起一个简单的web请求 发起一个简单的请求 import urllib.request url='https://www.douban.com' webPage=urllib.request.urlopen(

  • keras 自定义loss损失函数,sample在loss上的加权和metric详解

    首先辨析一下概念: 1. loss是整体网络进行优化的目标, 是需要参与到优化运算,更新权值W的过程的 2. metric只是作为评价网络表现的一种"指标", 比如accuracy,是为了直观地了解算法的效果,充当view的作用,并不参与到优化过程 在keras中实现自定义loss, 可以有两种方式,一种自定义 loss function, 例如: # 方式一 def vae_loss(x, x_decoded_mean): xent_loss = objectives.binary_

随机推荐