中间件应该总是调用下？ [英] A middleware should always invoke the next?

问题描述

我一直在试图了解ASP.NET 5管线中间件真正发挥作用。中间件，因为我知道，仅仅是一个 Func键< RequestDelegate，RequestDelegate> ，这是一个指向接收到下一个请求委托引用的方法，并返回一个新的一个包装下。我们当然可以使用一个类来表示一个中间件，是这样的：

I've been trying to understand how ASP.NET 5 pipeline middlewares really work. A middleware, as I know, is just a Func<RequestDelegate, RequestDelegate>, which is a pointer to a method that receives a reference to the next request delegate and returns a new one that wraps the next. We can of course, use a class to represent a middleware, something like:

public class MyMiddleware
{
    private readonly _next;

    public MyMiddleware(RequestDelegate next)
    {
        if (next == null)
        {
            throw new ArgumentNullException("next");
        }

        _next = next;
    }

    public Task Invoke(HttpContext context)
    {
        // New request delegate code here which can wrap the next one on the pipeline
    }
}

由于 RequestDelegate 是一个可以容纳引用接收方法委托有一个的HttpContext 并返回工作的调用的方法是要返回的请求，委托和可存取管道上的下一个。

Since the RequestDelegate is a delegate that can hold references to methods which receives one HttpContext and returns a Task the Invoke method is the request delegate to be returned and which has access to the next one on the pipeline.

我们拥有那么，编码时，中间件，访问该管道的下一个组成部分，但有一个疑问我有。一开始我以为理想是永远的工作方式如下：

We have then, when coding a middleware, access to the next component of the pipeline, but there is a doubt I have. In the beginning I thought the ideal was always to work the following way:

• 检查中间件可以处理请求


• 如果可以，为所欲为必须与的HttpContext


• 完成通话管道上的下一个中间件

所以，当我研究这是第一次我觉得每个中间件，应该总是调用下一个。但这样做导致了作为这个问题奇怪的行为。

So that when I studied this for the first time I thought each middleware should always call the next one. But doing this led to strange behavior as discussed on this question.

另外寻找一些中间件我看到其中的一些跟随另一个步骤的源代码：

Also looking at the source code of some middlewares I see some of them follow another steps:

• 检查中间件可以处理请求


• 如果可以，为所欲为必须与的HttpContext 来完成，这就是所有


• 如果不是，并仅如果没有拨打下一个

• Check if the middleware can handle the request
• If it can, do whatever must be done with the HttpContext and that's all
• If not, and only if not call the next one

这是采用中间件的真实想法？哪种方式是在这个正确的做法？每个中间件去做我们必须与请求来完成，并始终调用下或者如果midleware可以处理请求不调用下了吗？

Is this the real idea of using middlewares? Which way is the correct approach at this? Each middleware do what must be done with the request and always invoke the next or if a midleware can handle the request it doesn't invoke the next anymore?

我相信中间件应致电仅次于如果它不能处理请求。我认为原因是因为如果没有，就不会有管道上的中间件之间的耦合。这样处理中间件需要知道什么以前的人做，以避免搞乱一切请求。这是结论吧？

I believe a middleware should call the next only if it can't handle the request. The reason I think that is because if not, there would be coupling between the middlewares on the pipeline. So that to process the request the middleware would need to be aware of what the previous one did to avoid messing everything. Is this conclusion right?

推荐答案

中间件存在使请求管道模块化的，这意味着您可以添加/删除/从更换零件它只要你尊重合同。例如，如果你的应用程序提供了一些文件，而无需任何缓存，您可以在管道的前面加一个中间件而不改变休息。他们是积木

Middleware exist to make the request pipeline modular, meaning that you can add/remove/replace parts from it as long as you respect the contract. For example, if your application serves some files without any caching, you can add a middleware at the front of the pipeline without altering the rest. They are building blocks.

一个中间件：

1. 什么也不做通请求还（如中间件仅适用于POST请求，但当前是GET）


2. 什么都不做的的请求的，做别的事情，而不是和进一步传递（如日志记录）


3. 请某事的要求，并进一步传递请求（如获得一个认证令牌，并将其转换为一个身份，或删除请求一些敏感的信息）


4. 结束管道，而不是进一步的传递请求（如的StaticFileMiddleware 刚刚返回文件或路由匹配时，MVC）

1. Do nothing and pass the request further (e.g. a middleware that is applicable only to POST requests but the current one is GET)
2. Do nothing to the request, do something else instead and pass it further (e.g. logging)
3. Do something to the request and pass the request further (e.g. get an authentication token and convert it to an identity, or remove some sensitive information from the request)
4. End the pipeline and not pass the request further (e.g. StaticFileMiddleware which just returns the file, or MVC when a route matches)

也许你的回答其他问题太：有两种类型的中间件：

Probably answering your other question too: there are two types of middleware:

1. 中间件的设计做一些事情，通过沿着进一步数据（等AUTH，饼干，验证，日志记录等）


2. 中间件完成管道（静态文件，MVC等）。

当然，有些人可能都根据上下文做的。例如AUTH可以结束管道，如果凭据不正确，但否则继续。

Of course, some might do both depending on the context. For example auth can end the pipeline if the credentials are incorrect but continue otherwise.

中间件的作者必须决定是否在未来的中间件（如果有的话）应该被调用。在你的问题中间件返回消息的情况下，不应该调用下一个。

The author of the middleware must decide if the next middleware (if any) should be invoked. In the case of the middleware in your question which returns a message, it should not invoke the next one.

这篇关于中间件应该总是调用下？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！