Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm getting sick of all of Apache's quirks, and I'm considering starting to avoid .htaccess as much as I can in favor of writing actual, predictable code. It would be easy and straightforward to emulate things like file security and rewrites, and control precisely what is and isn't inherited between directories without having to use strange, obtuse directives. Would there be any downsides to this?

I'm talking about replacing, for example, this:

# .htaccess
RewriteCond %{HTTP_USER_AGENT} blah
RewriteRule ^(.*)$        /test$1 [R=301,L]

with something like this:

# PHP, in a header file
if(strpos($_SERVER['HTTP_USER_AGENT'], 'blah') !== false)
    redirect(301, '/test' . $_SERVER['REQUEST_URI']);

To repeat the question, what would be the downsides of implementing functionality in PHP which is traditionally handled by .htaccess?

share|improve this question
    
That's just nonsense! –  Stephen Jan 27 '11 at 18:08

3 Answers 3

I have written a framework for my own use that gets rid of all rewrites but one - rewrite (not redirect) everything to a single index.php. That index.php creates an instance of the framework controller and then tells it what paths exist in the site:

// Create paths for this site
$controller->addPath('/path', 'templatename, 'MyClass::someCodeToRun');

Of course there is more to it than that (mainly dynamic paths, nested templates, and security), but that's the basic idea.

This is what many frameworks do, and I really recommend it - it doesn't need to come at (much) of a performance price if your framework is lightweight and you only include what you need for each path. The only performance price is essentially the lookup table (which is just an associative array) for which path does what.

I think the better code organization can often end up being a performance win.

share|improve this answer
    
I was actually thinking about doing something like this, but I wasn't sure whether it would be too insane. I guess if you're separating the file system from URIs, might as well go all the way, right? –  Note to self - think of a name Dec 9 '10 at 1:51
    
@Note to self - Yep. No sense having anything halfway between the two, which would lead even more confusion than you're already seeing with .htaccess. –  NickC Dec 9 '10 at 1:53
    
This is how many of the MVC frameworks basically work (e.g. CakePHP with it's routes). In the few projects I've built that didn't use a framework, I've usually gone with something similar to this as well. –  Dean Harding Dec 9 '10 at 4:12

Performance and scalability are the two primary reasons to use Apache to do the work as opposed to an app server (hosted PHP code, Java Servlets, Ruby on Rails, Asp.NET, etc.). Essentially Apache is very good at handling a large number of requests, and the 2.x versions use non-blocking I/O which means it can work with many many more requests than processes and threads in use. This is a good thing.

Hosted code usually makes some assumptions in an effort to make it easier to program, such as the code environment having full access to a thread. No matter how efficient your solution is, you won't be able to scale as gracefully unless your platform works the same way Apache server works.

share|improve this answer
    
However, if you are rewriting two different URLs to two different PHP files, the end result is much the same as rewriting two different URLs to the same PHP file which then branches based on path. Which, I believe, is what the OP was asking about. If the URLs can avoid PHP altogether (and be served directly by Apache - HTML, JS, images) then you are absolutely right. –  NickC Jan 27 '11 at 17:42
    
I was answering the question in the most general sense of why there is benefit to .htaccess. That doesn't preclude the fact that there are several downsides to .htaccess as well. –  Berin Loritsch Jan 27 '11 at 17:44

Performance, probably...

Also, the two behaviors you describe are not the same - a rewrite is not the same as a 301 redirect.

share|improve this answer
    
Oops, dumb oversight, fixed –  Note to self - think of a name Dec 9 '10 at 1:42
1  
By limiting your question to only cases where you're redirecting, you significantly weaken your question. I would be OK with saying that redirect logic should be within your PHP or other code, but rewrite rules should, in many cases, stay in httpd.conf or .htaccess where they belong. –  Michael Kopinsky Dec 9 '10 at 2:10

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.