Nick Kew wrote:
I have just set up the most recent httpd v2.0.51-dev tree, and have configured a filter that strips leading whitespace from HTML:
AddOutputFilterByType STRIP text/html
The content is served by mod_proxy.
As it stands, that can't work.
Then as it stands filter's are broken.
Putting on an end user hat I see no reason why AddOutputFilterByType shouldn't do exactly what it says it does.
It's a manifestation of the problem I'm addressing by reviewing the filter architecture: see http://www.apachetutor.org/dev/smart-filter and the "Ideas for smart filtering" thread here.
Reading the above, it seems that people are alergic to having filters look at headers to decide whether they should be valid or not.
Having a totally generic non HTTP filter sounds like a nice idea, but in practice it's a real pain in the ass. The filters need the knowledge contained in the headers regardless otherwise they simply won't work. They can either access the headers directly, or they can access some generic interface that warps the headers into something generic for the filters to access. Right now it seems filters do neither.
This is really annoying for an end user. Having developed the filter we need for our application, we deploy it and now find we cannot use it. For us it's back to the drawing board. :(
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
