On Tue, Aug 12, 2008 at 08:26:09PM +0200, Thibaut VARENE wrote:
> The code in the module that deals with (X)HTML generation is very much
> built around a few standard procedures, and I'd expect many other
> thing to break if the symptom you describe (the module looking for
> files at the wrong place) was actually happening in a more general
> way. (i.e. stylesheet and icons should also be broken).
>
> Could you send your complete apache configuration ?
There's no need for that. See the simpler repro steps below. A
little more digging into the problem has produced a (hopefully) more
coherent explaination. Sorry, it's my first Debian bugreport :)
I was able to repro the problem using only the 000-default Apache
site, with
Alias /mp3/ "/data/home/sword/music/"
<Directory "/data/home/sword/music/">
Options Indexes MultiViews FollowSymlinks
AllowOverride Indexes
# Can be overriden in .htaccess
MusicIndex On +Stream +Download +Search -Rss +Tarball
</Directory>
added in there, as per your docs.
musicindex.conf is
Alias /musicindex/ "/usr/share/mod_musicindex/"
<Directory "/usr/share/mod_musicindex/">
Order allow,deny
Allow from all
</Directory>
as shipped.
Steps to repro (doesn't involve changing DocumentRoot):
1) Install apache + mod_musicindex. Move vcss et al away from
/usr/share/mod_musicindex elsewhere. Clean up anything in
/var/www/musicindex/. This should be a clean state as far as shipped
musicindex is concerned. Images are remote.
2) Leaving DocumentRoot alone (/var/www by default), mkdir
DocumentRoot/musicindex (/var/www/musicindex), place ONLY external
images in /var/www/musicindex. Result: broken vcss/loveRss/valid-x11
images (!), local links. Other images work. wget
http://localhost/musicindex/vcss is 404 Not Found.
3) The fix: copy (not move) vcss, loveRss et al to
/usr/share/mod_musicindex. Result: local images, not broken.
Expected behavior would be to put the images in the Aliased directory
and use those, per the documentation. Certainly step 2 should not
produce broken images.
(Cleaning up is essential to expose the bug. You need the two copies
to make the footer images local and not broken. Placing them soley in
the Aliased directory continues to make the images remote. Just one
set won't work. Permissions on all images are 644 no matter which
location.)
Explaination of 2:
Apache attempts to serve loveRss.gif from the Aliased
/usr/share/mod_musicindex but is caught in the act. After placing
loveRss.gif in /var/www/musicindex/ and refreshing the browser,
error.log has:
File does not exist: /usr/share/mod_musicindex/loveRss.gif
Strace of step 2 with the default-000 config:
access("/var/www/musicindex/loveRss.gif", R_OK) = 0
and the generated HTML response is sent. Later on,
read(9, "GET /musicindex/loveRss.gif HTTP"..., 8000) = 473
is followed shortly by stat64 and
lstat64("/usr/share/mod_musicindex/loveRss.gif", 0xb6d9614c) = -1 ENOENT (No
such file or directory)
and a 404 response to the GET for that file.
In contrast, we see, for directory.png and others, after the generated
HTML is sent:
read(9, "GET /musicindex/directory.png HT"..., 8000) = 450
followed by
stat64("/usr/share/mod_musicindex/directory.png", {st_mode=S_IFREG|0644,
st_size=2669, ...}) = 0
and
writev(9, [{"HTTP/1.1 200 OK\r\nDate: Wed, 13 A"..., 312}], 1) = 312
No stat is performed for any of the files used in musicindex.css
during HTML generation.
Since /musicindex is an Alias, vcss et al won't be served from
/var/www/musicindex: any request for /musicindex has the Alias
override DocRoot/musicindex, explaining why the wget failed.
You were not able to see the bug due to the following (a guess):
When you copied all the images + vcss, loveRss.gif, valid-x11 from
/usr/share/mod_musicindex, to /var/www/musicindex, it worked for you,
kind of: you did not disable the Alias in musicindex.conf, AFAICT, so
the files in /usr/share/mod_musicindex were still being used for
everything. It looks like you were already on step 3.
(You can keep things straight by, say, mogrify -resize 200%
/var/www/musicindex/vcss, so if you saw a big vcss image, you know
that's the DocumentRoot one.)
(I have limited C experience, so take this loosely.)
I guess this would all translate, less verbosely, to:
ap_sub_req_lookup_uri in send_foot in html.c is not performing the
request you were expecting. You wanted to check the presence of the
files in the Aliased directory but it appears that subreq->filename is
DocumentRoot/musicindex/ since that is what is access()ed. This
causes the remote links to be generated when the images are in the
Aliased directory only.
This does not affect the other images because their HTML is generated
by musicindex.css as an absolute URL "/musicindex/fetch.png" and it is
properly retrieved by the browser and Apache through the Alias.
I hope that's enough information to clarify the problem. Again,
thanks for the package.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
