On Wed, Aug 13, 2008 at 8:03 AM, sword <[EMAIL PROTECTED]> wrote: > 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.
Thanks indeed for the lengthy explanation, it made things very clear. A few comments: 1) I believe it's likely (would probably have to check apache documentation) that apache's behaviour when an Alias conflicts with a filesystem directory (which exactly is what you were having with Alias /musicindex pointing to /usr/share/mod_musicindex *AND* having a /var/www/musicindex directory) is at best *undefined* 2) I'm afraid that given the above, the behaviour of ap_sub_req_lookup_uri is equally undeterminable. 3) in any case, I'm quite convinced that the module's code is correct, so it's either "not a bug" or "a bug in apache implementation", provided that 1) isn't documented or is documented to have a different behaviour than the one you experienced. Given what you're doing, I would simply not put the Alias directive in the configuration, link all files from /usr/share/mod_musicindex/* to /var/www/musicindex and then add your own files to /var/www/musicindex. At some point I'll try to make it simpler for the user to mix both files provided by the package and their own files (either by making the files configuration files, but that doesn't really look right; or maybe by allowing for the use of two separate directories to search for files, though that will add a certain overhead to both the code and the module efficiency). It's a tradeoff between making the module efficient and making it "customisable". The feature you're exploiting (allowing for local images) is already bending a lot what a "normal user" would do, which is why I'm not really worried about it requiring "some skills" :-) Anyway, at best I could probably add a comment in the README file, but unless there's evidence that this is actually a bug in the module, I'm considering closing this bug... Thanks again for the feedback -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
