httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject RE: cvs commit: apache-2.0/src/main http_core.c http_protocol.c
Date Tue, 03 Oct 2000 13:42:22 GMT
On Mon, 2 Oct 2000, William A. Rowe, Jr. wrote:
> > From: rbb@covalent.net [mailto:rbb@covalent.net]
> > Sent: Monday, October 02, 2000 7:19 PM
> > 
> > If I understand what you are saying, you want filters to be able to
> > determine where data came from.
> 
> No, I want the filter to -know- the data they were handed, that is
> its charset, mime type and other headers (not who created it or how), 
> and what its persistance is (so we can set aside or copy as appropriate).

Okay, they do know this information.  Everything is in r->headers_out, and
filters have every right to modify those headers.  Of course, the
modification will only take if no headers have been sent yet.  :-)

> That's it.  The filter doesn't choose to coalesce, the admin configs
> that filter in the right place, if they required it.

But, the admin really doesn't and shouldn't know about coalescing.  That
is an optimization that we need, and how we coalesce depends on the type
of network and the type of response.

> > I probably wasn't clear enough with this example.  If filters need to do
> > just buffering they should try to do coalescing too.  They should use
> > ap_append_brigade to put two brigades together, and store that one brigade
> > in their context.  That's how buffering should be done.
> >
> > If we want to buffer data, do that with a call to
> > ap_save_data_to_filter.  If we want to coalesce, don't, 
> > that's the core's job.  :-)
> 
> Yet the core needs to know that the data should be shoved now, in the
> case of cgi.  I'm satisfied with your argument that if the api is
> simple enough (and the code short enough) filters can do so as necessary.
> It still seems unnecessarily restrictive, however.

Data is not shoved now in the case of CGI's.  Data is shoved now in two
cases, we have enough data to make a packet worth it.  Or, we dont' have
enough data, but it has been a long time since we got any, so we should
send more now.  In order for the second case to happen, the CGI modules
need to be written correctly, and we need a please flush bucket.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


Mime
View raw message