fix: pathsend handling in middlewares

[gi0baro]

Summary

Closes #2613

It seems that when I introduced support for pathsend in #2435 I didn't check the included middlewares to also support the relevant ASGI messages. Affected Starlette versions 0.36.0 and onwards when running on a server supporting pathsend.

Note: this is still in draft since I'd like to plan some tests for the involved code; also the proposed solution isn't necessarily the best one, probably someone like @Kludex might review this and give his feedbacks before proceeding further.
Update: I added tests just to verify the code. In case you're unhappy with the implementation, we can refactor that and keep the tests.

Checklist

• I understand that this PR may be closed in case there was no previous discussion. (This doesn't apply to typos!)
• I've added a test for each change that was introduced, and I tried as much as possible to make a single atomic change.
• I've updated the documentation accordingly.

[aersam]

Hi there! wouldn't it make sense to just read the file and stream it through here? Would be better for compatibility, no? Or maybe have some flag like "supports_message_pass_through"?

[gi0baro]

Reading the file from Python would be just the standard ASGI behaviour and defeat the whole pathsend idea (see for ref https://asgi.readthedocs.io/en/latest/extensions.html#path-send).

About the flag: I'm not sure I get the point around it. How should we evaluate such flag? pathsend messages will be returned by Starlette only if the relevant extension is present in the ASGI scope as the server supports it.

[aersam]

I was thinking about random middlewares out there, deriving from this BaseMiddleware that do not know pathsend. To keep those running, returning the message instead of bytes could be opt-in via a flag/class property

[gi0baro]

@aersam but even if you subclass BaseMiddleware, there's no way you can interact with that code. If the middleware completely overrides __call__ then it should be compliant with ASGI messages IMHO.

[gi0baro]

@Kludex any updates on this?

[Kludex]

Are the changes here just because the StreamingResponse is used in the BaseHTTPMiddleware?

[gi0baro]

Yes. A Better implementation would probably be to refactor BaseHTTPMiddleware, but it is something I am not confident to do by myself given my knowledge of the codebase is still limited.

[Kludex]

We are not making changes to the rest of the code source to make BaseHTTPMiddleware happy.

My recommendation for Granian users, and/or any server supporting http.response.pathsend is to replace BaseHTTPMiddleware for pure ASGI middleware. I don't want us to add more complexity to that code. That piece of code had too many issues over time.

[gi0baro]

I understand your position.

I think there are 2 major themes here though:

• StreamingResponse doesn't support any message type other than http.response.body, which make sense given the intent of streaming responses, so unless an additional body message type is added to ASGI this is future-proof. But, since BaseHTTPMiddleware depends on that, this also means any application using that middleware or a derivate middleware won't support any other ASGI message in responses, which is something you might want to change to be future-proof on ASGI spec changes.
• As of today Starlette states (due to the changes I made in Add support for ASGI pathsend extension #2435) to support http.response.pathsend, which is only partially true: as soon as the route involves a BaseHTTPMiddleware, GZIPMiddleware or a derivate of those in the middleware chain, then Starlette doesn't actually support pathsend.

The rationale behind this PR is not to address the first point, but rather the 2nd; as today experience with pathsend supportive servers with any Starlette/FastAPI application is practically dependant on which middlewares are implemented on the route returning a file response.

So given all of the above, if we can't find a proper way to address the pathsend issue, I'd rather suggest to revert #2435 and remove pathsend support completely until we find a proper way to support that ASGI extension in all the usages of Starlette and its dependants. This would sacrifice the performance gain of pathsend but at least we'd have the same DX across all the Starlette apps, regardless of the middlewares used, and thus prevent the whole bunch of issues related to this opened in Granian repo.

[Kludex]

Yeah, we can revert that one. It will be easier.

[gi0baro]

👍 I'll open a different PR later today and close this one

[gi0baro]

Closing this in favour of #2649, as discussed.