httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Trawick" <traw...@gmail.com>
Subject input filter which modifies body, Content-Length
Date Thu, 23 Feb 2006 18:52:45 GMT
(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?

Mime
View raw message