Dealing with “404″ errors in PHP frameworks
July 7, 2008
I didn’t want to steal the title “Is your MVC MIA when it comes to 404s?“, cause it’s just too good to plagiarize. My brother’s written a post that he’s looking for some feedback on.
Excerpt:
Usually, a request into a PHP framework is something like this
example.com/some/thing
… which gets re-written by mod_rewrite into
example.com/index.php/some/thing
The index.php uses the remaining “/some/thing” as instructions for which bit of logic to run. Failing to find the requested code can be akin to not finding a regular page in the traditional Web world, which would result in a 404 error. But, shouldn’t we expect a bit more from an advanced Web framework nowadays?
What do you think?
Did you like this post? Buy me a hot chocolate!
Posted in PHP
July 7th, 2008 at 10:46 pm
Symfony, PHP 5 framework, handles 404’s on an “application” basis. You can also build logic that will forward 404. Not sure if this resolves/addresses the issues you are discussing.
July 7th, 2008 at 11:07 pm
In Midgard, all HTTP errors start as Exceptions. If URL doesn’t match any installed route, or a route returns the midcom_exception_notfound error, then 404 results. Unless it is caught somewhere of course…
July 8th, 2008 at 1:19 am
Controller, Action not found => 404
/**
* Error Action
*
* @access public
* @return void
*/
public function errorAction()
{
$errors = $this->_getParam('error_handler');
$exception = $errors->exception;
switch ($errors->type) {
case Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_CONTROLLER:
case Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_ACTION:
// 404 error -- controller or action not found
$this->getResponse()->setRawHeader('HTTP/1.1 404 Not Found');
$this->view->title = 'Not Found';
$this->view->message = 'The requested URL was not found on this server.';
Object not found? => 404 (the solution is a bit hackish but works perfectly)
if (!$this->view->post = $post->find($id)->current()) {
throw new Zend_Controller_Action_Exception('Post ' . $id . ' not found.');
}
July 8th, 2008 at 5:41 am
I think there is a limit to how useful any MVC framework can be in cases like this. These frameworks are meant to be a (for better or worse) one size fits all solution. The good frameworks should allow you to detect 404 errors before they are shown to the user—but what they actually do on a 404 error should probably be left to the developer.
A good 404 page isn’t part of the framework, it’s part of the application built on the framework and therefore beyond the scope of the framework itself.
July 8th, 2008 at 6:16 am
@all - thanks for the feedback and examples!
@dj - but if a framework isn’t able to take a request for something it doesn’t know about and deal with it intelligently (pass it to another controller for that purpose, for example), you can’t build an application on top of the framework to deal with that condition. Right?
July 8th, 2008 at 6:50 am
@mgkimsal Right, the framework should give you the tools you need to handle a 404. If there’s no mechanism in place for catching calls to controllers that don’t exist, that’s the fault of the framework. But the framework doesn’t necessarily have to do anything with 404s out of the box.
@Sebastian Thanks for the code snippet. I may “borrow” it.
July 8th, 2008 at 9:53 am
@DJ
My post wasn’t really about a lack of catching 404s at all. It was about the subtle difference between saying that a missing controller is an ERROR or that it is not an error.
I know that you can probably deal with missing bits of application via an error handler in all these php frameworks… but why should you have to?
You wouldn’t think of saving objects to the database by triggering an error and then expecting your DB driver to catch the error and save the object. So, why are frameworks expecting us to “catch” or treat this condition as an error… That was the point.
@Jake
Sounds like Symfony and Cognifty have the same mindset about the problem.
July 8th, 2008 at 1:01 pm
@mark I think I see what you’re saying. Is your point that the MVC paradigm breaks down when 404s are treated as an error state that forces you to code outside the model?
But doesn’t directing all 404s through a special error controller violate the MVC model as well? The URI to controller/action mapping is lost. But at worst, that’s just bending the rules—whereas the thrown error state is, as (I think) you’re saing, breaking the rules. Point taken.
July 9th, 2008 at 7:49 am
@dj I think the point is just to raise the question “does 404 break MVC paradigm when treating 404s as errors?” I’m really not attempting to answer it, but just raise awareness.
I would say that… there is no URI to controller/action mapping inherent to MVC… that is just an artifact of doing MVC on the web. Look at Java Swing’s JTable API… there’s no URI to controller mapping… but it’s still MVC. Also, Qt’s MV (no C) is pretty good and more more closely representative of what goes on in Web environments.
There’s no requirement that a URI maps to exactly the same name of directory/file/function. It’s just the most convenient way of doing Web MVC. Which is why LogiCreate did it in 2001. Now you see people adding in “routes” and “vanity urls” to change how a URI maps to a controller.
Again, the article was chiefly about solving problems with “consistency”.