From: Ryan Bloom <rbb@apache.org>
Date: Thu, 8 Mar 2001 20:03:37 +0000 (+0000)
Subject: Always clear the C-L if we are going to try to parse the file.  It is
X-Git-Tag: 2.0.15~63
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=956be633e32763f6ae9f7ae2d1af14dfd96bebf7;p=apache

Always clear the C-L if we are going to try to parse the file.  It is
impossible for us to determine if there is going to be an SSI tag in the
file until we have actually scanned it all.  By that time, it is likely
that the first chunk of data, and the headers have been sent to the client,
and it is too late to clear the C-L.  If we are parsing the file, we have
to just assume we are going to change the content.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@88477 13f79535-47bb-0310-9956-ffa450edef68
---

diff --git a/CHANGES b/CHANGES
index 0213536d75..67bf199dff 100644
--- a/CHANGES
+++ b/CHANGES
@@ -1,5 +1,11 @@
 Changes with Apache 2.0.14
 
+  *) Mod_include should always unset the content-length if the file is
+     going to be passed through send_parsed_content.  There is no to
+     determine if the content will change before actually scanning the
+     entire content.  It is far safer to just remove the C-L as long
+     as we are scanning it.  [Ryan Bloom]
+
   *) Fix content-length computation.  We ONLY compute a content-length if
      We are not in a 1.1 request and we cannot chunk, and this is a keepalive
      or we already have all the data.  [Ryan Bloom]
diff --git a/modules/filters/mod_include.c b/modules/filters/mod_include.c
index e94815cd0b..4cdf5035a3 100644
--- a/modules/filters/mod_include.c
+++ b/modules/filters/mod_include.c
@@ -2497,13 +2497,6 @@ static void send_parsed_content(apr_bucket_brigade **bb, request_rec *r,
                 return;
             }
 
-            /* Even if I don't generate any content, I know at this point that
-             *   I will at least remove the discovered SSI tag, thereby making
-             *   the content shorter than it was. This is the safest point I can
-             *   find to unset this field.
-             */
-            apr_table_unset(f->r->headers_out, "Content-Length");
-
             /* Can't destroy the tag buckets until I'm done processing
              *  because the combined_tag might just be pointing to
              *  the contents of a single bucket!
@@ -2777,6 +2770,15 @@ static int includes_filter(ap_filter_t *f, apr_bucket_brigade *b)
      */
 
 
+    /* Always unset the content-length.  There is no way to know if
+     * the content will be modified at some point by send_parsed_content.
+     * It is very possible for us to not find any content in the first
+     * 9k of the file, but still have to modify the content of the file.
+     * If we are going to pass the file through send_parsed_content, then
+     * the content-length should just be unset.
+     */
+    apr_table_unset(f->r->headers_out, "Content-Length");
+
     send_parsed_content(&b, r, f);
 
     if (parent) {