Bug 7966 - Wrong Content-Length when SSI used as DirectoryIndex
Summary: Wrong Content-Length when SSI used as DirectoryIndex
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: All (show other bugs)
Version: 2.0.35
Hardware: All All
: P3 normal with 15 votes (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL: http://www.nanvaent.org:81/
: 8141 (view as bug list)
Depends on:
Reported: 2002-04-11 15:08 UTC by Olav Kolbu
Modified: 2004-11-16 19:05 UTC (History)
2 users (show)


Note You need to log in before you can comment on or make changes to this bug.
Description Olav Kolbu 2002-04-11 15:08:18 UTC
In some cases, the Content-Length used remains the length of the file on disk, even though the 
content of the file is changed by SSIs before transfer to client. This happens only when the file in 
question is used as a DirectoryIndex, i.e. http://www.nanvaent.org:81/. If explicitly gotten, i.e. 
http://www.nanvaent.org:81/oktest.shtml, it transfers fine (presumably because the server does not 
include a Content-Length: header in that case). 
The weird part is that _sometimes_ it actually works... 
In httpd.conf: 
DirectoryIndex oktest.shtml 
AddType text/html .shtml 
AddOutputFilter INCLUDES .shtml 
File /cgi-bin/oktest.cgi 
--- cut here --- 
echo Content-Type: text/html 
echo TeSt 
--- cut here --- 
File /oktest.shtml   (Note, 54 bytes long) 
--- cut here --- 
<!--#exec cgi="/cgi-bin/oktest.cgi"--> 
--- cut here --- 
Some tests with wget, the first one explicitly asking for the file: 
strider tmp # wget -O - -S http://www.nanvaent.org:81/oktest.shtml 
--16:57:45--  http://www.nanvaent.org:81/oktest.shtml 
           => `-' 
Resolving www.nanvaent.org... done. 
Connecting to www.nanvaent.org[]:81... connected. 
HTTP request sent, awaiting response... 
 1 HTTP/1.1 200 OK 
 2 Date: Thu, 11 Apr 2002 14:57:45 GMT 
 3 Server: Apache/2.0.35 (Unix) PHP/4.3.0-dev mod_ssl/2.0.35 OpenSSL/0.9.6a 
 4 Accept-Ranges: bytes 
 5 Connection: close 
 6 Content-Type: text/html; charset=ISO-8859-1 
    [<=>                                  ] 0             --.--K/s             <html> 
    [ <=>                                 ] 21            20.51K/s 
16:57:45 (20.51 KB/s) - `-' saved [21] 
Second test, just asking for the directory: 
strider tmp # wget -O - -S http://www.nanvaent.org:81/ 
--16:59:42--  http://www.nanvaent.org:81/ 
           => `-' 
Resolving www.nanvaent.org... done. 
Connecting to www.nanvaent.org[]:81... connected. 
HTTP request sent, awaiting response... 
 1 HTTP/1.1 200 OK 
 2 Date: Thu, 11 Apr 2002 14:59:42 GMT 
 3 Server: Apache/2.0.35 (Unix) PHP/4.3.0-dev mod_ssl/2.0.35 OpenSSL/0.9.6a 
 4 Last-Modified: Thu, 11 Apr 2002 14:40:25 GMT 
 5 ETag: "364ce-36-65f60840" 
 6 Accept-Ranges: bytes 
 7 Content-Length: 54 
 8 Keep-Alive: timeout=15, max=200 
 9 Connection: Keep-Alive 
10 Content-Type: text/html; charset=ISO-8859-1 
 0% [                                     ] 0             --.--K/s    ETA --:--<html> 
38% [=============>                       ] 21            20.51K/s    ETA 00:00 
16:59:57 (20.51 KB/s) - Connection closed at byte 21. Retrying. 
etc etc 
Note the Content-Length header.
Comment 1 David Waring 2002-04-11 16:42:01 UTC
I'm experiencing problems with proxies that is probably related to this bug. The
proxy cache is cutting the reply short if / is requested, but I get the full
reply if /index.shtml is used.
Comment 2 Christian Lemke 2002-04-12 00:31:20 UTC
The same bug is under Windows 2000.
Comment 3 Justin Erenkrantz 2002-04-12 01:54:54 UTC
This is seen on a bunch of different OSes, so change it to be All platforms and
All OSes.

An email has been sent to dev@httpd.apache.org asking for people to look at
this. There were lots of changes right before 2.0.35 regarding this code, so I
think something may have snuck in.

If the filters were ordered right, the C-L should be correct, so this isn't
obvious as to where the problem is and I'll let the people who worked on it
pre-2.0.35 look at this since they were the last ones in the code.
Comment 4 Bill Stoddard 2002-04-16 19:51:41 UTC
I cannot recreate this problem on Windows (haven't tried elsewhere).  Can 
someone send me an httpd.conf (as simple as possible) that I can use to 
Comment 5 Ian Holsman 2002-04-17 03:35:17 UTC
 I can recreate this on 35/solaris 2.6 FWIW content-length and etags shouldn't be shown on a SSI page. mod_include ~line 3367    apr_table_unset(f->r->headers_out, "Content-Length");      /* Always unset the ETag/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)         && (r->finfo.valid & APR_FINFO_GPROT)         && (r->finfo.protection & APR_GEXECUTE)) {         ap_update_mtime(r, r->finfo.mtime);         ap_set_last_modified(r);     }     else {         apr_table_unset(f->r->headers_out, "Last-Modified");     }  I'm thinking AutoIndex is the culprit 
Comment 6 Ian Holsman 2002-04-17 03:40:58 UTC
sorry about that Konqueror ate my line feeds.
I just cut & pasted some some mod-include code from ~3767 showing it unsetting
the Etag & Content-length fields
Comment 7 javier wilson 2002-04-19 01:28:28 UTC
I have exactly the same problem. I am using linux redhat.
We use "exec cgi" a lot and have this problem (incomplete 
content is returned as a result), right now we are trying 
to work-around it specifying "index.html" at the end
of our requests.
Comment 8 Justin Erenkrantz 2002-04-28 06:47:31 UTC
This problem has been resolved in modules/http/http_request.c revision 1.141.
(Gnarly to reproduce!)

This should be included in the forthcoming 2.0.36 or you can try out the latest
CVS snapshots.

Thanks for using Apache!
Comment 9 Justin Erenkrantz 2002-04-30 18:21:20 UTC
*** Bug 8141 has been marked as a duplicate of this bug. ***