我试图在我的MVC控制器动作执行后获得响应的副本,但从这里的其他问题我无法使此代码工作(尽管这似乎是一个很好地回答的问题)……
public class Startup
{
public void Configuration(IAppBuilder app)
{
app.Use(async (context, next) =>
{
var resultStream = context.Response.Body;
context.Response.Body = new MemoryStream();
// allow the response to be written in future request lifecycle events
await next.Invoke();
// fetch the repsonse
context.Response.Body.Seek(0, SeekOrigin.Begin);
var headers = context.Response.Headers;
var body = new StreamReader(context.Response.Body).ReadToEnd();
// ... other code omitted for question clarity
// write the response to the client
context.Response.Body.Seek(0, SeekOrigin.Begin);
await context.Response.Body.CopyToAsync(resultStream);
context.Response.Body = resultStream;
});
}
// ... other code omitted for question clarity
}
当我到达第二个seek时,变量"body“是空的。
当这之后的结果是一个有内容的页面时,你知道为什么会出现这种情况吗?
发布于 2018-06-03 06:11:56
所以这里的问题是,Owin和asp.net在整个生命周期中并没有像我想的那样相互交织在一起。
简而言之,请求生命周期类似于...
all Owin middlewares)
..。我需要的是..。
<代码>G217
..。当然,我在这里大大简化了过程,但我想解释它的最简单的方法是当你这样做的时候……
app.Use((context, next) => { ... }).UsestageMarker(?);
..。没有表示“响应处理完成”的阶段标记。
有趣的是,aspnet核心给了我们更多的控制,因为与整个请求生命周期中的所有部分的紧密集成较少依赖于预定义的阶段,而更多的是由用户定义自己的流程来处理请求和构造响应。
简而言之。在.net核心中,我可以做我想要做的事情,但在owin中使用aspnet 4.6似乎不可能做到这一点
然而,我引用了一些关于使用过滤器和处理"OnActionExectuted“的内容,如果你看一下,你会得到一个完全不同的请求和响应对象,而不是在中间件的流水线中给你的(因此增加了更多的证据,表明这些事情实际上不是一个单独的进程,而仅仅是一个顺序中发生的两个进程)。
从那以后,我一直在考虑将我的应用程序迁移到aspnet核心...事实证明,这比我预期的更令人头疼,但我一直希望最终的结果会更干净、更快。
https://stackoverflow.com/questions/50657219
复制相似问题