I request /phpinfo/ and I get served /phpinfo.php
Moderator: General Moderators
Re: I request /phpinfo/ and I get served /phpinfo.php
OK, so I went an read the documentation on mod_rewrite and it turns out that my guess that you can't rewrite physical paths is incorrect. You have to refer to the detailed mod_rewrite documentation documentation to work out why your rewrite rule is failing in particular the section on how mod_rewrite is hooked into the API.
Basically (if I'm understanding the documentation correctly), the requested URL is translated by multiviews and acceptpathinfo prior mod_rewrite's first hook in. So the first time mod_rewrite gets a sniff of the URL it has already been translated. So, when you request '/skin/somelayout', multiviews translates 'skin' to skin.php and together with acceptpathinfo the URL that mod_rewrite sees would be '/skin.php/somelayout' which doesn't match your rewrite pattern so it just floats straight through the rewrite engine.
Basically (if I'm understanding the documentation correctly), the requested URL is translated by multiviews and acceptpathinfo prior mod_rewrite's first hook in. So the first time mod_rewrite gets a sniff of the URL it has already been translated. So, when you request '/skin/somelayout', multiviews translates 'skin' to skin.php and together with acceptpathinfo the URL that mod_rewrite sees would be '/skin.php/somelayout' which doesn't match your rewrite pattern so it just floats straight through the rewrite engine.
Re: I request /phpinfo/ and I get served /phpinfo.php
Hmm I dont see specifically where it explains that but I am aware that is what is happening, if they're not going to "fix" IMO they should at least explain it more clearly
To quote the manual
This is the part that in my opinion, contains an omission, based on what we've established a factual statement would bring to my attention that Apache actually does not start processing my rewrite directives until _after_ the URL -to- filename phase ( or whatever its called, for lack of explanation on their terminology and ignorance on my part ). I understand if I read 100% of the docs and source code and knew more about their architecture I would likely have not an issue in the first place, but my issue I guess was that I've been using these features for years and read those docs several times a year on average, and never once would I have guessed it implied this behavior.
The multiviews is coarse grained, it can affect an unbounded # of URIs, rewrites are more specific containing only wildcards the user specifies and usually coarse grained to a certain path, it would just make sense to override the former with the latter, the reverse is currently not possible. On the contrary a user with a dead rewrite can simply fix his rewrite rules, arguably I could just disable multiviews ( which I did ) but the point is I guess is if the modules are not interoperable it should be at least be implied in the manual.
The apache team has the right to do what they want, I just feel like as soon as I mis spoke on one small fact they immediately discredited me and ignored my follow comments, support teams mis understand bug reports _constantly_ sometimes it can take hours or days to read thru their source code to try to help them and they spend 2 seconds and are sure you are crazy and shut you down ( ex. http://framework.zend.com/issues/browse/ZF-6480 ). In this example they put the bug at high priority for a half year, they do 2 major releases and then decide to mis-read the issue. I think in this case tho Matthew would re-open if he would read ( or when he reads ) my test cases. From his comments it doesn't seem like he bothered to, which I even offered to spend my own time fixing the bug for them, all they had to do was send me SVN details and itd be fixed in an hour complete with regression tests
.
To quote the manual
http://httpd.apache.org/docs/2.2/rewrit ... _tech.htmlSo, after a request comes in and Apache has determined the corresponding server (or virtual server) the rewriting engine starts processing of all mod_rewrite directives from the per-server configuration in the URL-to-filename phase.
This is the part that in my opinion, contains an omission, based on what we've established a factual statement would bring to my attention that Apache actually does not start processing my rewrite directives until _after_ the URL -to- filename phase ( or whatever its called, for lack of explanation on their terminology and ignorance on my part ). I understand if I read 100% of the docs and source code and knew more about their architecture I would likely have not an issue in the first place, but my issue I guess was that I've been using these features for years and read those docs several times a year on average, and never once would I have guessed it implied this behavior.
The multiviews is coarse grained, it can affect an unbounded # of URIs, rewrites are more specific containing only wildcards the user specifies and usually coarse grained to a certain path, it would just make sense to override the former with the latter, the reverse is currently not possible. On the contrary a user with a dead rewrite can simply fix his rewrite rules, arguably I could just disable multiviews ( which I did ) but the point is I guess is if the modules are not interoperable it should be at least be implied in the manual.
The apache team has the right to do what they want, I just feel like as soon as I mis spoke on one small fact they immediately discredited me and ignored my follow comments, support teams mis understand bug reports _constantly_ sometimes it can take hours or days to read thru their source code to try to help them and they spend 2 seconds and are sure you are crazy and shut you down ( ex. http://framework.zend.com/issues/browse/ZF-6480 ). In this example they put the bug at high priority for a half year, they do 2 major releases and then decide to mis-read the issue. I think in this case tho Matthew would re-open if he would read ( or when he reads ) my test cases. From his comments it doesn't seem like he bothered to, which I even offered to spend my own time fixing the bug for them, all they had to do was send me SVN details and itd be fixed in an hour complete with regression tests
Re: I request /phpinfo/ and I get served /phpinfo.php
It's in the paragraph just above from where your quote is taken that details it...josh wrote:Hmm I dont see specifically where it explains that but I am aware that is what is happening, if they're not going to "fix" IMO they should at least explain it more clearly
To quote the manualhttp://httpd.apache.org/docs/2.2/rewrit ... _tech.htmlSo, after a request comes in and Apache has determined the corresponding server (or virtual server) the rewriting engine starts processing of all mod_rewrite directives from the per-server configuration in the URL-to-filename phase.
This is the part that in my opinion, contains an omission, based on what we've established a factual statement would bring to my attention that Apache actually does not start processing my rewrite directives until _after_ the URL -to- filename phase ( or whatever its called, for lack of explanation on their terminology and ignorance on my part ). I understand if I read 100% of the docs and source code and knew more about their architecture I would likely have not an issue in the first place, but my issue I guess was that I've been using these features for years and read those docs several times a year on average, and never once would I have guessed it implied this behavior.
... it doesn't explicitly detail your situation but the information is there.Apache Docs wrote:First you have to understand that when Apache processes a HTTP request it does this in phases. A hook for each of these phases is provided by the Apache API. Mod_rewrite uses two of these hooks: the URL-to-filename translation hook which is used after the HTTP request has been read but before any authorization starts and the Fixup hook which is triggered after the authorization phases and after the per-directory config files (.htaccess) have been read, but before the content handler is activated.
The modules are not mutually exclusive, you just have to understand what each one does and how it may effect information passed to the other.josh wrote:The multiviews is coarse grained, it can affect an unbounded # of URIs, rewrites are more specific containing only wildcards the user specifies and usually coarse grained to a certain path, it would just make sense to override the former with the latter, the reverse is currently not possible. On the contrary a user with a dead rewrite can simply fix his rewrite rules, arguably I could just disable multiviews ( which I did ) but the point is I guess is if the modules are not interoperable it should be at least be implied in the manual.
The solution to your problem is to either have two explicit rewrite rules...
Code: Select all
RewriteRule ^skin/(.*)$ /skin.php?file=$1 [L]
RewriteRule ^skin.php/(.*)$ /skin.php?file=$1 [L]
Code: Select all
RewriteRule ^skin/(.*)$ /skin.php/$1
RewriteRule ^skin.php/(.*)$ /skin.php?file=$1 [L]
One more small point of interest. From what I can gather, the additional pathinfo is always present regardless of the acceptpathinfo setting, the value of acceptpathinfo is merely stored as an option flag.
When you set acceptpathinfo to 'off' the additional pathinfo is not stripped from the URL, it's the job of the various filters and handlers to check the option flag to determine what (if anything) should be done with the additional pathinfo.
Re: I request /phpinfo/ and I get served /phpinfo.php
Nice, see that is an example that IMO would make this page ( http://httpd.apache.org/docs/2.2/rewrit ... _tech.html ) LESS verbose not more.
and in that paragraph I see
For my own sanity is there anything else I should look out for that would cause me similar problems in the future?
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"?
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 )
and in that paragraph I see
I don't see how that tells me where the rewrite rules actually play into that, to me this paragraph says "there is some undocumented hook method you can place your rewrite rules in to make them run first", in my opinion the author did not convey his intent, at least to me.. I still have no idea what any of this is trying to sayFirst you have to understand that when Apache processes a HTTP request it does this in phases. A hook for each of these phases is provided by the Apache API. Mod_rewrite uses two of these hooks: the URL-to-filename translation hook which is used after the HTTP request has been read but before any authorization starts and the Fixup hook which is triggered after the authorization phases and after the per-directory config files (.htaccess) have been read, but before the content handler is activated.
The documentation is basically no use to a layman. Maybe some people are able to extract hidden and or implied meaning from these paragraphs but the intent of documentation is to spell it out I thought.In both situations mod_rewrite rewrites URLs either to new URLs or to filenames, although there is no obvious distinction between them.
For my own sanity is there anything else I should look out for that would cause me similar problems in the future?
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"?
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 )
Re: I request /phpinfo/ and I get served /phpinfo.php
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.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"?
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.
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.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 )
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.
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.josh wrote:For my own sanity is there anything else I should look out for that would cause me similar problems in the future?
Re: I request /phpinfo/ and I get served /phpinfo.php
When you say the information would be scattered thru the core docs, do you mean this? http://httpd.apache.org/docs/2.2/mod/
I clicked on core but I don't see anything explaining phases, and how they work
Now when you say hooks into the API, does that mean the order I include the .so file in? Or I would have to just know about each module and its "phase", and somehow know what all the "phases" are and in what order they go in?
It looks like this is the root problem here, they assume we know all about phases. Instead of them acting like I wanted them to enumerate every possible interaction if they had heard me out maybe we would have discovered "phases" are not documented ( unless its buried, in which case my suggestion to re-organize the info would still apply. )
Skimming the docs I see there startup phases, cleanup phases, authentication phases. It is not clear what phases there are or in what order they go in, is the cleanup phase cleaning up the startup phase, does authentication come after startup or before? etc etc... One way for them to improve the docs would be to add a section about phases. Another would just be to put warnings at strategic places, for instance something on the rewrite docs saying to watch out for multiviews! These are 2 simple serious suggestions, are they not worthwhile if it saves them false bug reports?
I clicked on core but I don't see anything explaining phases, and how they work
See, now that isn't too verbose and makes a lot more sense then what they have up there. I knew within the rewrite module things worked like a filter, I had no idea there existed other modules that performed operations on URIs like that, if they had a few sentences on the architecture itself instead of just listing configuration directives, it would do leaps and bounds for their usability reputation."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)"
Now when you say hooks into the API, does that mean the order I include the .so file in? Or I would have to just know about each module and its "phase", and somehow know what all the "phases" are and in what order they go in?
It looks like this is the root problem here, they assume we know all about phases. Instead of them acting like I wanted them to enumerate every possible interaction if they had heard me out maybe we would have discovered "phases" are not documented ( unless its buried, in which case my suggestion to re-organize the info would still apply. )
Skimming the docs I see there startup phases, cleanup phases, authentication phases. It is not clear what phases there are or in what order they go in, is the cleanup phase cleaning up the startup phase, does authentication come after startup or before? etc etc... One way for them to improve the docs would be to add a section about phases. Another would just be to put warnings at strategic places, for instance something on the rewrite docs saying to watch out for multiviews! These are 2 simple serious suggestions, are they not worthwhile if it saves them false bug reports?
Re: I request /phpinfo/ and I get served /phpinfo.php
I was referring to the API documentation not the standard user documentation. However, be warned, the API documentation is currently in a state of flux, much of it still references the older 1.3 code base and some of it is so outdated it's been removed (from what I can tell) so at present I wouldn't assume that anything you take from the API documentation is 100% factual to current software.
The Apache software is built around a fairly typical plugin architecture, I'm not going to go into huge detail about the finer details of this as I would assume that there are numerous articles and discussion on this type of implementation dotted around the web and can probably explain it better than I can.
Although I will just touch on your question regarding loading external modules. Each module is loaded in the order it appears in the 'LoadModule' section of the config file. When the module is loaded it (amongst other things) registers itself with one or more 'hook points' (a hook point is a point within the program's execution). When two or more modules register themselves as being callable at the same hook point then the order they are called is the same as the order they were loaded.
The Apache software is built around a fairly typical plugin architecture, I'm not going to go into huge detail about the finer details of this as I would assume that there are numerous articles and discussion on this type of implementation dotted around the web and can probably explain it better than I can.
Although I will just touch on your question regarding loading external modules. Each module is loaded in the order it appears in the 'LoadModule' section of the config file. When the module is loaded it (amongst other things) registers itself with one or more 'hook points' (a hook point is a point within the program's execution). When two or more modules register themselves as being callable at the same hook point then the order they are called is the same as the order they were loaded.
Re: I request /phpinfo/ and I get served /phpinfo.php
Yeah I understand I was just more looking for an up to date complete list of the phases, and when the hooks get invoked. I guess the documentation is just in fact incorrect / outdated / ommits details / however the heck ya wanna put it! The only way to know for sure is to read the source like I figured. Thanks for clarifying what happens when 2 modules perform a similar task in the same phase. We have established a wealth of info now that IMO are omissions. Guess Apache has no intention to maintain or increase user adoption of their system ( sarcasm )
Re: I request /phpinfo/ and I get served /phpinfo.php
To be fair, an open source project (of any reasonable size) with documentation that could be considered complete, accurate and covers all aspects of the project in fine detail would be a rare find in my opinion. Not saying it doesn't exist, but from my own experience, I can't think of one off the top of my head. That's not a complaint, merely an observation.
Re: I request /phpinfo/ and I get served /phpinfo.php
Oh I totally agree, there are tons of issues with datashuffler ( one of my OS projects ), but if someone brought them to my attention I would at least be receptive to their feedback. oh well thanks for your help tho you've taught me some interesting things, hopefully there were no perceived undertones in our exchanges