Currently, the content-length filter attempts to compute the length
of the entire response before passing any data on to the next filter,
and it sets request_rec->bytes_sent to the computed content-length.
This is bad for several reasons:
* The C-L filter needs to know the length of every bucket that
passes through it. If it sees a pipe bucket, for example, it
has to read and buffer all the data, regardless of how large it
is. (To be strictly accurate, it can push the data downstream
in 32KB chunks, but only if the client supports chunked encoding.)
* In order to compute the C-L in time to put it in the response
header, the C-L filter sets aside buckets until it sees EOS.
This can be a big performance problem in some real-world cases.
For example, given a .shtml file that includes several small,
non-parsed files, the setaside logic in the C-L filter will do
an mmap+memcpy+munmap of each of the included files.
* r->bytes_sent is used by mod_log_config as a count of bytes sent
to the client (minus response header). But the value that's
computed in the C-L filter isn't necessarily equal to the number
of bytes sent, as there may be additional filters between the
C-L filter and the client that affect the output (the chunking
filter, for example, or mod_deflate).
What I'd rather do is:
* Compute r->bytes_sent in core_output_filter(), so that it accurately
represents bytes sent to the client.
* Compute and save the response header length in ap_http_header_filter
so that code that the logger can subtract it from r->bytes_sent.
* Simplify the C-L filter so that it:
- Computes the content-length if it sees an EOS in the first brigade
passed to it,
- Acts as a simple pass-through in cases where it can't get the C-L
from the first brigade,
- And never sets aside any buckets.
(Note that this means we won't be able to send a C-L on SSI requests
any more. But we'll be able to deliver the responses faster, because
we won't have to incur the mmap+memcpy+munmap to setaside file buckets
inside the C-L filter.)
Before I start modifying any filters, does anyone have an argument
in favor of maintaining the current implementation?
Thanks,
--Brian
