Bug#1120319: apache2: mere presence of mod_includes (SSI) in filter chain prevents 304 from working

[Thorsten Glaser <tglaser@b1-systems.de>]

Source: apache2
Version: 2.4.65-1~deb11u1
Tags: upstream
X-Debbugs-Cc: tglaser@b1-systems.de

I have a setup which uses SSI to augment some HTML files,
but that also serves static PDFs with working Last-Modified
header. However, attempts to use If-Modified-Since with it
fail. I’ve been able to track this down to the mere *presence*
of SSI in the filter chain: even if I do…

	FilterDeclare SSI
	FilterProvider SSI INCLUDES "-R '1.2.3.4/32'"

	FilterChain ! Piwik SSI Compress

… it fails to work (despite the request not coming from 1.2.3.4/32).

If I	FilterChain ! Piwik Compress
then things work, so it’s indeed *just* that (also confirmed
with mod_info and -DDUMP_CONFIG), the two other filters are
unrelated.

I have the, perhaps naïve, expectation that a thing in the filter
chain should not affect requests that do not match its expression.

In fact, people report all over the internet that mod_deflate
ruins ETags and 304, but the Compress filter…

	FilterDeclare Compress
	FilterProvider Compress DEFLATE "%{CONTENT_TYPE} =~ m#^text/(html|plain|xml|css)#"
	FilterProvider Compress DEFLATE "%{CONTENT_TYPE} =~ m#^application/(x-javascript|javascript|ecmascript|r

… DOES honour its expressions and doesn’t break PDF caching.