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 [EMAIL PROTECTED] 645 Howard St. [EMAIL PROTECTED] San Francisco, CA > -----Original Message----- > From: Ryan Bloom [mailto:[EMAIL PROTECTED]] > Sent: Friday, March 15, 2002 9:22 AM > To: 'Bill Stoddard'; [EMAIL PROTECTED] > 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 >
