Bug 47253

https://issues.apache.org/bugzilla/show_bug.cgi?id=39727 is past, but it
would seem Apache do not understand its own new generated values with suffix
"-gzip" of Etag received in If-None-Match header. Each resource at each
request is compressed on-the-fly. Status 304 respose does not occur.

Example configuration: =====================================================

<FilesMatch "\.(css|...)$">
	SetOutputFilter	DEFLATE
</FilesMatch>

HTTP request and response: =================================================

GET /manual/style/css/manual.css HTTP/1.1
Host: server.tld
User-Agent: Firefox/3.0
Accept: text/css,*/*;q=0.1
Accept-Language: de,de-de;q=0.8,en;q=0.5,en-us;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer	http://server.tld/manual/mod/core.html
If-Modified-Since: Wed, 12 Jul 2006 03:20:01 GMT
If-None-Match: "677d6-48f2-41859ec369a40"-gzip
Cache-Control: max-age=0

HTTP/1.1 200 OK
Date: Fri, 22 May 2009 19:57:07 GMT
Server: Apache
Cache-Control: no-transform, max-age=15
Last-Modified: Wed, 12 Jul 2006 03:20:01 GMT
Etag: "677d6-48f2-41859ec369a40"-gzip
Accept-Ranges: bytes
Expires: Fri, 22 May 2009 19:57:22 GMT
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 4088
Keep-Alive: timeout=30, max=91
Connection: Keep-Alive
Content-Type: text/css; charset=iso-8859-1


Identically there are values of If-Modified-Since and If-None-Match as well as Last-Modified and Etag.