Basically, in HTTP 1.x there are only very specific times at which the server can respond throughout a request. In particular, there's no way to tell a client "please stop" when it is transmitting the request body.
So how most web applications handle request bodies that are too big is to either kill the connection (which to the client looks like a network issue) or patiently pipe the entire message to /dev/null before sending a response that indicates the message has not been processed (e.g. HTTP 413).
Unless I'm mistaken, this can be avoided if the client sends an honest Content-Length header, but this only works if the size is known in advance and the client is honest (you could submit an arbitrary number of bytes with a Content-Length header indicating something much smaller).
Because there is no clear way to distinguish a server aborting a request mid-body because of the size versus spontaneous existence failure, a client might misinterpret that and attempt to re-submit the same request later.
So how most web applications handle request bodies that are too big is to either kill the connection (which to the client looks like a network issue) or patiently pipe the entire message to /dev/null before sending a response that indicates the message has not been processed (e.g. HTTP 413).
Unless I'm mistaken, this can be avoided if the client sends an honest Content-Length header, but this only works if the size is known in advance and the client is honest (you could submit an arbitrary number of bytes with a Content-Length header indicating something much smaller).
Because there is no clear way to distinguish a server aborting a request mid-body because of the size versus spontaneous existence failure, a client might misinterpret that and attempt to re-submit the same request later.