At 05:18 AM 5/15/2002, Greg Stein wrote: >On Tue, May 14, 2002 at 11:52:25PM -0500, William A. Rowe, Jr. wrote: > > I'm running across one particularly troubling example in the MS ISAPI > example > > extensions [other than all of the bugs I've documented at > > www.apache.org/~wrowe/] > > > > There is a chunking example that sends a chunked response to the > client. I > > imagine > > other authors have written similar cgi scripts that attempt to do this > as well. > > > > Suppose we look for the cgi/isapi to set the chunked response flag, and > then > > insert our dechunk filter at the head of the output stack? Think that > > would fly? > >No. Bleck. If the "chunked response flag" is not already private, it really >should be. Modules should not be setting that [any more]. We absolutely >should not compensate for modules which do.
Wait... not the internal 'bit flag'! I'm talking about "transfer-coding: chunked" header printed by the CGI application. The other answer [although it's 'late' in the game to try this switch] is to treat this as a late-discovered NPH script, or force the author to deal with the module as NPH [and lose keep-alives while we are at it? That's a real bleck :-] >[ and yes: modules *do* need to change w.r.t. how they handle output. I had > to remove byte-range handling from mod_dav; that is now handled in the > core; by a similar analogy, chunking is handled in the core ] CGI and ISAPI are established specs, not "Apache Modules" which did change. Sure, chunked output in 2.0 is a hassle, suboptimal at that, but I don't see any parallels. A better parallel would be your viewcvs revision. Say that used chunking to accomplish it's goals. Why recode your .py scripts (except to tune performance to given servers/platforms?) Bill
