edicl/hunchentoot

How to limit the size of http request

Closed this issue · 0 comments

hello, If user's invalid http request body is very very long that take up a lot of memory,
I would like to ask you to add a limit, please,at around here:

(defmethod process-connection ((*acceptor* acceptor) (socket t))

I found some relevant information on the Internet:

Request limits define the validation criterion for incoming requests by enforcing size limits on HTTP request header fields. The requests that have fields larger than the specified maximums are dropped. Properly configured limits mitigate buffer overflow exploits, preventing Denial of Service (DoS) attacks.

is there any way to set the limit of request body size,
like client_max_body_size or maxrequestlength ,
also like post_max_size or upload_max_filesize ?
It is necessary to set something like *the-limit-of-request-size*
https://edicl.github.io/hunchentoot/#+http-request-entity-too-large+

(def-http-return-code +http-request-entity-too-large+ 413 "Request Entity Too Large")

the trouble i have on Linux 5.6.11 x86_64:
(I chang the information about the time and IP address in the error message and left the rest unchanged)

[yyyy-mm-dd hh:mm:ss [ERROR]] Error while processing connection: The condition The condition end of file on #<SB-SYS:FD-STREAM for "socket -.-.-.-:-, peer: -.-.-.-:-" {10015777B3}> occurred with errno: 0. occurred with errno: 0.
Heap exhausted during allocation: 179208192 bytes available, 268435488 requested.
Gen Boxed Code Raw LgBox LgCode LgRaw Pin Alloc Waste Trig WP GCs Mem-age
1 329 2 171 34 0 24601 12315 822047904 1641312 564315162 25137 2 0.6734
2 0 0 0 0 0 0 0 0 0 2000000 0 0 0.0000
3 0 0 0 0 0 0 0 0 0 2000000 0 0 0.0000
4 0 0 0 0 0 0 0 0 0 2000000 0 0 0.0000
5 0 0 0 0 0 0 0 0 0 2000000 0 0 0.0000
6 430 2 183 55 0 10 0 21707232 575008 2000000 680 0 0.0000
Total bytes allocated = 843755136
Dynamic-space-size bytes = 1073741824
GC control variables:
GC-INHIBIT = false
GC-PENDING = true
STOP-FOR-GC-PENDING = false

I am sorry to asked a repetitive question, but i am sad that it hasn't been solved.