Handling of If-Match header (RFC 2616, Section 14.24) seems to be broken. See an example session below: # Obtain ETag GET / HTTP/1.0 HTTP/1.1 200 OK Date: Tue, 16 Dec 2014 02:27:48 GMT Server: Apache/2.4.10 (Unix) Last-Modified: Mon, 11 Jun 2007 18:53:14 GMT ETag: "2d-432a5e4a73a80" Accept-Ranges: bytes Content-Length: 45 Connection: close Content-Type: text/html <html><body><h1>It works!</h1></body></html> # If-Match with ETag => OK GET / HTTP/1.0 If-Match: "2d-432a5e4a73a80" HTTP/1.1 200 OK Date: Tue, 16 Dec 2014 02:28:33 GMT Server: Apache/2.4.10 (Unix) Last-Modified: Mon, 11 Jun 2007 18:53:14 GMT ETag: "2d-432a5e4a73a80" Accept-Ranges: bytes Content-Length: 45 Connection: close Content-Type: text/html <html><body><h1>It works!</h1></body></html> # If-Match: * => WRONG, should return 200 GET / HTTP/1.0 If-Match: * HTTP/1.1 412 Precondition Failed Date: Tue, 16 Dec 2014 02:28:43 GMT Server: Apache/2.4.10 (Unix) Last-Modified: Mon, 11 Jun 2007 18:53:14 GMT ETag: "2d-432a5e4a73a80" Accept-Ranges: bytes Content-Length: 0 Connection: close Content-Type: text/html # ETag doesn't match => WRONG, should return 412 GET / HTTP/1.0 If-Match: "xyzzy" HTTP/1.1 200 OK Date: Tue, 16 Dec 2014 02:28:53 GMT Server: Apache/2.4.10 (Unix) Last-Modified: Mon, 11 Jun 2007 18:53:14 GMT ETag: "2d-432a5e4a73a80" Accept-Ranges: bytes Content-Length: 45 Connection: close Content-Type: text/html <html><body><h1>It works!</h1></body></html>
Created attachment 32297 [details] Patch
Committed a slightly different version in r1646282 to trunk. Thanks for the pointer.
Confirming that the bug is fixed in recent (r1665385) trunk (2.5 dev). I'd like to propose this to be backported to the 2.4 branch, since it's a regression and can cause loss of data if a client is relying on the functionality. (The bug appeared between the 2.4.4 and 2.4.6 releases, and exists up though 2.4.12 and the current (r1665231) 2.4.x-branch head.)
Backport to 2.4.x proposed in r1665739.
This is part of the (unreleased) 2.4.13 backport in r1674658