If we're going to make it a configurable middleware it might also make sense to have some sort of timeout for connections and each chunk, maybe infinite by default but definitely tunable.

Another thing to keep in mind is that this is likely something users want to control on a per-endpoint basis. That is, if I have an app that has an upload feature where I'm expecting 1GB files it's likely a single endpoint that expects 1GB files so I'd want to bump up the limits just for that endpoint. That makes me think that the best strategy may be a per-endpoint middleware w/ a companion middleware that just tweaks the config by changing it in scope. That would allow layering and overriding of these settings. This would be similar to #2026

This is a good one! I also agree that we need a global setting and per-route (Route + Mount).
Use case: global limit - 1mb, photo upload endpoint - 10mb limit.

We can add max_body_size to request.form(), request.json(), and request.stream() functions.

Why should the ASGI application be the one to set this instead of the server?

Why should the ASGI application be the one to set this instead of the server?

Example: global POST limit is 1mb, for selected endpoints that upload files - 100mb.
Setting this at the server level is global and leaves no chance to override it.

Adding a LimitRequestSizeMiddleware is the simplest and forward-compatible way.

Adding a LimitRequestSizeMiddleware is the simplest and forward-compatible way.

Yeah. Shall we follow this path?

Yes I think someone should make a PR and we can discuss the details (override vs. min/max, should there be a default, etc.) there.

Yes I think someone should make a PR

I am someone, I made a PR 😆 : #2328

The PR was closed, but the idea is still on the table, so here are my 2ct:

• Global request size limits do no work for application that actually want to accept file uploads on some routes. Those uploads are usually spooled to temporary files and not limited by available memory. JSON is parsed into in-memory structures, though. Enforcing the same limit on both types of data is not sensible.
• Not having reasonable default limits is an invitation for developers to forget about this aspect and write vulnerable applications.
• How do others do it? That should not matter much, but: Bottle, Django and probably many others do have size limits. Not for the request body, but for what is loaded into memory by functions like Request.json(). Werkzeug/Flask says that calling Request.get_data() is a bad idea without checking request size first, but does it anyway when parsing json. Not the best role model perhaps.
• Frameworks that parse the request body before calling the request handler function (e.g. FastAPI) make it extra hard to be safe. You cannot check the request body size before the parsing step is triggered.
• Request.json() is a function, adding a size limit parameter would backwards compatible.