DO NOT REPLY [Bug 12207] New: - If-None-Match requests always return 304 with FileETag None directive

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12207>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12207

If-None-Match requests always return 304 with FileETag None directive

           Summary: If-None-Match requests always return 304 with FileETag
                    None directive
           Product: Apache httpd-2.0
           Version: 2.0.40
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Critical
          Priority: Other
         Component: Core
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: andrew@tellme.com

If Apache has the FileETag directive set to "None" and an If-None-Match header is sent in a request, Apache always sends back a 304 Not Modified response, regardless of the content of the ETag(s) sent in the If-None-Match header.

This bug is pretty high priority, because it means that if a site running Apache normally serves ETags but then stops serving them by setting FileETag None, any downstream caches which understand ETags and send If-None-Match requests will stop getting updated content.

How to reproduce:

1. Make a regular HTTP request to Apache for any static file, and note its ETag.
2. Make another HTTP request for that file, sending an If-None-Match header (for example, if the ETag from step 1 is "abcdef", send the header If-None-Match: "abcdef"). Apache should correctly return a 304 Not Modified response.
3. Make a new If-None-Match request with a bogus ETag, for example by sending If-None-Match: "xxx". Apache should correctly return a 200 OK and include an entity body.
4. Add a FileETag None directive to the Apache configuration, and restart Apache.
5. Make the same If-None-Match request as in step 2. Again, Apache should correctly return a 304 Not Modified response.
6. Make the same bogus If-None-Match request as in step 3 (or any other If-None-Match request with a bogus ETag). Apache will incorrectly return a 304 Not Modified response.

Steps 4 and 6 are enough to reproduce the bug but the other steps give a little context by showing the correct behavior.

I have reproduced this bug with Apache 2.0.40 on Solaris x86. I strongly suspect the bug to be platform independent, as it is a simple missing check in http_protocol.c for an empty ETag. Apache 1.3 has an identical bug, for which details can be found in Bug 12202.