Bug 177885 - large file support isn't working in httpd
large file support isn't working in httpd
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: httpd (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-01-16 00:49 EST by Nathan G. Grennan
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-03 04:58:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


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

  None (edit)
Description Nathan G. Grennan 2006-01-16 00:49:44 EST
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 04:17:36 EST
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 11:27:50 EST
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 11:31:06 EST
Created attachment 123243 [details]
strace log of wget
Comment 4 Nathan G. Grennan 2006-01-16 11:35:49 EST
wget and curl on a Fedora Core 4 i386 and x86_64 systems get the same results.

Comment 5 Joe Orton 2006-01-16 11:38:01 EST
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 11:47:17 EST
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 04:58:10 EST
Thanks for tracking this down.

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