httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@apache.org
Subject cvs commit: httpd-2.0/modules/filters mod_include.c
Date Thu, 08 Mar 2001 20:03:42 GMT
rbb         01/03/08 12:03:41

  Modified:    .        CHANGES
               modules/filters mod_include.c
  Log:
  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.
  
  Revision  Changes    Path
  1.125     +6 -0      httpd-2.0/CHANGES
  
  Index: CHANGES
  ===================================================================
  RCS file: /home/cvs/httpd-2.0/CHANGES,v
  retrieving revision 1.124
  retrieving revision 1.125
  diff -u -d -b -w -u -r1.124 -r1.125
  --- CHANGES	2001/03/07 19:13:27	1.124
  +++ CHANGES	2001/03/08 20:03:30	1.125
  @@ -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]
  
  
  
  1.105     +9 -7      httpd-2.0/modules/filters/mod_include.c
  
  Index: mod_include.c
  ===================================================================
  RCS file: /home/cvs/httpd-2.0/modules/filters/mod_include.c,v
  retrieving revision 1.104
  retrieving revision 1.105
  diff -u -d -b -w -u -r1.104 -r1.105
  --- mod_include.c	2001/03/02 21:44:14	1.104
  +++ mod_include.c	2001/03/08 20:03:37	1.105
  @@ -2497,13 +2497,6 @@
                   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!
  @@ -2776,6 +2769,15 @@
        * fix this, except to put alarm support into BUFF. -djg
        */
   
  +
  +    /* 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);
   
  
  
  

Mime
View raw message