You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@bellsouth.net> on 2000/11/20 21:21:49 UTC
Re: [Patch]: mod_include.c port to 2.0 buckets (includes newmod_include.h)
"Bill Stoddard" <bi...@wstoddard.com> writes:
> There is definitely a content length problem. parsed content should not have a
> content length header added, yet the default handler is adding one. I suspect
> it should be removed and chunked encoding set somewhere in the path, I am just
> not yet sure where this should happen.
>
> Bill
A filter which expects to change the content length should unset the
Content-Length header field.
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.
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: computing C-L (was: Re: [Patch]: mod_include.c ...)
Posted by Jeff Trawick <tr...@bellsouth.net>.
"Paul J. Reder" <re...@raleigh.ibm.com> writes:
> rbb@covalent.net wrote:
> > Just always unset it. The core always figures out the c-l if it needs to
> > and can. If it can't or doesn't need to, the core does the right thing.
>
> I can hunt through and figure it out, but it might save time to give
> me a quick clue as to how to "Just always unset it." Like which function
> to call to mess with header fields.
apr_table_unset(f->r->headers_out, "Content-Length");
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: computing C-L (was: Re: [Patch]: mod_include.c ...)
Posted by rb...@covalent.net.
On Tue, 21 Nov 2000, Paul J. Reder wrote:
> rbb@covalent.net wrote:
> > Just always unset it. The core always figures out the c-l if it needs to
> > and can. If it can't or doesn't need to, the core does the right thing.
>
> I can hunt through and figure it out, but it might save time to give
> me a quick clue as to how to "Just always unset it." Like which function
> to call to mess with header fields.
call
apr_table_unset(r->headers_out, "Content-Length");
should work.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: computing C-L (was: Re: [Patch]: mod_include.c ...)
Posted by "Paul J. Reder" <re...@raleigh.ibm.com>.
rbb@covalent.net wrote:
> Just always unset it. The core always figures out the c-l if it needs to
> and can. If it can't or doesn't need to, the core does the right thing.
I can hunt through and figure it out, but it might save time to give
me a quick clue as to how to "Just always unset it." Like which function
to call to mess with header fields.
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
Re: computing C-L (was: Re: [Patch]: mod_include.c ...)
Posted by rb...@covalent.net.
Just always unset it. The core always figures out the c-l if it needs to
and can. If it can't or doesn't need to, the core does the right thing.
Ryan
On Tue, 21 Nov 2000, Paul J. Reder wrote:
> I need to know what mod_include should do in this case. I can certainly unset
> the field, but I would have to unset it before I know if it needs to change
> (I think).
>
> I certainly don't think I should try to compute the length because
> a single request may have several SSIs in it requiring the field to change as
> I encounter each one. And to make matters worse, some of the content is
> generated inside sub requests.
>
> Any help would be greatly appreciated. No version of mod_include will be able
> to work properly until this is resolved.
>
> --
> Paul J. Reder
> -----------------------------------------------------------
> "The strength of the Constitution lies entirely in the determination of each
> citizen to defend it. Only if every single citizen feels duty bound to do
> his share in this defense are the constitutional rights secure."
> -- Albert Einstein
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: computing C-L (was: Re: [Patch]: mod_include.c ...)
Posted by "Paul J. Reder" <re...@raleigh.ibm.com>.
I need to know what mod_include should do in this case. I can certainly unset
the field, but I would have to unset it before I know if it needs to change
(I think).
I certainly don't think I should try to compute the length because
a single request may have several SSIs in it requiring the field to change as
I encounter each one. And to make matters worse, some of the content is
generated inside sub requests.
Any help would be greatly appreciated. No version of mod_include will be able
to work properly until this is resolved.
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
Re: computing C-L (was: Re: [Patch]: mod_include.c ...)
Posted by rb...@covalent.net.
> > > 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?
The c-l filter should almost never buffer the whole response. It should
only ever buffer everything if it is a 1.1 request and it can't chunk for
some reason.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
computing C-L (was: Re: [Patch]: mod_include.c ...)
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Nov 20, 2000 at 12:31:28PM -0800, rbb@covalent.net 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?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [Patch]: mod_include.c port to 2.0 buckets (includes newmod_include.h)
Posted by Jeff Trawick <tr...@bellsouth.net>.
rbb@covalent.net writes:
> > 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.
Oops... I didn't realize that we started ignored content length fields
set by the handler (or a filter).
--
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: [Patch]: mod_include.c port to 2.0 buckets (includes newmod_include.h)
Posted by rb...@covalent.net.
> 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.
> 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.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------