httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: [PATCH] dechunking, body filtering (fwd)
Date Mon, 16 Oct 2000 17:45:47 GMT

> > >   we're in some buffering logic on output...  we need to know whether
> > >   there is more data already received on input (the next request)
> > >   before we decide to sent a small amount of data...  HTTP_IN would be
> > >   holding onto such data if it has been received...  we need to take a
> > >   look in its context
> > 
> > This is a bogus example.  We don't do that.  
> 
> Go look at ap_bhalfduplex().

But ap_bhalfduplex is going away as soon as input filtering is done,
because it won't make any sense any more.  We will need to find another
way to do similar things, but peeking at the data isn't going to work
well.

> > > . ap_get_client_block() telling the next filter that it can only
> > >   accept 8192 bytes breaks certain cases like a pipe bucket.  Do we
> > >   need to implement some sort of filter to sit below
> > >   ap_get_client_block() to get everything in memory and return only
> > >   the desired amount of data?  All this to avoid a field in the r?
> > 
> > Ummm, since there is no filter that returns a pipe bucket on input this
> > too is a bogus example.  We aren't talking about adding a new filter.  If
> > your filter creates a pipe bucket, then yes it is your filters
> > responsability to make sure we don't return too much data.
> 
> Not nearly as bogus as your ftp->http conversion filter :)  A real
> life example: mod_ext_filter in output-filter mode needs to be changed
> to construct a pipe filter for output once we know we have delivered
> the child process all the data to filter.  The same should happen with
> the input side. 

As soon as I have a free hour or so I will be implementing my ftp
module.  I haven't done it yet, because I haven't had any time
recently.  It is a module I have spoken to many people about however, and
it is going to happen.

> Hey, I'm happy to set a field in c instead of HTTP_IN's context data.
> The only reason I put it in the ctx is that I thought you were gung ho
> on leaving the c alone.  Sometimes we aren't so religious when it
> comes time to arrange the bits to actually accomplish something.

I was.  Unfortunately, there is no clean solution.  This was the least
messy in my opinon.

> Suppose I change the way we tell HTTP_IN (or whichever hypothetical
> filter provides the same service) how many body bytes are left so that
> it matches your change from this weekend...

Fine.

> The remaining issue is that I have ap_get_client_block() save state
> between calls.  In exchange, all input filters are simplified in that
> they don't care how many bytes the caller wants; they do what is
> reasonable (and the pipe bucket *is* a reasonable example; other folks
> will need buckets of indeterminate length too).  

First of all, that brigade should never be in the request_rec.  If it is
going to be stored anyplace, it needs to be in the core's request_rec
module data, core_dir_config.  If you move that brigade, I won't stop the
patch.  I still think input filters should be informing lower level
filters how much data they can accept, but I won't fight for it.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------




Mime
View raw message