Question

我一直试图了解ASP.NET 5管道中间件如何真正起作用。据我所知，中间件只是一个Func<RequestDelegate, RequestDelegate>，它是一个指向方法的指针，该方法接收对下一个请求委托的引用并返回一个包装下一个请求委托的新方法。当然，我们可以使用类来表示中间件，例如：

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并返回Task的方法的引用，因此Invoke方法是要返回的请求委托和可以访问管道上的下一个。

我们在编写中间件时，可以访问管道的下一个组件，但我有一个疑问。一开始我认为理想总是以下列方式工作：

检查中间件是否可以处理请求
如果可以，请执行HttpContext
调用管道上的下一个中间件

因此，当我第一次研究这个时，我认为每个中间件应该总是调用下一个。但这样做会导致this question上讨论的奇怪行为。

另外看一些中间件的源代码，我看到其中一些中间件遵循另一个步骤：

检查中间件是否可以处理请求
如果可以的话，可以使用HttpContext执行必须执行的操作
如果没有，且仅在时才会调用下一个

这是使用中间件的真正想法吗？这方面的正确方法是什么？每个中间件都会执行必须完成的请求，并始终调用下一个或者如果中间件可以处理它不再调用下一个请求的请求？

我认为中间件只有在无法处理请求时才应调用下一个中间件。我认为这是因为如果不是，管道上的中间件之间会有耦合。因此，为了处理请求，中间件需要知道前一个做了什么以避免弄乱一切。这个结论是对的吗？

Answer 1

存在中间件以使请求管道模块化，这意味着只要您尊重合同，就可以添加/删除/替换部件。例如，如果您的应用程序在没有任何缓存的情况下提供某些文件，则可以在管道前面添加中间件而不更改其余文件。它们是构建块。

中间件可以：

不做任何事情并进一步传递请求（例如，仅适用于POST请求的中间件，但当前的请求是GET）
对请求执行任何操作，执行其他操作并进一步传递（例如，记录）
对请求执行某些操作并进一步传递请求（例如，获取身份验证令牌并将其转换为身份，或从请求中删除一些敏感信息）
结束管道而不是进一步传递请求（例如StaticFileMiddleware只返回文件，或者当路线匹配时MVC）

也可能回答你的other question：有两种类型的中间件：

设计用于执行某些操作并进一步传递数据的中间件（等等身份验证，Cookie，验证，日志记录等）
完成管道的中间件（静态文件，MVC等）。

当然，有些人可能会根据具体情况做两件事。例如，如果凭据不正确，auth可以结束管道，否则继续。

中间件的作者必须决定是否应该调用下一个中间件（如果有的话）。如果你的问题中的中间件返回一条消息，它就不应该调用下一个消息。

中间件应该总是调用下一个？

1 个答案: