Bug 177885

Summary: large file support isn't working in httpd
Product: [Fedora] Fedora Reporter: Nathan G. Grennan <redhat-bugzilla>
Component: httpdAssignee: Joe Orton <jorton>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-02-03 09:58:10 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
strace log of wget none

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... 127.0.0.1
Connecting to localhost|127.0.0.1|: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|127.0.0.1|: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.
Retrying.




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

How reproducible:
Always

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
localhost.

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.