A new idea about BaseHTTPMiddleware

[abersheeran]

https://github.com/abersheeran/baize/blob/master/baize/asgi/middleware.py

Recently I needed to use a design similar to BaseHTTPMiddleware in WSGI, so I spent a whole day today adjusting baize and successfully implemented a version that meets my needs.

As far as I know, a considerable part of the complex design of BaseHTTPMiddleware comes from the reading of the request body, but reading the request body in the middleware itself is a niche behavior. We should encourage people who need to read the request body to directly write Prue ASGI middleware, abandoning very few requirements, and we can make BaseHTTPMiddleware more usable and easier to maintain to meet the needs of most people.

So I made a version in baize.asgi.middleware, where users are not allowed to read the request body in the middleware, and I found that everything became simple.

I wonder what you think of this design? @Kludex @adriangb

[adriangb]

Part of the complexity also comes from handing over control to the user's code and having to pass them a callback.
Other complexity comes from trying to go from ASGI -> Request/Response -> ASGI.
The best way I've found to avoid that is FastAPI dependency style middleware, similar to the proposal in #1691.
I think if we combined that with moving Request/Response middleware to happen after routing (or making routing Request/Response based but I think that's a bigger change) we'd be in a much better place.

[abersheeran]

There are many better ways to get out of the Pure ASGI field, such as the https://github.com/abersheeran/baize/blob/master/baize/asgi/shortcut.py#L58 I mentioned earlier, which only takes a few lines of code to implement an elegant middleware.

def decorator(
    handler: Callable[[Request, ViewType], Awaitable[Response]]
) -> Callable[[ViewType], ViewType]:

    @functools.wraps(handler)
    def d(next_call: ViewType) -> ViewType:

        @functools.wraps(next_call)
        async def view(request: Request) -> Response:
            return await handler(request, next_call)

        return view

    return d

But I think we still need a method that can facilitate us to write ASGI middleware in most cases. These two requirements are not conflicting.

[Kludex]

But I think we still need a method that can facilitate us to write ASGI middleware in most cases.

I think that, too.

The proposal here is to recommend users to write Pure ASGI middleware when they want to read the body, and this new decorator for normal middlewares?

[adriangb]

The thing to note is that unless (1) you want to use a middleware across asgi frameworks or (2) you want to mess with routing you may as well run the middleware after routing once you're in the Request/Response world. Then you can also read the request body, etc., essentially like FastAPI dependencies.

[abersheeran]

The proposal here is to recommend users to write Pure ASGI middleware when they want to read the body, and this new decorator for normal middlewares?

Yes. In most cases, the body is not manipulated in the middleware, and such manipulation is complicated. By giving up processing this part, we can give most people a better user experience (this can almost solve all the problems caused by BaseHTTPMiddleware).