Lighttpd

With mod_compress enabled, invalid ETags are generated for compressed variants of the same resource. Some examples:

# curl -D - -o /dev/null -H 'Accept-Encoding: gzip' http://localhost:81/test.txt
HTTP/1.1 200 OK
Vary: Accept-Encoding
Content-Encoding: gzip
Last-Modified: Thu, 16 Oct 2008 03:00:59 GMT
ETag: "1755605059" 
Content-Type: text/plain
Accept-Ranges: bytes
Content-Length: 60
Date: Thu, 16 Oct 2008 03:11:52 GMT
Server: lighttpd/1.4.20

# curl -D - -o /dev/null -H 'Accept-Encoding: deflate' http://localhost:81/test.txt
HTTP/1.1 200 OK
Vary: Accept-Encoding
Content-Encoding: deflate
Last-Modified: Thu, 16 Oct 2008 03:00:59 GMT
ETag: "1755605059" 
Content-Type: text/plain
Accept-Ranges: bytes
Content-Length: 42
Date: Thu, 16 Oct 2008 03:13:37 GMT
Server: lighttpd/1.4.20

# curl -D - -o /dev/null http://localhost:81/test.txt
HTTP/1.1 200 OK
Vary: Accept-Encoding
Content-Type: text/plain
Accept-Ranges: bytes
ETag: "1755605059" 
Last-Modified: Thu, 16 Oct 2008 03:00:59 GMT
Content-Length: 25600
Date: Thu, 16 Oct 2008 03:14:27 GMT
Server: lighttpd/1.4.20

The ETag values in the above examples are all identical regardless of the fact that each entity is a different variant.

This behaviour is in violation of RFC2616 #3.11:

An entity tag MUST be unique across all versions of all entities associated with a particular resource.