Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add max_size parameter to web.Request reading methods #1133

Closed
asvetlov opened this issue Aug 27, 2016 · 7 comments
Closed

Add max_size parameter to web.Request reading methods #1133

asvetlov opened this issue Aug 27, 2016 · 7 comments
Labels
Milestone

Comments

@asvetlov
Copy link
Member

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
Copy link
Member Author

Should raise 413 on size overloading

@asvetlov asvetlov added the good first issue Good for newcomers label Aug 28, 2016
@f0t0n
Copy link
Contributor

f0t0n commented Aug 28, 2016

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
Copy link
Contributor

f0t0n commented Aug 28, 2016

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
Copy link
Contributor

f0t0n commented Aug 28, 2016

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
Copy link
Member Author

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
Copy link
Member

argaen commented Sep 1, 2016

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
Copy link

lock bot commented Oct 29, 2019

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.

@lock lock bot added the outdated label Oct 29, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Oct 29, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants