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_protocol.c
Date Fri, 13 Oct 2000 02:47:59 GMT
> From: rbb@covalent.net [mailto:rbb@covalent.net]
> Sent: Thursday, October 12, 2000 9:41 PM
> 
> > For CGI, what if...
> > 
> >   create pipe
> >   while get input buckets
> >       write pipe
> >   set child's content-length
> >   create, run child from pipe with content-length  
> > 
> > Really it's a case where we want the consumer (mod_cgi) to pass its
> > preference back up the chain to the core input bucket 
> creator, saying
> > we want a pipe.  Win32 pipes are fixed length, so this 
> solution sucks
> > there, but perhaps for other platforms?
> 
> mod_cgi can't have a pipe for input.  The best we could do is 
> create some
> way to take all the data from a socket and send it to a pipe.  This is
> solved easiest by just using ap_get_client_block though, so I wouldn't
> change that.

I wasn't clear.  mod_cgi would create the pipe, suck in the entire POST,
create a cgi process with the (now resolved) REQUEST_LENGTH, and send the 
write end to the cgi process.
 
> I suggest that somebody (I volunteer) implements what we discussed
> today.  This is already about 75% done, there are a few 
> things to change, and then we all talk about it again.

+1

> I expect to be ready to work on it early tomorrow or really 
> late tonight.
> 
> Ryan
> 
> 
> > 
> > It's pretty clear our entire filtering schema will 
> eventually call for
> > a mod_cgid2.  Till then might this work?
> > 
> > For DOS issues and CGI, it seems we may need some global limiting
> > mechanism for these (seemingly unlimited) pipes, as an aggragate and
> > individually by directory/file (or perhaps based on user auth).  We
> > haven't even begin to tap that area, but it is an issue for the top
> > level, perhaps a preference from the handler and intervening input
> > filters.
> > 
> > ------
> > 
> > Deja vu...
> > 
> > We will have to have a communcations mechanism, just like I brought
> > up at the filtering meeting, for consumers to express its 
> preferences
> > to it's upstream provider - and if that provider (filter) 
> doesn't care,
> > it passes it on to the next upstream provider.  There has 
> to be a noop
> > and don't care option, as well.  If a handler wants a pipe 
> (like this
> > cgi example) it can express that.  If a filter/handler for 
> compression
> > wants persistant bytes, then it can express that as well.  
> Clever and
> > clean handlers/filters will take the best of what they can do, and
> > we won't see all the copies I'm expecting as we start 
> mixing different
> > input and output filters.
> > 
> > I'd say this entire scheme would be a 2.1 optimization, if we don't
> > start hitting roadblocks first.
> > 
> > Bill
> > 
> 
> 
> ______________________________________________________________
> _________________
> Ryan Bloom                        	rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> --------------------------------------------------------------
> -----------------
> 
> 

Mime
View raw message