-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Warn about aggregate possibly consuming a lot of RAM? #2414
Comments
Yes, it's possible to use without protection, and that could be problematic. I see it kind of similar to Read::read_to_end. That doesn't include a warning. That said, I see nothing wrong with including a warning in the documentation. My personal view is that an So, I'd be fine with adding a warning, but otherwise I'll just close this. |
I'd say situations where I can trust local files are much more common than trusting something on the other side of the Internet. And sometimes, one has no option than just support arbitrary clients.
Thanks :-). |
Yes, certainly. Though, |
The to_bytes and aggregate don't check how long the body is, so the user better be aware. Relates to #2414.
The to_bytes and aggregate don't check how long the body is, so the user better be aware. Relates to hyperium#2414.
Hello
I'm wondering about one thing. Let's say I have a web server and it wants to get the whole body sent by the user in
POST
. The aggregate would be a good candidate for that. However, I think there's no way of protecting against the client sending excessive amounts of data and consuming all my RAM that way (at least, I've found none).I could check the
Content-Length
header first, before calling this function. However, if the client is sending with chunked encoding, the header is optional. That makes the function (and its siblingto_bytes
) potential DoS hazard.Therefore I wanted to ask if there should be some kind of
aggregate_with_limit
function, or if the documentation should at least include a warning and point out the fact it shouldn't be used when exposed to untrusted clients.The text was updated successfully, but these errors were encountered: