josh wrote:Here is my shot at explaining my ( current possibly wrong ) understanding of the module.
"Apache is invoked when an HTTP request is received, the URL passes thru a chain of modules that can alter the URI which is eventually translated into an absolute path on your filesystem. Rewrite rules can only rewrite the URL if another module has not mapped it to an absolute path that leads to an existing file"
Is this what you meant earlier by a "physical path"?
That was what I was originally getting at although when I explained it this way I did say it was a guess and I also later (in a later post on in this thread) did state that after reading the docs that I was incorrect in my guess and you can rewrite physical paths.
I suppose a slightly more correct explanation would be....
"Apache is invoked when an HTTP request is received, the URL passes thru a chain of filters/modules that can alter the URI which is eventually translated into an absolute path on your filesystem. Each filter/module takes the URI, performs any translations/rewrites on it before passing the newly translated URI on to the next filter/module. The order in which filter/modules are applied is defined by the points at which the filter/module hooks into the API. When two or more filters/modules hook into the same API phase the order they are applied is based on the status of the filter/module 'core', 'base' 'extension' etc.. (although I could wrong on this last part)"
The issue you are expericing is that multiviews is translating the URL before mod_rewrite gets to see it and by the time the URL is handed to mod_rewrite the URL has changed to the extent that your rewrite pattern doesn't match it so it just flows straight through the mod_rewrite engine unchanged.
Ultimately applying multiple translators to the URL is a bad idea and unexpected results may occur however, I can see (due to config options) how/why/where this situation can arise. Ideally in your specific case you should disable multiviews however, if this is part of a distributed app where the end user doesn't have permission or means to change Apache config options then you should use rewrite rules similar to the two examples I've given.
josh wrote:In your example rewriteRules you are rewriting a "physical path" tho it looks like? Now that I see your example it is IMMEDIATELY clear where there was a lapse in my understanding, IMO the documentation should be just as black and white, even now that I understand what is happening I can't find the dots to connect in the manual, I still don't see how any of this could be implied ( You seem to have read thru its source or something, you seem very knowledgeable of info that is outside the scope of the docs )
For us normal people tho it could be spelt out better, maybe if we identify specifically where the gaps are they could fix them ( or get myself banned hah )
To be honest, I suspect most if not all the information is already present in the docs however, it will be spread out. For example, the docs for mod_rewrite just concern themselves with aspects of mod_rewrite. It's not the job of the mod_rewrite section to go into fine detail about each and every API phase of URL handling, you will probably find that in the core API docs.
While I like to consider myself as being slightly more knowledgeable than the average Apache user I am by no means any form of Apache guru, I have no secret access to undisclosed documentation nor do I posses a bat phone to the core developers. I've been working with Apache on and off for some 10+ years, I guess my knowledge is just an accumulation of my experiences over those years. I also say that possibly just through using the software I've become more familiar with the terminology that is used within the docs. It's just like most software apps, the more you use it the more you understand it, the comfortable you become with it. I have on occasions reverted to digging through the source to get answers but it's not very often as I find that most questions I've had over the years are answered in the official docs.
josh wrote:For my own sanity is there anything else I should look out for that would cause me similar problems in the future?
Probably. But due to the size, power and flexibility of Apache almost all configurations are different and every user has individual needs, it would be impossible to guess at what you may or may not want to do with Apache in the future.