httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@algroup.co.uk>
Subject Re: cvs commit: httpd-2.0/server/mpm/perchild perchild.c
Date Mon, 07 May 2001 19:39:56 GMT
rbb@covalent.net wrote:
> 
> > > rbb         01/05/06 16:27:14
> > >
> > >   Modified:    include  util_filter.h
> > >                modules/experimental mod_case_filter_in.c mod_charset_lite.c
> > >                         mod_ext_filter.c
> > >                modules/http http_protocol.c http_request.c mod_core.h
> > >                modules/mappers mod_alias.c
> > >                modules/tls mod_tls.c
> > >                server   core.c protocol.c util_filter.c
> > >                server/mpm/perchild perchild.c
> > >   Log:
> > >   Back out the recent change to ap_get_brigade, to make it use indirection
> > >   again.  The problem is that the amount of data read from the network,
> > >   is not necessarily the amount of data returned from the filters.  It is
> > >   possible for input filters to add bytes to the data read from the network.
> >
> > What isn't clear to me is what a filter is supposed to put into
> > readbytes - could you explain, please?
> 
> Readbytes is only to be used by the filter that actually reads from the
> network and the function that is requesting information.  The function
> that is requesting information (i.e. the top of the filter stack),
> should insert either 0 or a positive value.  0 means read one line of
> input, a positive value means read no more than this amount from the
> network.
> 
> The filter that is reading from the network should insert the number of
> bytes read.  All other filters should ignore this value.  That's why this
> used to be a field in the conn_rec, but at the hack-a-thon, it was
> decided that this should be a parameter instead.
> 
> The whole reason for this field, is that it is impossible to determine
> when one request is done and another begins without information that is
> stored in the request_rec.

Umm. I don't see how this will work with SSL - the number of bytes read
at the network layer does not correspond to anything happening at the
request layer...

Seems to me that this is being used to do something rather magical and
protocol dependent...

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Mime
View raw message