httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <...@covalent.net>
Subject RE: [PATCH] AddOutputFiltersbyType
Date Fri, 15 Mar 2002 17:39:23 GMT
Sander and I were just discussing this on IRC, because there is a
chicken and egg problem here.  The problem is that the filter order is
defined at registration time, which means that the filter order problem
can't be solved with a new filter.

The only clean way to implement this (IMHO), is to create a function
that sets the content-type.  That function would then be able to call
AddOutputFilterByType automatically, and it would insert filters
correctly at the correct times.

This would also allow us to make the content-type in the request-rec a
const string, because the only safe way to change it is through the
accessor.

This idea came from both Sander and I, but any mangling done in this
description is mine alone.

Ryan

----------------------------------------------
Ryan Bloom                  rbb@covalent.net
645 Howard St.              rbb@apache.org
San Francisco, CA 

> -----Original Message-----
> From: Ryan Bloom [mailto:rbb@covalent.net]
> Sent: Friday, March 15, 2002 9:22 AM
> To: 'Bill Stoddard'; dev@httpd.apache.org
> Subject: RE: [PATCH] AddOutputFiltersbyType
> 
> 
> > > > The essential feature of this patch is that
> > > > ap_add_output_filters_by_type() is called out
> > > > of the ap_http_header_filter.
> > >
> > > You can't solve this problem this way.  The problem here, is that
> the
> > > first time down the filter stack, the data won't go through the
> correct
> > > filters.  Think of what would happen if you had CGI script that
> output
> > > text/html, and you had
> > >
> > > AddOutputFiltersByType INCLUDES text/html.
> > >
> > > With this patch, it would be possible to miss SSI tags in the
first
> > > chunk of data.
> > Not sure I understand why this is the case.  The call to
> > ap_add_output_filters_by_type()
> > is being called right before the call to insert the chunked encoding
> > filter. If what you
> > say is true, then wouldn't the problem exist with the chunked
encoding
> > filter as well?
> 
> Nope.  The thing is that we insert filters in a defined order,
specified
> by the filter type.  The chunked filter is a protocol filter, so it is
> by definition after the HTTP_HEADER filter.  However, the INLCUDES
> filter is a RESOURCE filter, so it is by definition before
HTTP_HEADER.
> 
> > > The only way to do this, is to have a filter at the end of the
> RESOURCE
> > > and CONTENT_SET filter stacks.  That filter would add more
filters,
> and
> > > then move itself to below those new filters to check if the
> content-type
> > > has changed.
> >
> > Yep, I considered this and will implement it if this is what we
really
> > need to do.
> 
> Take a look at my comments above, if they aren't clear, I will try to
go
> into more detail.  BTW, the hard part about doing this, is that we
have
> to re-insert the AddOutputFilterByType filter _after_ the new filter
> that is being added, and we need to be sure that the new filter
actually
> sees the content, which is NOT going to be easy to do, because of the
> filter order.
> 
> In reality, I don't see a good way to implement this feature.
> 
> Ryan
> 



Mime
View raw message