httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: cvs commit: apache-2.0/src/main http_protocol.c
Date Fri, 13 Oct 2000 02:40:48 GMT

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

I expect to be ready to work on it early tomorrow or really late tonight.


> 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               
406 29th St.
San Francisco, CA 94131

View raw message