On Wed, Aug 13, 2008 at 11:50:18PM +0200, Thibaut VARENE wrote: > 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*
It is very much defined. The Alias (/usr/share) as YOU defined it completely overrides anything present in the DocumentRoot (/var/www) except for one case: a request for bare "/musicindex", but that does not occur when requesting any of the images or css. I've already done a lot of the legwork for you... >From the Apache docs for the Alias directive: "The Alias directive allows documents to be stored in the local filesystem other than under the DocumentRoot. URLs with a (%-decoded) path beginning with url-path will be mapped to local files beginning with directory-path." The edge case is also discussed here. >From the docs, for DocumentRoot: "This directive sets the directory from which httpd will serve files. _Unless matched by a directive like Alias_, the server appends the path from the requested URL to the document root to make the path to the document." (emphasis mine) The DocumentRoot folder is the default (i.e., last) in the chain of filesystem resolution. It appears that the only thing that has higher precedence than an Alias is a Rewrite (makes sense if you need to mangle the request first). >From a post to httpd-dev on Mon, 07 Jan 2002 06:06:42 GMT by Bill Rowe, w32 Apache dev: ... "mechanism for serving content. And it certainly neither breaks the existing DocumentRoot, nor the Alias directive [which will still, as always, override DocumentRoot.)" Your Alias, as shipped in musicindex.conf, will cause any requests that start with /musicindex/ to be served from /usr/share/mod_musicindex. No attempt will be made to access any other filesystem location. This was demonstrated in step 2: no image is displayed by the broswer, despite the image's presence in DocRoot/musicindex. However, it obviously saw it when it checked, because the image was broken. When Apache goes to serve the file from the external request, it does NOT stat or open anything under DocumentRoot/musicindex. (If what you say is true, that is is undefined, that would allow people to break any Aliased files by making the same file in DocRoot. It was shown that you can't get to those files.) > 2) I'm afraid that given the above, the behaviour of > ap_sub_req_lookup_uri is equally undeterminable. The way I understand the API spec, this should do all the resolution that Apache would normally go through to serve the file, short of actually serving it. So, it's not undeterminable and should have a definite resolution (i.e., it should resolve the Alias correctly.) > 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. The behavior of having overlapping directories is understood. It is definitely a bug as it stands now. Placing images in a folder that is completely ignored when serving the images should NOT break your served page. Yet it currently does. I can agree with the fact that it appears to be a bug in the call that you're using. However, if you think you are using the correct call, then it is a bug in Apache and the correct action should be to reassign this bug to apache2 and call the attention of the Debian Apache maintainers, or report this upstream to Apache and change to forwarded. If this call ends up being a known issue, the Apache team(s) will quickly get back to you, and you can fix the bug. > 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 That'd work; I've already implemented a suitable workaround for now, though. > 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" :-) It is explicitly allowed by the documentation as shipped. I am not "exploiting" a feature. Besides, resolving w3.org, fetching, waiting, is not efficient compared to a stat/open/sendfile. Even if you've got the image cached, you still have to GET each time the page loads, and the remote server has to return Not Modified... (At worst, a bunch of Debian users making unnecessary calls to their websites... I like to be a good netzien and the page loads quicker, to boot.) It may be that the images are Free enough to include directly in your package; then you could remove the access() calls, removing the bug here, but the bug still exists and you should forward the problematic call. > 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... (If by "close", you meant "reassign/forward", then you can stop reading here.) You should not close this bug until it is fixed. It is not fixed at the moment. There is sufficient proof to show that there is a bug at the moment unless you do not believe the evidence that the DocRoot/musicindex directory is being ignored during remote requests, but is not being ignored while checking for the presence of the local image. A change in the documentation is not a sufficient fix, because I could still break the module's generated page by touching DocRoot/musicindex/vcss et al. That would be another bug, so you can't get rid of it like that. :) The only way you can get rid of it cleanly without extra work is to include the images with the package (depending on their license), but the bug should remain open, because you now claim it is a problem with Apache. You should not close it now since the closed state is reserved for non-existent bugs, no matter where they start, right? This is not the case. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
