On Reddit today there's a rather large discussion going on about the recently posted manifesto from Ed Finkler about building simple, manageable tools rather than using "kitchen sink" frameworks for your applications.

As of the time of this post there's about sixty-five comments posted to the thread with widely ranging opinions:

• "How is [lots of separate libraries scattered around] better than simply using a framework?"
• "This is part of the reason for the PSR0 reference for auto loaders [...] Part of the problem is an inconsistent way to load modules."
• "I would love to see this become a trend in the PHP community. I think this is exactly the direction needed to make PHP exciting again and regain mindshare in the wider dev community."
• "I know, many people are currently on that micro trip but seriously, I think that there is as much to microframeworks as there is to microoptimization"
• "A framework is a tool. If you don't need it, why use it?"
• "There's a tool for ever job, I agree some projects or companies "need" something like Zend or Symfony for their enterprise projects. Whether or not you'd want to work on a project with 1000's of classes is something else all together."

Read the full responses to Ed's article here.

In response to some of the comments being made about the hash table Denial of Service attack recently posted Freek Lijten has posted his thoughts about the real problem with the whole situation - how it was handled by the communities involved.

Interesting they may be, but I want to address what in my opinion is the real problem: The way the communication around it was handled by different projects and the fact that the exploit could still exist at all. [...] In the presentation Wälde and Klink talk about their disclosure process. The PHP project had them wait 3 weeks for a first response while this is obviously a serious matter.

He argues that things like a commit message mentioning a DoS prevention fix instead of just mentioning the fix have the potential to do more harm than good. He also points out that other communities were notified of the problem (like Python) and some still haven't responded to the issue.

This attack was the result of good research and it is important that it is disclosed. More importantly however is the fact that organisation got by with years of not noticing it and even worse, reacted very poor after being informed. I can't say I have a ready solution to avoid these kind of things in the future, perhaps that will prove to be an interesting discussion.

In a recent post to his blog Chris Hartjes looks at the idea of better HTTP Request/Response functionality in PHP, more than just the superglobal handling and PECL HTTP extension it has now.

I think the fact that we have $_POST and $_GET lulls some of us into the false sense that we should have $_PUT and $_DELETE objects, since that would map to the commonly-desired set of HTTP verbs that REST likes to use. But what should be inside those things, or should we be moving towards a more Pythonesque solution where a Request object, as part of core or via a only-really-for-the-brave- PECL extension?

He mentions opinions from other PHP community members (Laura Thompson and Elizabeth Smith) and a bit about what he (and I'm sure other developers) are looking for in a more full-featured request/response handling feature.

David Stockton has a new tutorial posted to his blog - a technique he's found useful in his Zend Framework application to make the ErrorController work with Ajax calls to reduce the message you get back to just a JSON response.

If you've ever built a Zend Framework MVC app which makes AJAX calls, you may have noticed that if an error occurs, you'll get a chunk of JSON followed by the HTML for the error page. If you've built a layout, you'll get all of that back to. This is fine if your users hit the page in the browser but it can cause problems with your JavaScript being able to correctly decode your JSON.

The fix is pretty simple, though, and only requires that you add the error handling action to the Ajax context to force it to drop the layout and any other HTML that might come along with the view. He includes a bit more code to have the error handler include the exceptions and pass them out to be included in the JSON response.

In response to this article from DevShed about creating a "simple and secure login script", Anthony Ferrara has written up this post to help dispel some of the inaccuracies, bad practices and security issues that could result from DevShed's code.

I decided to click the link [in my feed reader] and give the article a read. Not overly shocking was the fact that I didn't find the content of the article to be, how shall I say this..., overly factual. It's not really a "tutorial", but more of a "here's some code that's secure". A quick review of the code found more than one vulnerability, and some significant things that I would change about it (as well as a few "really bad practices").

He walks through each of the files included in the original tutorial - Authenticate.php, Register.php and Logout.php - and talks about things like brute force detection, password verification, registration handling and session serialization. He finishes it off with a list of twelve overall issues he noticed during his work along with solutions for each (usually very simple ones too).

In a response to this post that introduced some basic security methods for your applications, Anthony Ferrara has posted some corrections and updates to the suggested methods, even pointing out where some of them are completely wrong.

Today an article popped into my feed reader that raise my eyebrows. The article's title is "Building Secured Web Applications Using PHP - The Basics". The summary of the item looked interesting, so I decided to open it up...What I found blew me away. It was filled with loads of bad information including some down-right wrong suggestions. Let me go through point by point and shed some light on the subject...

His response goes back through the original article by section header and explains either why the advice was bad and/or the more correct way to do things.

Security is not something you can learn in a page. It's not something that you can learn in a single book. It takes a lot of time and effort. It should not be trivialized into a simple "Do this and you'll be secure" style post. It sends the wrong message...

Michael Nitschinger has put together a guide to caching responses in the Lithium framework - a simple update that means your application dosen't even need to reach the controllers to do its job.

I've hacked together a small example on how to easily cache full responses in Lithium. If you need to cache full Response objects in Lithium (which means that your controllers don't even get called when there's a cache hit), you can place this in your app/config/bootstrap/cache.php file (note that this is certainly not "production ready", but it should give you a starting point).

The code adds a new filter to run on execute that takes the current object (the Response object hit the first time) and use the Cache functionality to push it into storage. Their cache key is based on the URL, so each requests is cached individually. You can find out more about filters and the framework at Lithify.me.

In a recent post to his blog Artur Ejsmont looks at an attack that could potentially leave a hole open in your PHP-based application for a cross-site scripting (XSS) attack - HTTP response splitting (mail headers too).

There are two similar security issues both taken care of by Suhosin patch and strict escaping/encoding rules. They both relate to injecting new lines into headers of network protocols. They are not very well known and i think its worth mentioning it. HTTP response splitting is a web based attack where hacker manages to trick the server into injecting new lines into response headers along with arbitrary code. If you use GET/POST parameters in the headers like cookie or location, then someone could provide new lines with XSS attack.

He gives some examples of how it might work via the header function so that superglobals might be abused (like adding information on the URL to inject into $_GET). To prevent the attack, you just have to ensure that no special characters make it into the headers or cookies. He also mentions that the Suhosin patch takes care of the issue automatically.

On the php|architect blog today Bill Karwin has posted his response to this interesting suggestion from Dennis Hoston about how to "reinvent" object-oriented programming in PHP.

Dennis acknowledges that the name needs work. But, getting past that, his blog is about some creative experiments Dennis is working on. He has come up with a pretty innovative way of creating objects dynamically in PHP that allows for some usage that conventional PHP coding techniques don't support.

He talks about some of the features that this method allows that the usual style of OOP don't allow like class scoping, methods can be added at any times and that the classes created can be temporary. He points out that the base object is actually a factory and makes it simple to create those other instances of child objects. He also mentions some of the features that will no longer work with Deniss' approach like interfaces, instanceof, reflection and autoloading to name a few.

In a new post to his blog Kevin Schroeder shares some of the responses he received from a question he posted on Facebook - what's your favorite PHP resource?

Earlier today I had asked on the Zend Facebook page "what is your favorite page for getting PHP-based information?" There were some good answers there so I figured that I would post those answers here (since it's all public information anyways).

Sites mentioned in his list include:

• ProPHP.org
• StackOverflow
• PHPFreaks.com
• PHPClasses.org
• DZone.com

Several also mentioned using the Freenode IRC network (in channels like ##php and #phpc) for a more interactive form of help.