Rackspace Server .htaccess url rewriting problem

Hi all,
I'm looking for help from someone that has experience with Rackspace hosting environments as I'm pretty sure this issue is specific to my hosting environment and not an .htaccess problem.  My production server is a Rackspace managed cloud environment that has a master & slave server behind a load balancer and varnish with Apache, MySQL & PHP.  The relevant .htaccess code pasted below works on several local LAMP, WAMP, & MAMP dev environments but doesn't work on the production server.  I do have a support ticket open with Rackspace but after about a week without a solution I wanted to start looking elsewhere for help; not a jab at their support which has always been a 9 or 10 out of 10.

What I need to accomplish when a user goes to "domain.com/someRequest":
Extensionless url rewriting:
1. If ".../someRequest" is a directory then serve ".../someRequest/index.php|html", the normal Apache behavior.
2. If ".../someRequest" is not a directory but is an existing php file then serve ".../someRequest.php"
3. If ".../someRequest" is not a directory and is not an existing php file then move on to the next rewrite rule.
Handle dynamic pages & 404
4. The next rewrite rule will serve ".../page.php?id=someRequest".  This file will look for a dynamic page in the database and return the page's content & other info if found.  If not found, it will redirect to our 404 page.

The relevant .htaccess code that works in various local dev environments:

# Resolve .php file for extensionless php urls
RewriteCond %{REQUEST_URI} !-d
RewriteCond (%{REQUEST_URI})\.php -f
RewriteRule $1.php [L]

# handle dynamic pages from the database & 404
RewriteRule ^([a-zA-Z0-9_-]+)$ /mrsmob/page.php?id=$1 [NC,L]

Thank you in advance for your time.
LVL 1
foxymoron7Asked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Steve BinkCommented:
I'm not sure how that rule could work - you are missing part of it.  It should look more like this:
RewriteCond %{REQUEST_URI} !-d
RewriteCond %{REQUEST_URI}\.php -f
RewriteRule (.*) $1.php [L]

Open in new window

The change simply adds the match portion of the RewriteRule directive.  I also removed the backreference capture on the second RewriteCond, since it was not being used.  That bit is fine if left alone, though.

RE: the first two goals in your rewriting.  You did not post the directives for these, so I imagine you are handling them through other means.  Be aware that if you are allowing #1 to be resolved via the DirectoryIndex settings, the rewrites will fire prior to Apache targeting that file.  You may need to compensate for that in rules further down the line.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
foxymoron7Author Commented:
Hey Steve,

Thank you for your response.  Everything I know about .htaccess should be put in a .gitignore file.
I'm not sure why my original .htaccess worked on several *AMP dev machines, but it worked so I assumed it was good.  Turns out the solution has two parts - adding ^(.+)$ to the rewrite rule and changing REQUEST_URI to REQUEST_FILENAME.  Again, I don't know why this works but it does. :)  Here is the new code that is working:

# Resolve .php file for extensionless php urls
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME}.php -f
    RewriteRule ^(.+)$ $1.php [L]

Thanks again for your help!
0
foxymoron7Author Commented:
Forgot to mention as a side note that the new code does not work on either of the dev machines I tried it on but the old code does.  Hopefully one day I'll find the time to figure out why.
0
Steve BinkCommented:
>>> changing REQUEST_URI to REQUEST_FILENAME.

Yeah, my bad for not picking up on that one.  The REQUEST_URI variable is the resource as seen by the requesting client (i.e., relative to the site's DocumentRoot), whie REQUEST_FILENAME is the resource as seen by the local server (i.e., the full local path).  

Here's a bit of help for when you get around to investigating why the original rule worked at all.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Apache Web Server

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.