httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: filters and subrequests
Date Thu, 24 Aug 2000 22:10:15 GMT
On Thu, 24 Aug 2000, Allan Edwards wrote:

> > Sub requests may have more filters than the main request.  
> OK I understand that, but they will be added during 
> subrequest processing - no? and the inherited ones 
> will still be in the list so we don't need to add 
> them again.

They will be added during sub-request processing, and the inherited ones
should not be added again.  The real problem comes back to the fact that
the install-filters hook is fundamentally wrong.  Removing it from the
sub-request doesn't solve the problem, because we need to give the
sub-request the same opportunity to insert new filters.

> ap_run_insert_filters currently only handles hooked 
> filters, is that going to change?

ap_run_insert_filters just gives modules a chance to insert their own
filters.  The problem right now, is that all of the current filters are
being inserted unconditionally.  This is where the problem is, not that we
are calling the insert_filters code twice.

> If it's broken that doesn't enhance its flexibility :)
> Maybe someone can explain how the example below is 
> supposed to work then I can fix it.

> > > e.g. if we process an SSI with an 'include file', 
> > > the subrequest that processes the included file 
> > > ends up with the filter sequence:
> > > and we write out the file without any chunking headers.

The problem is core inserts it's filter unconditionally.  Either core
needs some logic to only insert the filter once, most likely by moving
where we insert the core fitler to when we create the originally
request, or we should remove the insert-filter call from the code
completely.  The solution is not to allow a sub-request to be created
without the filters.


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message