fpm-apache: compressed responses never get a 304 (mod_deflate's -gzip ETag) #735

Steps To Reproduce

1. docker run --rm -p 8080:8080 -v "$PWD:/var/www/html/public" serversideup/php:8.5-fpm-apache with a CSS file of a few kB in the current directory.
2. curl -s -D - -o /dev/null -H 'Accept-Encoding: gzip' http://localhost:8080/big.css returns ETag: "1395-…-gzip".
3. Send it back: curl -s -o /dev/null -w '%{http_code}\n' -H 'Accept-Encoding: gzip' -H 'If-None-Match: "1395-…-gzip"' http://localhost:8080/big.css

Outcome

What did you expect?

304 Not Modified, as for the uncompressed response with its ETag.

What happened instead?

200 with the full body. mod_deflate appends -gzip to the ETag (DeflateAlterETag AddSuffix, the default) and never matches that ETag in If-None-Match, so a browser never gets a 304 for a compressed response and downloads it again on every revalidation. ETags sent by PHP behave the same.

Affected Docker Images

serversideup/php:8.5-fpm-apache (Apache 2.4.69), all fpm-apache images.

Anything else?

DeflateAlterETag Remove (Apache 2.4.58+) fixes it: compressed responses go out without an ETag, browsers revalidate with If-Modified-Since and get a 304. NoChange would give gzip and identity one strong ETag, which lets a mixed If-Range request get a 206 cut from the gzip bytes. https://httpd.apache.org/docs/2.4/mod/mod_deflate.html#deflatealteretag

Fixed in #734.