httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject RE: cvs commit: apache-2.0/src/main http_core.c http_protocol.c
Date Tue, 03 Oct 2000 00:49:33 GMT
> 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).

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

> 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.

Mime
View raw message