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

How to limit max size of the request body? #452

Closed
kachayev opened this issue Dec 18, 2018 · 4 comments · Fixed by #663
Closed

How to limit max size of the request body? #452

kachayev opened this issue Dec 18, 2018 · 4 comments · Fixed by #663
Assignees

Comments

@kachayev
Copy link
Collaborator

Which is a typical safety requirement, something like client_max_body_size directive for Nginx.

Netty's HttpObjectAggregator provides this functionality out of the box. The problem with introducing the same kind of settings for our handlers is that the error most probably will be detected after the user's handler was invoked (when reading :body stream). Closing input stream from Aleph side would probably lead to unexpected behavior. Maybe we can provide some kind of a helper to "read body but not more than X bytes" that will throw an exception when the body is too large (it also would be nice to have the same helper to work correctly both with InputStream and manifold's stream for raw handlers)?

Another interesting question here: if I return 413 Entity Too Large response from the handler, how can I force Aleph to close the connection after the response is sent? Regarding RFCs the client have to monitor server response even while transfering request body and have to stop sending it in case of the response arrived earlier. In practice, this is usually not handled well.. so mostly probably I would like to close the connection to make sure that if a client misbehaves - that is its problem, not mine.

@kachayev
Copy link
Collaborator Author

I think we can add an additional setting, e.g. :max-request-body-size, that will effectively change the execution flow:

  1. Aggregate body before handler's invocation
  2. Respond with 413 status code and close the connection in case a request body exceeds the limit given

This is not the best option when handling larger requests, but it might be super useful to cover and protect those use cases when I know in advance that my server is working with small (or relatively small) payloads, e.g. RPC server or forms w/o file uploading functionality etc. This might be done by introducing Netty's HttpObjectAggregator into the pipeline or manually dealing with buffering (at least ring-handler is already doing this to follow request buffer capacity setting.

@dspearson
Copy link
Contributor

This would be very nice to have. One of my projects is in a fairly early state of development, but this will be a necessary feature at some point; it's designed to be a standalone application, but exposed to a potentially-hostile network environment.

Thank you for your work so far. It is appreciated very much.

@jhimanka
Copy link

ring-clojure/ring#297
Maybe relevant? This would be useful for us as well. Could be at Aleph, Ring or reverse proxy level.

@arnaudgeiser
Copy link
Collaborator

This might be done by introducing Netty's HttpObjectAggregator into the pipeline

In my opinion, this is the easiest and more solid approach.
We inject HttpObjectAggregator into the pipeline when max-request-body-size is defined.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants