Abhinav Singh has posted a guide to PHP extensions - what they are and how to write a simple "hello world" one.

Assuming you have read the previous post, lets discuss on how to build our first PHP extension: every PHP extension is built out of minimum of 2 files, a configuration file (config.m4) which tells us what files to build and what external libraries are needed and source File(s) which will contain the actual functionality.

He builds up an example skeleton for an extension (the config.m4) and explains how the file will be phpized and configured. Next up is the php_sample.h header file where the needed modules are loaded and the sample.c file to define them. Last, but not least, comes the extension code itself that calls the printf function to output the "hello world" message.

Brian Snugg has two new posts relating to his script for a reverse proxy in PHP5. The first lays the foundation, the second makes some updates to make it a bit more efficient.

So I have been working on a little class to run a reverse proxy from PHP using cURL. I have extended this class for my own purposes (single-sign-on) to handle some special request parameters, but here it is. It has some warts, but it's a good starting point.

He creates the ProxyHandler class in the first post and in the second updates the script to pass a more correct version of the headers to the proxy server to get a better response back.

Kris Jordan recently posted five tips to help you get a "more correct" REST interface in your application.

As we entered a programmable web of applications with APIs the decision to ignore HTTP gave us problems we're still dealing with today. We have an internet full of applications with different interfaces (GET /user/1/delete vs. POST /user/delete {id=1}). With REST we can say /user/1 is a resource and use the HTTP DELETE verb to delete it.

Here's the five (six?) tips:

• Using PUT and DELETE methods
• Send Custom HTTP/1.1 Headers
• Send Meaningful HTTP Headers
• Don't Use $_SESSION
• Test with cURL or rest-client
• Use a RESTful PHP Framework

On the Tillate Blog today there's a new post from Leo looking at how you can give clients back the control on when your cache refreshes.

We worked hard on the right caching strategy over months now. But there are still caches that do not get invalidated right or are cached too long and we still get complaints from our users. So we decided to integrate a feature that allows certain users to invalidate the cache on the server side. The first idea was to add a link to every page that will append a GET-parameter to the site and then avoid the cache.

He used the apache_request_header function to get the current request's headers and noticed that they included a cache-control header. By changing up this on the client-side, it allows the site visitor to "force" an update to the information if your application pays attention to it.

In a recent post to his blog Daniel Cousineau shows a method for correctly outputting CSV data in push down to the client browser as a method of export.

Nearly every application you could write in for the business sphere in PHP probably requires some sort of data export, most likely in the CSV format. The easiest way to provide a downloadable file is by altering the headers and echo'ing the file content.

His method sets the headers for the CSV file type then pushes the content out (contained in an array) via the fputcsv function. He wraps it all in a function near the end for simple cut and paste.

Jani Hartikainen has posted a quick tip for Zend Framework users out there looking to force a download from their script.

"How do I make a file downloadable through my script?" This seems to be a relatively common question on #zftalk nowadays, so here's a quick wrapup!

He compares the two ways - the usual PHP-only way of using header() calls and echoing out the file versus the more Zend Framework way - using a Response object to pull in the content, set the headers and a helper to display/render the data output.

Kevin Waterson has posted a new article to his site today - an introductory look at security in your PHP applications.

One of the great benefits of PHP is its ease of access to new-comers. Its entry level is minimal and so attracts those looking for simple scripts to their sites. It is this same ease of access that becomes a problem as the new-comers begin to deal with input from users. Failure to adequately validate and sanitize data is the leading cause of security problems when dealing with PHP.

He looks at a few different areas that developers need to focus on (and be sure to filter on) like PHP_SELF, protection from email header injections, file inclusion and the use of error reporting to make handling user-generated errors "more correct".

DevShed has the second of a two part tutorial posted today on sending emails with the included mail() function.

In this article we will look at the protocol that is involved in sending email messages. We will also examine the thorny issue of how to send an attachment with an email message. This article is the second of two parts.

They include examples of sending simple messages and more complex ones with things like attachments and custom headers. They also tack on a look at the PEAR::Mail package to the end showing how it can make sending some things a little less painful.

A pretty cool project in PHP - Memproxy is a caching proxy "server" that uses memcached for storing the cache. This project uses PHP scripts to handle caching using memcache.

The server uses memcached to store the information and automatically manages things like TTL, custom headers and is "application agnostic" all wrapped up in a small codebase with minimal dependencies.

Matthew Turland has come across an "interesting bug" in PHP's stream wrappers functionality - some strange 404 or 500 HTTP errors in one of his scripts.

I wrote a small script a while back that's gained a surprising amount of popularity thanks to a plug from the site that it posts to. [...] I learned that this [connection from the script] could be done with streams, I attempted to implement it in that fashion, but ran into strange issues where I would get 404 or 500-level HTTP errors rather than the response I was expected.

He eventually found the bug related to his problem (in the 5.2.x branch) but happily notes that it has been corrected and will be patched in the upcoming 5.3 (and 6) branches.