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: [email protected] ReportedBy: [EMAIL PROTECTED] 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. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
