I have kept my MP3 files available on a password-protected site using =
Apache
1.3.x for a while now. I recently upgraded to Apache 2.0.x and I've come
across a problem that has me stumped.
I'm now running Apache 2.0.47 on Linux (Gentoo 2.4.20 kernel). I have my =
MP3
files on a Win 2k smbfs share that I mount read-only at /mnt/mp3. In
/home/httpd/htdocs I have a symbolic link "music" to the mounted share.
I have also tried replacing the symbolic link with a normal directory =
and an
Alias as follows:
Alias "/music" "/mnt/mp3"
<Directory "/mnt/mp3">
Options Indexes
<IfModule mod_access.c>
Order allow,deny
Allow from all
</IfModule>
</Directory>
The indexes display just fine, showing all the files and the correct
attributes (size, etc.). But . . .=20
Using either configuration, when I try to download an MP3 from that link =
I
get a zero byte file. Here's an example of a wget. This used to work =
fine
with Apache 1.3.x
PROMPT $ wget
http://www.mydomain.com/music/goodmusic.mp3
--00:39:44--
http://www.mydomain.com/music/goodmusic.mp3
=3D> `goodmusic.mp3'
Resolving
www.mydomain.com... done.
Connecting to
www.mydomain.com[xxx.xxx.xxx.xxx]:80... connected.
http request sent, awaiting response... 200 OK
Length: 3,264,370 [audio/mpeg]
0% [ ] 0 --.--K/s ETA --:--
00:39:44 (0.00 B/s) - Connection closed at byte 0. Retrying.
Note that it gets an HTTP response code of 200 and the correct size for =
the
file, but nothing is returned past zero bytes. There are no entries in =
the
error_log and nothing but the succesful GET record in the access_log.
If I make another symbolic link (or Alias) in the same directory to an =
MP3
on the local file system instead, it downloads correctly.
I can play the file with local MP3 players via the symbolic link to the
smbfs
mount using the paths /home/httpd/htdocs/music/goodmusic.mp3 or
/mnt/mp3/goodmusic.mp3, but as indicated above, not via the URL.
What could be causing the bad file download? Do any default related to =
this
change between Apache 1.3.x and 2.0.x? I did start with all new conf =
files
as part of the upgrade.
Thanks for taking a look.
--
Rob Rosenfeld
rosenfeld.DeleteThis@alum.mit.edu