Bug 177885 - large file support isn't working in httpd
Summary: large file support isn't working in httpd
Alias: None
Product: Fedora
Classification: Fedora
Component: httpd   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Joe Orton
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2006-01-16 05:49 UTC by Nathan G. Grennan
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-03 09:58:10 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
strace log of wget (27.65 KB, text/plain)
2006-01-16 16:31 UTC, Nathan G. Grennan
no flags Details

Description Nathan G. Grennan 2006-01-16 05:49:44 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8) Gecko/20060103 Fedora/1.5-4 Firefox/1.5

Description of problem:
  One of the defining features of httpd 2.2 is supposed to be large file support for 32bit systems. Yet it doesn't seem to work. I tried using wget-1.10.2-3.1 and firefox-1.5-4 to download a 3.1gb dvd iso file via httpd-2.2.0-4. The file does show up in a directory index, but the size comes out zero.

This is on a x86_64 system with a dual core processor.

[root@proton ~]# wget http://localhost/FC5-test2-x86_64-DVD.iso
--00:42:34--  http://localhost/FC5-test2-x86_64-DVD.iso
           => `FC5-test2-x86_64-DVD.iso'
Resolving localhost...
Connecting to localhost||:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3,235,653,632 (3.0G) [application/octet-stream]

 0% [                                                         ] 0             --.--K/s

00:42:34 (0.00 B/s) - Connection closed at byte 0. Retrying.

--00:42:35--  http://localhost/FC5-test2-x86_64-DVD.iso
  (try: 2) => `FC5-test2-x86_64-DVD.iso'
Connecting to localhost||:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3,235,653,632 (3.0G) [application/octet-stream]
FC5-test2-x86_64-DVD.iso has sprung into existence.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. service yum install httpd wget
2. service httpd start
3. wget url

Actual Results:  00:42:34 (0.00 B/s) - Connection closed at byte 0. Retrying.

Expected Results:  The file to download properly.

Additional info:

Comment 1 Joe Orton 2006-01-16 09:17:36 UTC
Works fine for me on a variety of systems.  What platform is the system running
httpd, x86 (you only mention x86_64)?

Tried curl?  Can you run:

strace -o /tmp/httpd.t wget ...

and attach the httpd.t.  Anything in the server error_log?

Comment 2 Nathan G. Grennan 2006-01-16 16:27:50 UTC
I am testing this on a Fedora Core 5 Test 2 x86_64 system and connecting to

I tried curl and got the error below.

[root@proton ~]# curl http://localhost/test/FC5-test2-x86_64-DVD.iso
curl: (18) transfer closed with 3235653632 bytes remaining to read

I tried wget again with strace. I will attach the log. I assumed wget would work
in that one of the features of a wget version a while back was that it finally
supported large files.

Comment 3 Nathan G. Grennan 2006-01-16 16:31:06 UTC
Created attachment 123243 [details]
strace log of wget

Comment 4 Nathan G. Grennan 2006-01-16 16:35:49 UTC
wget and curl on a Fedora Core 4 i386 and x86_64 systems get the same results.

Comment 5 Joe Orton 2006-01-16 16:38:01 UTC
It looks like the server is crashing.  Please look at /var/log/httpd/error_log;
if a segmentation fault is listed, please run as root:

echo CoreDumpDirectory /tmp > /etc/httpd/conf.d/core.conf
service httpd restart
yum install httpd-debuginfo apr-debuginfo apr-util-debuginfo
# <... trigger the crash... >
gdb /usr/sbin/httpd /tmp/core.*
(gdb) backtrace full

and attach the output of gdb.

Comment 6 Nathan G. Grennan 2006-01-16 16:47:17 UTC
I figured out the problem. Another round of fun in SELinux world. I had disabled
SELinux via firstboot to avoid such problems, but I hadn't rebooted. So I guess
it automatically boots with SELinux the first time, and then respects your decesion.

I simply rebooted and tried again, and now it works. Too bad the anaconda
developers probably can't be talked into putting the selinux and firewall
control back in the anaconda. I am sure more bugs like this are going to crop up.

Comment 7 Joe Orton 2006-02-03 09:58:10 UTC
Thanks for tracking this down.

Note You need to log in before you can comment on or make changes to this bug.