httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject computing C-L (was: Re: [Patch]: mod_include.c ...)
Date Tue, 21 Nov 2000 02:11:44 GMT
On Mon, Nov 20, 2000 at 12:31:28PM -0800, wrote:
> > A filter which expects to change the content length should unset the
> > Content-Length header field.
> No.  That is making the filter do too much.  There is no reason to ever
> set the content-length in any module.  The core can do it much
> better.  Allow me to explain a bit.  If the handler sets the C-L, and
> mod_include unsets it, and the re-sets it to the new value, and then
> mod_gzip unsets it and re-sets it to the correct value, then we have just
> computed the thing three times, but only the last one was valid.
> All handlers and filters should punt the c-l computation to the c-l
> filter.  If that filter can compute the c-l, then it does, once.  If it
> can't, then it just passes the data on.  It makes no sense for filters to
> be trying to set this, because it makes it harder to write
> filters/handlers, and the information is almost never going to be used.

We should not always punt to the C-L filter. That filter must have the whole
output brigade available to compute the length. It is entirely possible that
the handler knows the proper length and can set the value. It is the
presence of a filter that changes the length, which is the problem.

I'm perfectly okay with a filter unsetting the C-L because it is changing
the length.

Consider it from the semantic standpoint: the handler says, "here is the
content, and it is <this> long." But there is this sneaky filter hanging out
in there (and the handler should *not* know that), and the filter says
"well, I'm gonna change the length."

Whether the filter knows the final length or not is beside the point. The
handler should be able to set it, and the filter should unset it.

> > If a filter unsets the Content-Length header field, magic should
> > happen (i.e., the core code should chunk or compute content length or
> > let it stream as appropriate).  The core support for this has been
> > working in the past.  A couple of quick tests with mod_autoindex
> > (HTTP/1.0 and HTTP/1.1) indicates that the right stuff is happening.
> As things stand right now, if the c-l is set by the handler, the c-l
> filter ignores it and re-computes if possible.

But what if the handler got it right, and there are no intervening filters?
Why should the C-L filter buffer up the response to recompute the thing?


Greg Stein,

View raw message