(Apologies if there is juicy past discussion that I didn't find with my search keywords.)
It isn't clear to me what an input filter should do about Content-Length when it modifies the length of the body (assuming that this isn't chunked encoding). It causes problems for some handlers to modify the length of the request body but leave Content-Length alone. Handlers which care about Content-Length have probably already looked at it before the input filter has been called anyway. A handler that uses brigades to read the body and has no need to look at Content-Length should be okay either way. mod_cgi uses brigades to read the body but needs to look at Content-Length before spawning the CGI script, so that's problematic. And there is an unexpected ordering requirement so that the input filter can signal to this handler that the content-length can't be trusted, before mod_cgi spawns the child. ap_setup_client_block() looks at the initial Content-Length to know how much to read, so that's problematic but perhaps fixable for these types of handlers. A filter which spools up to a configured amount of request body in order to calculate content-length could be of some practical benefit, since many request bodies are relatively small and this could potentially allow mod_cgi[d] to properly handle chunked request bodies, regardless of input filtering. With such a filter installed, and no need to spool beyond a configured limit, getting a brigade would return bucket(s) with known length and an EOS at the end. Unknown lengths or EOS? Better punt if you're mod_cgi[d]. Thoughts?
