Placeholder http.request.body truncates at max_size bytes, rather than producing a 413 error

[chris-morgan]

Issue Details

max_size documentation says:

max_size is the maximum size in bytes allowed for the request body. […] Reads of more bytes will return an error with HTTP status 413.

To begin with, that “reads of more bytes” thing feels a bad design when content-length is essentially always present—I think reasonable people would expect it to see that and immediately return 413 if appropriate, and only act the documented way in case of chunked, which is vanishingly rare and requires out-of-band negotiation; but that’s a separate matter, and one I don’t feel qualified to file an issue against.

But the issue here is that, when I use the http.request.body placeholder, it stops reading at this size, rather than triggering a 413 error as I reasonably expected. Truncating silently is an unfriendly failure mode, and can even be a security hazard.

My actual use case was handling a simple application/x-www-form-urlencoded form inside Caddy (mostly to see if I could; an fcgiwrapped shell script would probably have been just as easy/hard), with @foo vars_regexp {http.request.body} "(?:^|&)foo=(.*?)(?:$|&)" and such; and when done I tried capping the size because why not, and was bamboozled when it didn’t work.

Minimal example:

:8006 {
	request_body {
		max_size 10
	}
	respond `{{placeholder "http.request.body"}}`
	templates
}

$ curl http://127.0.0.1:8006 -d abcdefghijklm=nopqrstuvwxyz
abcdefghij

Assistance Disclosure

AI not used

If AI was used, describe the extent to which it was used.

No response