Graham Leggett wrote: > Hi all, > > I have attached a small filter module that strips leading whitespace > from text files. This would typically be used to remove the "indenting" > whitespace found inside HTML files, resulting in a significant reduction > in network traffic for some sites. > > I didn't bother to include trailing whitespace removal, as this involved > buffering (leading whitespace removal requires no buffering). > > Comments?
this may be outside the scope of the example code, but filters like this probably ought to consider the ETag header. my personal opinion is that because the content will not be exactly the same bitwise as, say, a file on disk, any ETag header should be made weak to be compliant. I think roy didn't agree, but I never really understood his response last time I brought this up. anyway, if you start considering the ETag header, then you need to consider what happens when default-handler returns 304 and short-circuits your filter entirely. in this case the ETag returned would be the strong ETag created by ap_set_etag, even though the cached response was using a weak ETag. so, you would probably want to create a filter_init hook to weaken any ETag. but that ETag would possibly run in vain if your filter doesn't have any whitespace to change, so... anyway, I'm bringing this up only as something to consider - it's a real life problem for me that I have tried several times to figure out within the current filter architecture but have come up short. so, for a simple filter like this to be fully RFC compliant would be a bit help to others that want to apply filters in more complex settings. fwiw --Geoff
