On Sun, 25 Jul 2021 at 17:19, Nick Kew <n...@apache.org> wrote: > > > > > On 24 Jul 2021, at 14:59, sebb <seb...@gmail.com> wrote: > > > > I'm trying to write a filter to add a banner to some HTML pages. > > > > I have used the following definition: > > > > ExtFilterDefine rebootbanner mode=output \ > > intype=text/html outtype=text/html \ > > cmd="add_banner.sh" > > > > The script contents boil down to: > > > > echo header > > cat > > echo footer > > > If they're HTML, that'll break badly! You'd need to add the header > and footer within the HTML <body>.
In theory, yes, but in practice, browsers seem to cope OK. > Markup-aware filters will do that, > or you could (at fairly low risk) use a sed or regexp search-and-replace > filter. Indeed, and that is something that can be added later if necessary. > A second consideration is that with ExtFilter you're incurring two performance > penalties. Spawning an extfilter process (a CGI-equivalent overhead) > and pumping your data through the filter. I know, but this is mainly a PoC at present. Also I see the same behaviour with a LuaOutputFilter. > > This works fine for some pages, however other pages fail to display in > > a browser. > > Turns out that the issue is that the input to the filter is sometimes > > gzipped. > > The header causes issues for the browser display. > > > How can I ensure that the filter is run before the output is gzipped? > > It's many years ago so memory is hazy, but making filtering play nicely > with gzipped contents, particularly in a proxy situation, was one of the > main motivations behind both mod_filter and the INFLATE output filter in > mod_deflate. Revisiting the documentation I see the image downsampling > example in the mod_filter page applies the same principle (and also dates it - > that was for a proxy accelerator for mobile phones pre-3G). I have done some further tests, and it looks like the problem is due to the use of Passenger, rather than an issue with Apache itself. It also seems that I can get round the issue by inflating first. Thanks anyway. > -- > Nick Kew > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org > For additional commands, e-mail: users-h...@httpd.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
