Page 1 of 2
I request /phpinfo/ and I get served /phpinfo.php
Posted: Tue Aug 04, 2009 1:38 pm
by josh
This is interfering with my rewrite rules. So I disabled the mod_rewrite from even being loaded and I can still replicate this. I even turned off allow override, restarted the server
Also strangely, if I request /foo/ I get a regular 404, but heres the kicker
I create a file foo.html and request /foo/ again and I get a 404 but I get
"The requested URL /sort.
html/ was not found on this server."
Any clues?
I'm just trying to make a simple rule RewriteRule ^skin/(.*)$ /skin.php?file=$1 [L]
127.0.0.1 - - [04/Aug/2009:14:26:12 --0400] [
www.localhost.k12jobs.com/sid#3c0998][rid#42520c0/subreq] (3) [perdir C:/dev/k12/html/] add path info postfix: C:/dev/k12/html/skin.php ->
C:/dev/k12/html/skin.php/styles/layout.css
As you can see when I do have the rewrites enabled, the issue interferes with my script by rewriting it without the ?file= part on there.
However if I rename skin.php to skin2.php and update my rewriteRule, requesting /skin/foo/ properly rewrites to skin2.php?file=foo

Re: I request /phpinfo/ and I get served /phpinfo.php
Posted: Tue Aug 04, 2009 5:15 pm
by Weirdan
josh wrote:I request /phpinfo/ and I get served /phpinfo.php
This kind of behavior is controlled by MultiViews and AcceptPathInfo directives. MultiViews enable serving /phpinfo.php when /phpinfo is requested, AcceptPathInfo allows to add anything that looks like a path to it (e.g. /phpinfo/ or /phpinfo/name/value/anothername/anothervalue). If you're using mod_rewrite you may want to disable those and see if it helps. Other than that I'm out of ideas.
Re: I request /phpinfo/ and I get served /phpinfo.php
Posted: Tue Aug 04, 2009 6:09 pm
by josh
Adding "AcceptPathInfo Off" to my vhost fixed it but I don't see where this behavior is documented, do you think its a bug?
http://httpd.apache.org/docs/2.0/mod/core.html
Manual says if it is not explicitly on / off the handler responsible for the request is in control
if OFF a request will only be accepted if it maps to an existing path. "For example, assume the location /test/ points to a directory that contains only the single file here.html. Then requests for /test/here.html/more and /test/nothere.html/more both collect /more as PATH_INFO.Therefore a request with trailing pathname information after the true filename such as /test/here.html/more in the above example
will return a 404 NOT FOUND error."
ON
" A request will be accepted if a leading path component maps to a file that exists. The above example /test/here.html/more will be accepted if /test/here.html maps to a valid file."
So if it were default I would expect my rule to go thru, if it were OFF I would expect a 404 error or my rewrite to work, if it were ON I would expect
/skin.php/whatever will be accepted as /skin.php, but not
/skin/ to map to skin.php.
So I guess I am asking if I don't have this thing explicitly configured why would it turn ON instead of the behavior under DEFAULT, and is it a bug that the ON behavior is magically coming up with file extensions? I mean what if I have skin.sql skin.pl, etc... this can't be documented behavior can it? But turning it off does fix my problem.
Re: I request /phpinfo/ and I get served /phpinfo.php
Posted: Tue Aug 04, 2009 7:37 pm
by Weirdan
josh wrote:Adding "AcceptPathInfo Off" to my vhost fixed it but I don't see where this behavior is documented, do you think its a bug?
I think it depends on both the compile details and configuration files. I am by no means an expert in Apache configuration, and I haven't seen your configs (not that it would help, since I'm no expert), so I can't give you a definite answer on this.
Re: I request /phpinfo/ and I get served /phpinfo.php
Posted: Wed Aug 05, 2009 12:17 pm
by josh
Here's what they wrote about this thread
"This behavior is by design.
Disable multiviews or disable acceptpathinfo.
issues.apache.org is not a support forum. Use the peer-support users@ list
to discuss configurations"
Makes absolutely NO sense ( if I have foo.htm and foo.php why should requesting /foo/ serve 1 over the other?? )

Re: I request /phpinfo/ and I get served /phpinfo.php
Posted: Wed Aug 05, 2009 12:20 pm
by Eran
This behavior is by design.
I love this response. Developers usually give this when they think it's a hassle to change existing behavior.
Re: I request /phpinfo/ and I get served /phpinfo.php
Posted: Wed Aug 05, 2009 2:52 pm
by josh
yep.
https://issues.apache.org/bugzilla/show ... i?id=47644
"Bugzilla is not the place to argue about whether something is a bug or you just
don't understand the behavior. Take it to the users mailing list."
How about, bugzilla is not the place to argue subjective statements.

I dont care if it was by design I'm telling them it differs from the docs, ugh!
Re: I request /phpinfo/ and I get served /phpinfo.php
Posted: Wed Aug 05, 2009 3:37 pm
by josh
Hmm I found out its a combination of accept path info and multi views thats producing this, multi-views basically says to expect wacky behavior, but then that in turn makes the rewrite engine documentation incorrect, a rewrite rule should take precedence one would imagine, oh well. I guess they are going to chew me alive for commenting on their docs
This is why they have a reputation for being more complex then the other web servers, yeah it works, so does freaking chizzeling punch cards from blocks of stones it doesnt mean its practical or the best way
Update:
I inform them their documentation does not state rewrite rules run _after_ those modules, nowhere I could find anywhere about the order the modules run in their documentation, so I make a suggestion and they keep shutting me down, so I ask "So if there are issues with the documentation then APACHE doesn't want to know
about it? Really?"
Their official statement:
"the number of interactions between your choice of configuration of
the entire array of modules cannot reasonably be documented" ...
"Reopen this upon threat of being blacklisted to apache.org topography, your
immature behavior is not amusing. You have been told repeatedly that this
is not a support forum."
So I try to bring a gap in their docs to their attention, and they threaten to block me from the entire apache.org domain ( too bad the tracker runs on bugzilla.org ), which would basically impede me in what I do for a living, oh and to top it off a personal insult
Hopefully this thread saves other people time, I'm going to do some serious reading up on lighthttpd, so glad I run ZF routes and can easily switch over since apache is clearly NOT SANE, they could have just wrote in the first place "thank you for your suggestion we will pass it along", in my opinion they are the ones acting immaturely.
Re: I request /phpinfo/ and I get served /phpinfo.php
Posted: Wed Aug 05, 2009 7:16 pm
by redmonkey
josh wrote:Adding "AcceptPathInfo Off" to my vhost fixed it but I don't see where this behavior is documented, do you think its a bug?
http://httpd.apache.org/docs/2.0/mod/core.html
Manual says if it is not explicitly on / off the handler responsible for the request is in control
if OFF a request will only be accepted if it maps to an existing path. "For example, assume the location /test/ points to a directory that contains only the single file here.html. Then requests for /test/here.html/more and /test/nothere.html/more both collect /more as PATH_INFO.Therefore a request with trailing pathname information after the true filename such as /test/here.html/more in the above example
will return a 404 NOT FOUND error."
ON
" A request will be accepted if a leading path component maps to a file that exists. The above example /test/here.html/more will be accepted if /test/here.html maps to a valid file."
So if it were default I would expect my rule to go thru, if it were OFF I would expect a 404 error or my rewrite to work, if it were ON I would expect
/skin.php/whatever will be accepted as /skin.php, but not
/skin/ to map to skin.php.
So I guess I am asking if I don't have this thing explicitly configured why would it turn ON instead of the behavior under DEFAULT, and is it a bug that the ON behavior is magically coming up with file extensions? I mean what if I have skin.sql skin.pl, etc... this can't be documented behavior can it? But turning it off does fix my problem.
The documentation also clearly states...
Apache Docs wrote:Default
The treatment of requests with trailing pathname information is determined by the handler responsible for the request. The core handler for normal files defaults to rejecting PATH_INFO requests. Handlers that serve scripts, such as cgi-script and isapi-handler, generally accept PATH_INFO by default.
When you run PHP as a CGI handler you explicitly declare it as a handler with the 'AddHandler' directive, when you run PHP as an Apache module, the module registers itself as the handler for mime types 'application/x-httpd-php', 'application/x-httpd-php-source' and 'php5-script' and these are associated with your PHP files using the AddType directive.
So, in your example above, because you had multiviews enabled it picks up skin.php when the url is /skin further more because the default behavior of AcceptPathInfo is to leave it up to the handler to decide how to deal with it and PHP's internal logic is to behave as tho AcceptPathInfo is 'on' unless explicitly set 'off' then the URL /skin/ is also valid.
In short, the response you received from your Apache bug report is in my opinion justified, this is not a bug, it is 'expected behavior' given your configuration.
The problem you are running up against is that mod_rewrite is normally used to rewrite virtual URLs to physical paths but in this case (due to your config) the initially requested URL is seen as a physical path (which is why it works when you renamed skin.php to skin2.php).
Re: I request /phpinfo/ and I get served /phpinfo.php
Posted: Wed Aug 05, 2009 7:24 pm
by josh
Thanks for the response can you link me to where it explains the last part, virtual URLs vs physical URLs. Honestly they are justified to do whatever they want, I don't pay them, but I just think its hypocritical for them to respond to a suggestion with a personal insult & threat. I tried googling their docs for rewrites and virtual URLs, etc.. and found NOTHING, maybe I'm missing it but in my opinion it took more effort for them to respond the way they did
How was I being immature? I wasn't going to even submit it as an issue but I felt like if I was in their shoes I would welcome feedback from my users, etc.. I understand accept path info and multi views now, just not why they have to stomp on rewrites
Re: I request /phpinfo/ and I get served /phpinfo.php
Posted: Wed Aug 05, 2009 8:04 pm
by Weirdan
josh wrote:I wasn't going to even submit it as an issue but I felt like if I was in their shoes I would welcome feedback from my users, etc..
I don't think you would. Not given the size of their auditory. Apache runs half the web, literally.
Re: I request /phpinfo/ and I get served /phpinfo.php
Posted: Wed Aug 05, 2009 8:12 pm
by redmonkey
You can view the docs for mod_rewrite but to be honest I don't think it categorically states that attempting to rewrite physical paths is a bad idea. I haven't looked into it but I'd guess there is probably some internal logic that spots that the originally requested URL is a valid physical path and therefore decides that the rewrite is possibly an error and just serves the original URL. When you think about it, there is no real reason to rewrite a physical path as doing so would mean that users would not be able to access that physical path and if they can't access it why is there?
josh wrote:How was I being immature? I wasn't going to even submit it as an issue but I felt like if I was in their shoes I would welcome feedback from my users, etc.. I understand accept path info and multi views now, just not why they have to stomp on rewrites
Not sure I want to get in to this but you've asked the question so I'll give you an answer. Their initial response was that it wasn't a bug but a configuration issue, they also gave you hints on where to look and suggested that you should take the issue to one of their support channels. Despite this, you came back with more questions and comments, questions and comments which in my opinion should've been directed at their support channels. They did inform you in a further three separate responses that the bug tracker was not the place to discuss this type of issue but still you pressed on until they felt the need to threaten to blacklist you from the bug tracker.
Personally I think you should've taken your issue to one of their support channels after the first response, and after thrashing it out there if it was deemed a valid bug you could've gone back and updated the bug accordingly.
I find that most open source projects are very open, appreciative and responsive to feedback and issues but only if they are delivered through the correct channels. You have to appreciate the size of the Apache project and I'd imagine that they receive a large amount of bug reports that are bogus. Persistently pushing an issue in the wrong channel (especially when you've been informed as such) is very much frowned upon and that's not an Apache project thing, that's just a general rule of most projects.
Hopefully it won't stop you or put you off reporting bugs in the future.
Re: I request /phpinfo/ and I get served /phpinfo.php
Posted: Wed Aug 05, 2009 8:35 pm
by josh
Yeah they may run half the web, they could be running three quarters though.
http://plugins.jquery.com/node/9585#comment-3924 This developer received a report of similar circumstances and I'm going to throw him some contributions for being very helpful. I bet if they listened to their users core problems they could pick up market share and easily monetize it thru support, but I digress.
It would make sense to me, speaking from an intuitive standpoint, that if I am rewriting /foo to /bar and then I request /foo with multi views enabled I would get /bar.htm I could see that, I just can't make out the logic in having the dependency the other way around, not saying theres not a reason but apparently they are keeping that information confidential ( dry humor / sarcasm ).
I assume the overall goal in any design is being intuitive to the user, if you can make it more intuitive why not do it? In this case it could affect BC in a minor way but it would arguably be just as useful to. Eh, at the least they could have simply asked me to not followup any further with them

Not like I try to get in peoples hair intentionally.
I do agree the first half of the ticket I was in the wrong, I did not understand the module and mis-read weirddans post too. The second half of the ticket I was trying to bring up a related, but separate issue ( missing documentation ) and at no point did they advise me I was becoming a nuisance, but no use crying over spilt milk, I do get put off by this type of response, I'm sure false bug reports are plentiful but closing of valid issues does happen too.
I am still left with many questions as to the undocumented behavior. I guess I will thrash it around on the user forum, even if someone has the esoteric knowledge and is able to explain what is happening though, its pretty crummy they are not going to address why the documentation skips over these critical concepts. Not like anyone expects an itemized list of how the modules interact, but it would be nice for them to touch on the subject.
What do you think the proper channel would be to discuss the possibility of clearing up some ambiguities in the documentation? Obviously there is room for improvement ( as with anything in life ) which you would think would correlate with the # of false reports they receive ( explaining why it works the way it does so the users can better judge if something is a bug !!! )
Re: I request /phpinfo/ and I get served /phpinfo.php
Posted: Wed Aug 05, 2009 9:31 pm
by redmonkey
josh wrote:Yeah they may run half the web, they could be running three quarters though.
http://plugins.jquery.com/node/9585#comment-3924 This developer received a report of similar circumstances and I'm going to throw him some contributions for being very helpful. I bet if they listened to their users core problems they could pick up market share and easily monetize it thru support, but I digress.
To be honest, other than the response providing direct links, I don't see that there is that much difference between the response you got from your jQuery bug report and the initial response from your Apache bug report.
josh wrote:It would make sense to me, speaking from an intuitive standpoint, that if I am rewriting /foo to /bar and then I request /foo with multi views enabled I would get /bar.htm I could see that, I just can't make out the logic in having the dependency the other way around, not saying theres not a reason but apparently they are keeping that information confidential ( dry humor / sarcasm ).
The dependency isn't the other way round. I think a more appropriate question would be why would you want to rewite a physical path? Although I can see what you are trying to do you have to consider that the Apache server has no clue what you are attempting as far as it's concerned it's a fairly black and white matter of attempting rewrite a physical path.
josh wrote:I do agree the first half of the ticket I was in the wrong, I did not understand the module and mis-read weirddans post too. The second half of the ticket I was trying to bring up a related, but separate issue ( missing documentation ) and at no point did they advise me I was becoming a nuisance, but no use crying over spilt milk, I do get put off by this type of response, I'm sure false bug reports are plentiful but closing of valid issues does happen too.
They did clearly state multiple times that the bug tracker was the wrong place to be having the discussion. To be honest, I personally don't think that the mod_rewrite documentation not stating that rewriting physical paths is an omission or valid bug either.
josh wrote:I am still left with many questions as to the undocumented behavior. I guess I will thrash it around on the user forum, even if someone has the esoteric knowledge and is able to explain what is happening though, its pretty crummy they are not going to address why the documentation skips over these critical concepts. Not like anyone expects an itemized list of how the modules interact, but it would be nice for them to touch on the subject.
Don't be fooled into thinking that just because it's a 'general support' channel that all you are going to get is people quoting from the documentation, support channels for open source projects are generally frequented by some very smart people that know their onions. Modules and components are generally documented as individual items, it's up to the end user to read the doc for the various modules and work out any potential conflicts. I think if the docs included all the various module interactions and possible configuration conflicts they'd be so verbose and confusing that nobody would go near them (most people don't read them as they stand now).
josh wrote:What do you think the proper channel would be to discuss the possibility of clearing up some ambiguities in the documentation? Obviously there is room for improvement ( as with anything in life ) which you would think would correlate with the # of false reports they receive ( explaining why it works the way it does so the users can better judge if something is a bug !!! )
Regardless of the project or product your first port of call is generally the general support channels. Apache's bug tracker does have the ability to log a bug under the 'Documentation' component. However, while you may think it's a bug that doesn't necessarily mean that the documentation maintainers will agree with you and in those cases, adding to the bug report with comments like 'Why is that', 'How come this' or 'Can't you just..' will be frowned upon.
I've submitted bugs to projects before that I still to this day believe are bugs or could at least be correct by a feature enhancement but the core developers haven't agreed as they believe that the fundamental design of the particular component was never intended to work the way I was describing. On a couple of occasions I've accepted their comments and moved on, on others I've taken it to one of their mailing lists to discuss it further. What I do not do is attempt to use the bug report as a discussion forum thread or sounding board.
Re: I request /phpinfo/ and I get served /phpinfo.php
Posted: Thu Aug 06, 2009 12:32 am
by josh
redmonkey wrote:To be honest, other than the response providing direct links, I don't see that there is that much difference between the response you got from your jQuery bug report and the initial response from your Apache bug report.
The difference was the jquery functionality was documented, apache's was not.
redmonkey wrote:To be honest, I personally don't think that the mod_rewrite documentation not stating that rewriting physical paths is an omission or valid bug either.
I had a long response typed out but I canned it, I guess the only thing I have to say on this one is the definition of an
omission is "excluding information" / "to leave out". In this case the functionality made it to core but not the docs. There are plenty of reasons someone would want to rewrite a "physical path" ( which I haven't found an official definition of yet ), one of them given in my OP.
I wasnt asking them to explain their reasoning or to support me in any way. I was incorrect about the first omission but after I was corrected I pointed out another that they have sort of indirectly confirmed as an omission. I was trying to explain the way their server was behaving under a certain configuration and the way that differed from my expectations, I guess it is a grey line whether you consider it a suggestion or an attempt to coerce them to change the manual at my beck and call ( not the case ). I certainly have nothing to personally gain from them changing the docs. I don't see how adding a new section explaining what a physical path is and how the "flow" happens or why a physical path causes the rewrite engine to not activate, they already have examples, introductions, etc.. all in different sections of the manual, adding another section covering the omission wouldnt make any of the other stuff more verbose.
And if most people dont read the docs is a valid reason to leave stuff out, why even write docs at all? I'm not saying they have to implement 100% of the suggestions that they receive, just kinda shocked how they address you