Interesting dechunk question for cgi/isapi

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

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?
Of course we would simply rechunk later, but that's based on the server core.

Bill

Re: Interesting dechunk question for cgi/isapi

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

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

Re: Interesting dechunk question for cgi/isapi

[Greg Stein <gs...@lyra.org>]

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.

[ 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 ]

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/