Apache 1.3 on woody largefile problems
Hi,
I sent this to debian-user, but haven't heard anything. I didn't know if I should submit it as a bug, or send it here first --- sorry if I'm doing it the wrong way. Please point me to the right place otherwise.
(please note I bumped to r3 and it still happens)
thanks a bunch!
adam
----begin forward----
Hi,
I have a system running Debian Woody 3.0r2 (have yet to bump to r3) with the latest security patches as of today (Nov. 1) with apache "1.3.26-0woody5" (from dpkg -l).
Short version: files >2GB don't get seen as >2GB, and it looks like largefile support doesn't "work," in both GET and HEAD requests.
I create a file in /var/tmp >2GB (2GB + 3 kbytes):
dd if=/dev/zero of=/var/tmp/tester bs=1k count=2097155
and point apache to /var/tmp as document root (httpd.conf):
ServerType standalone
ServerRoot /etc/apache
LockFile /var/log/apache/lock
PidFile /var/log/apache/pid
ScoreBoardFile /var/log/apache/scoreboard
Timeout 300
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15
MinSpareServers 5
MaxSpareServers 10
StartServers 20
MaxClients 500
MaxRequestsPerChild 200
Listen 10.38.0.1:80
LoadModule config_log_module /usr/lib/apache/1.3/mod_log_config.so
LoadModule mime_module /usr/lib/apache/1.3/mod_mime.so
LoadModule negotiation_module /usr/lib/apache/1.3/mod_negotiation.so
LoadModule status_module /usr/lib/apache/1.3/mod_status.so
LoadModule dir_module /usr/lib/apache/1.3/mod_dir.so
LoadModule alias_module /usr/lib/apache/1.3/mod_alias.so
LoadModule rewrite_module /usr/lib/apache/1.3/mod_rewrite.so
LoadModule access_module /usr/lib/apache/1.3/mod_access.so
LoadModule auth_module /usr/lib/apache/1.3/mod_auth.so
LoadModule expires_module /usr/lib/apache/1.3/mod_expires.so
LoadModule unique_id_module /usr/lib/apache/1.3/mod_unique_id.so
LoadModule setenvif_module /usr/lib/apache/1.3/mod_setenvif.so
ExtendedStatus Off
DocumentRoot /var/tmp
<Directory />
Options Indexes Includes FollowSymLinks MultiViews
AllowOverride None
Allow from all
</Directory>
... (mime settings, language settings for negotiation_module, log file settings, etc.)
/var/tmp# nc 10.38.0.1 80
HEAD /tester HTTP/1.1
Host: 10.38.0.1:80
Connection: close
HTTP/1.1 200 OK
Date: Tue, 02 Nov 2004 01:06:47 GMT
Server: Apache
Last-Modified: Tue, 02 Nov 2004 00:35:29 GMT
ETag: "4f138-80000c00-4186d651"
Accept-Ranges: bytes
Content-Length: -2147480576
Connection: close
Content-Type: text/plain; charset=iso-8859-1
/var/tmp# ls -l tester
-rw-r--r-- 1 root root 2147486720 Nov 1 16:35 tester
see the Content-Length: line? It says "-2147480576" which is:
$ bc -l
(2147486720+2147480576)/1024/1024
4096.00000000000000000000
(4GB --- 2GB * 2, so it wraps?)
A tcpdump:
17:02:42.611860 10.38.255.252.32791 > 10.38.0.1.80: P [tcp sum ok] 1:65(64) ack
1 win 49640 (DF) (ttl 64, id 44917, len 104)
0x0000 4500 0068 af75 4000 4006 76d1 0a26 fffc E..h.u@.@.v..&..
0x0010 0a26 0001 8017 0050 0205 b12d ccb6 2f7e .&.....P...-../~
0x0020 5018 c1e8 15ca 0000 4845 4144 202f 7465 P.......HEAD./te
0x0030 7374 6572 2048 5454 502f 312e 310d 0a48 ster.HTTP/1.1..H
0x0040 6f73 743a 2031 302e 3338 2e30 2e31 3a38 ost:.10.38.0.1:8
0x0050 300d 0a43 6f6e 6e65 6374 696f 6e3a 2063 0..Connection:.c
0x0060 6c6f 7365 0d0a 0d0a lose....
0x0000 4500 0133 0cc7 4000 4006 18b5 0a26 0001 E..3..@.@....&..
0x0010 0a26 fffc 0050 8017 ccb6 2f7e 0205 b16d .&...P..../~...m
0x0020 5018 16d0 4ce5 0000 4854 5450 2f31 2e31 P...L...HTTP/1.1
0x0030 2032 3030 204f 4b0d 0a44 6174 653a 2054 .200.OK..Date:.T
0x0040 7565 2c20 3032 204e 6f76 2032 3030 3420 ue,.02.Nov.2004.
0x0050 3031 3a30 323a 3432 2047 4d54 0d0a 5365 01:02:42.GMT..Se
0x0060 7276 6572 3a20 4170 6163 6865 0d0a 4c61 rver:.Apache..La
0x0070 7374 2d4d 6f64 6966 6965 643a 2054 7565 st-Modified:.Tue
0x0080 2c20 3032 204e 6f76 2032 3030 3420 3030 ,.02.Nov.2004.00
0x0090 3a33 353a 3239 2047 4d54 0d0a 4554 6167 :35:29.GMT..ETag
0x00a0 3a20 2234 6631 3338 2d38 3030 3030 6330 :."4f138-80000c0
0x00b0 302d 3431 3836 6436 3531 220d 0a41 6363 0-4186d651"..Acc
0x00c0 6570 742d 5261 6e67 6573 3a20 6279 7465 ept-Ranges:.byte
0x00d0 730d 0a43 6f6e 7465 6e74 2d4c 656e 6774 s..Content-Lengt
0x00e0 683a 202d 3231 3437 3438 3035 3736 0d0a h:.-2147480576..
0x00f0 436f 6e6e 6563 7469 6f6e 3a20 636c 6f73 Connection:.clos
0x0100 650d 0a43 6f6e 7465 6e74 2d54 7970 653a e..Content-Type:
0x0110 2074 6578 742f 706c 6169 6e3b 2063 6861 .text/plain;.cha
0x0120 7273 6574 3d69 736f 2d38 3835 392d 310d rset=iso-8859-1.
0x0130 0a0d 0a ...
And an strace:
read(5, "HEAD /tester HTTP/1.1\r\nHost: 10."..., 4096) = 64
rt_sigaction(SIGUSR1, {SIG_IGN}, {SIG_IGN}, 8) = 0
time(NULL) = 1099356262
stat64("/var/tmp/tester", {st_mode=S_IFREG|0644, st_size=2147486720, ...}) = 0
open("/var/tmp/tester", O_RDONLY|O_LARGEFILE) = 6
close(6) = 0
select(6, [5], NULL, NULL, {0, 0}) = 0 (Timeout)
write(5, "HTTP/1.1 200 OK\r\nDate: Tue, 02 N"..., 267) = 267
I see nothing in the logs regarding this error, it's clearly not an "error" per se, as it's "working" --- it just doesn't get >2GB, or I'm clearly missing something.
I am running linux-2.4.27 with debian's freeswan patches and grsec patches. i've had large file support work on other applications (ftp, etc.), as I have some 4GB+ files that were uploaded using ftp.
What am I missing?
thanks,
--
adam
----- End forwarded message -----
--
adam
Reply to: