Aiohttp: Add max_size parameter to web.Request reading methods

[asvetlov]

It my prevent malicious clients from sending infinite BODY in post requests which may lead to running out of memory.

Guys, what do you think about?
Does it make sense?

[asvetlov]

Should raise 413 on size overloading

[f0t0n]

I think you'll never get to request body size check when you run behind nginx in production deployment since nginx has own setting client_max_body_size (default 1MB) and returns 413 if the size of request's body exceeds that value.

Do we expect users to run aiohttp applications without nginx in production?

[f0t0n]

So my point is RAM management is more up to DevOps engineer that is responsible for the server infrastructure, so that he should configure correct limits for nginx, optimal database connection pool size and so on.

[f0t0n]

Say attacker could try to overload RAM with huge request body. And we check the max size. Ok. Then he starts to DoS the application, should we now check his request rate? I think both cases are out of application's scope and should be delegated one level upper, namely to servers setup by DevOps team.

[asvetlov]

Checking for max length by nxing is satisfactory solution but writing complex configuration with different values for different locations may be painful.
So why not support it in aiohttp too?
In other case most likely DevOps will relax the size for all application even if only couple endpoints should accept huge file uploads.

[argaen]

I think it's useful to have this feature supported by aiohttp as long as:

1. We set a reasonable default size
2. We provide a way of disabling it (like setting max_size=0 for example?)

@f0t0n with the example you say about request rate, there are libraries like djangorestframework that provide this functionality. Is the users choice if they want to use this feature or use something else in the server layer.

[lock[bot]]

This thread has been automatically locked since there has not been
any recent activity after it was closed. Please open a [new issue] for
related bugs.

If you feel like there's important points made in this discussion,
please include those exceprts into that [new issue].