On the Leaseweb Labs blog there's a recent post looking at using the POC framework to work with flexible output caching. The tool makes it easy to create a new object and push cache content into it, automatically caching the data to sources like the file system, a Redis instance or a MongoDB database.

Last year at the Symfony conference in Paris I have heard a really good quote: "There are only two hard things in Computer Science: cache invalidation and naming things" - Phil Karlton. I agree with it and it gave me a boost to keep evolving the concept.

He includes an introduction to the caching features of the framework complete with sample code showing first how to cache to the default file system and a more complex example that uses unique caches and page blacklists. Other features planned for the caching tool include edge-side includes, using Twig for templating and statistics recorded to a database.

Lorna Mitchell is back with another post in her "Building a RESTful PHP Server" series today with this new post showing how to work with output handlers (her focus is on JSON).

So far we've covered parsing requests to determine exactly what the user is asking for, and also looked at routing to a controller to obtain the data or perform the action required. This post gives examples of how to return the data to the client in a good way.

She advocates using output handlers instead of the usual views you'd think of in a typical MVCish sort of application. The difference here is that there's not a lot of extra overhead to produce the results - it's literally an output directly from a class extending the base view (including the correct headers). She also briefly mentions the inclusion of JSONP functionality, allowing you to specify a local callback to execute when the request is returned. A few other "nice to haves" are also mentioned like the number of results returned and pagination support.

In a new post to his blog Ilia Alshanetsky takes a look at PHP's output buffering feature and some interesting things he found when testing some recent code (hint: it has to do with PHP's "interesting" management of the buffer).

While profiling our application I came across a a rather strange memory usage by the ob_start() function. We do use ob_start() quite a bit to defer output of data, which is a common thing in many applications. What was unusual is that 16 calls to ob_start() up chewing through almost 700kb of memory, given that the data being buffered rarely exceeds 1-2kb, this was quite unusual.

Through a bit more testing he found that, if a buffer provided for content isn't enough, PHP automatically bumps it up by 10kb each time - a waste of resources if you only need a small subset of that. He includes a small patch he made to the PHP core API that allows for defining a custom buffer size and, if it's not enough, bumps up the buffer size by 1kb instead of 10kb.

On the DeveloperDrive.com site there's a recent post anyone wondering about cross-site scripting should give a read. They introduce you to the basic concept and two things you can do to help prevent them.

This little fable describes the most common vulnerability found in web sites, the Cross Site Scripting (XSS) attack. According to a report from WhiteHat Security 83 percent of websites they tested have had at least one serious vulnerability and 66 percent of all websites with vulnerabilities are susceptible to XSS attacks making it the most common vulnerability web developers face. To fix this, it takes 67 days on average. Tools like WebScarab and Paros Proxy can be used to scan sites for possible vulnerabilities.

They offer two simple pieces of advice that it's all too easy to forget when developing applications - validate all user input to ensure it's what it should be and escape any untrusted output (even sometimes your own!) before pushing it out to the page.

Abou Kone has a recent post to his blog showing the CakePHP users out there how to set up JSON output for your actions in a few simple steps.

Working on setting up the Rest Plugin for CakePHP helped me realize that i wanted to set up JSON output for some of my actions. This way, if you request for example "www.yourapp.com/app/post/view/1.json" in the url, you will be returned the JSON post data. This excellent tutorial here will help you achieve it.

Changes include updates to configuration for routing, using the RequestHandler component and setting your actions to output the data correctly when the ".json" is detected on the request.

Nicolas Grekas has submitted about a new tool he's developed to "represent faithfully any PHP variable as complex as it is" - Patchwork-Doc (related to his Patchwork PHP framework).

The JSON format on which it rests guarantees maximum interoperability while ensuring good readability. The implementation done in the JsonDumper class operates all potentialities of the representation while providing maximum latitude to the developer to exploit its ability as desired, both in term of exposure of internal class mechanism for specialization and in terms of custom use, thanks to the callbacks that allow to intercept the JSON line by line and to adjust the dumping of objects or resources according to their type.

It isn't required to use the framework to use this tool, however. You can see an example of the output format in this example on the project's github page, complete with a guide to some of the advantages and disadvantages of some of the current, more common methods of output. Several types are included in the example including simple string/integer values, objects, classes, stream resources and the results of variable casting.

On the Amazium blog Jeroen Keppens has a recent post looking at some of tools available to you when needing to filter input and escape output in your applications. This post specifically covers filtering on command line applications.

When you need data input in a web context, you send a GET/POST request to your script. On the command line, things work differently. In this blog post, we will talk obout input and output in php-cli.

The post is broken up into a few different sections:

• Handling arguments
• File descriptors
• Interactive input
• Resources mentioned in the post

Tools mentioned include everything from getopt and PEAR's' Console_Getopt out to using file descriptors and working with readline.

Philip Norton has shared a script he's created in a new post today that lets you read from a Netscape-formatted cookie file (as outputted from a curl request).

This file is generated by PHP when it runs CURL (with the appropriate options enabled) and can be used in subsequent CURL calls. This file can be read to see what cookies where created after CURL has finished running. As an example, this is the sort of file that might be created during a typical CURL call.

The file is structured, plain-text content with information on the domain, path, security, name and expiration details of each cookie. His script parses out these details and pushes them into a basic array, prime for searching and sorting (and reuse) in your application.

Sameer Borate has a recent post to his blog looking at an important part of any application - filtering input from the user and output before its used. In his examples he uses a library called Inspekt (from Ed Finkler) to make the job a lot easier.

Most web security glitches are caused by insufficient input filtering and validation. Despite a large number of validation libraries being available, input sanitization is usually bypassed due to sheer laziness or the idea that your site is somehow immune from bad input data. Inspekt is one such library that has a small footprint and is very easy to integrate into your application.

He goes through the installation (a require_once) and a few examples of how to "cage" incoming data from a sample form with two hidden fields. He shows how to use the library to access the filtered versions of the values and how to run some tests on the data (like checks for alphanumeric, valid hostname, between two values, valid phone number, etc). He also briefly mentions "super cages" that can be used over and over.

Dan Horrigan, one of the members of the development team for the Fuel PHP framework has a recent post to his blog of an overview of the the security features of the framework and how it handles things like input and output filtering.

There are many ways to handle security in a web application, and many things to think about. This is by no means an in-depth look on application security. It is meant to be an overview of how to use the security features included in FuelPHP.

The framework lets you set up application-wide input filtering in your configuration file, making it a nice "set it and forget it" kind of thing you don't have to include in each form. There's three types of filtering - xss_clean, htmlentities and strip_tags. For output, he mentions the "e()" method that escapes your output and strips all HTML tags to prevent XSS attacks.