httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 19355] New: - mod_include allows invalid ETag headers
Date Sun, 27 Apr 2003 00:49:19 GMT
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=19355>.
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=19355

mod_include allows invalid ETag headers

           Summary: mod_include allows invalid ETag headers
           Product: Apache httpd-2.0
           Version: HEAD
          Platform: All
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: Minor
          Priority: Other
         Component: mod_include
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: geoff@apache.org


this bug was first reported to dev@httpd.apache.org

http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=105120818606501&w=2

mod_include has an ETag bug when activated using XBitHack Full.  in general, default_handler
generates an ETag header for documents it serves.  because embedded SSI tags have the ability
to alter the content of a document, mod_include strips outgoing ETag headers from responses
it enters.  however, the method by which mod_include strips these headers is insufficient
in cases where default_handler decides a 304 is warranted.

consider the following series of requests when XBitHack is activated for a document in DocumentRoot
(uninteresting headers snipped for brevity)

GET /ssi.html HTTP/1.1

HTTP/1.1 200 OK
Last-Modified: Thu, 24 Apr 2003 16:50:50 GMT

-------------

GET /ssi.html HTTP/1.1
If-Modified-Since: Thu, 24 Apr 2003 16:50:50 GMT

HTTP/1.1 304 Not Modified
Last-Modified: Thu, 24 Apr 2003 16:50:50 GMT
ETag: "35157-5f-4861ce80"


while mod_include removes the ETag header from the first request, default_handler generates
an (almost always invalid) ETag on the subsequent 304.

the below patch seems to be a better way for mod_include to handle ETag generation (or, rather,
supression).


Index: modules/filters/mod_include.c
===================================================================
RCS file: /home/cvspublic/httpd-2.0/modules/filters/mod_include.c,v
retrieving revision 1.233
diff -u -r1.233 mod_include.c
--- modules/filters/mod_include.c	3 Feb 2003 17:53:01 -0000	1.233
+++ modules/filters/mod_include.c	24 Apr 2003 17:46:13 -0000
@@ -3338,6 +3338,12 @@
         f->r->no_local_copy = 1;
     }
     
+    /* Don't allow ETag headers to be generated - see RFC2616 - 13.3.4.
+     * We don't know if we are going to be including a file or executing
+     * a program - in either case a strong ETag header will likely be invalid.
+     */
+    apr_table_setn(f->r->notes, "no-etag", 1);
+
     return OK;
 }
 
@@ -3407,14 +3413,13 @@
      */
     apr_table_unset(f->r->headers_out, "Content-Length");
 
-    /* Always unset the ETag/Last-Modified fields - see RFC2616 - 13.3.4.
+    /* Always unset the Last-Modified fields - see RFC2616 - 13.3.4.
      * We don't know if we are going to be including a file or executing
      * a program which may change the Last-Modified header or make the 
      * content completely dynamic.  Therefore, we can't support these
      * headers.
      * Exception: XBitHack full means we *should* set the Last-Modified field.
      */
-    apr_table_unset(f->r->headers_out, "ETag");
 
     /* Assure the platform supports Group protections */
     if ((*conf->xbithack == xbithack_full)

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message