The PHP-Security.net site has two posts related to the recently discovered bug in PHP (hence the new versions) related to the CGI handling in certain server configurations.

In the first they detail more of what the bug is, how it could be exploited and link to the original advisory for the problem. Also included are more details on the issue, including sample avenues of attack.

In the second post they look at the recent PHP release and note that it does not completely rid the language of the problem. They point out that the Rewrite rule that's included in their post (not the one on PHP.net) should be used to prevent this issue from effecting your installations.

Gonzalo Ayuso has a new post that can help you protect certain files inside of a public folder by combining mod_rewrite and PHP.

Here's the problem. We have a legacy application (or a WordPress blog for the example) and we want to protect the access to the application according to our corporate single sign on. We can create a plug-in in WordPress to ensure only our single sign-on's session cookie is activated.

In his example, he shows the handling of an uploaded file and a plugin that can be used to protect parts of the site based on session information. Unfortunately, by itself, this doesn't prevent the direct access of the file. His trick is to route all file access back through a central "media.php" script that fetches it from a file location (could even be outside the docroot). The routing to the PHP is handled via mod_rewrite and the code checks the permissions on the current user's session for access.

Brandon Savage has posted another in his series looking at useful tips for working with the Zend Framework. This time he focuses on caching your data to help improve its overall performance.

So, given this performance difference [between static pages and Zend Framework-driven pages], how do we improve the performance of Zend Framework while still retaining its functionality and ease-of-use? Well, we employ caching, of course! But not just any caching. One of the beauties of a read-heavy website, especially one that doesn't change all that often, is that we have the ability to cache entire pages and serve them directly using our web server.

He shows how to use the Zend_Cache component to create a simple caching object tat allows you to cache the entire page contents and, with the help of a little mod_rewrite trickery, tell Apache how to grab them (or regenerate them if need be).

From the ImproveSpeed.info blog there's a recent post about a quick way you can speed up your WordPress site (especially one that gets a higher load) by making some modifications to your .htaccess file.

It is known the importance of the page loading speed over the traffic of your blog. Recently there were a lot of discussions and probably the page loading speed will become an important SEO factor for google and other search engines. The main problem with the existing .htaccess file is that the RewriteCond directives checks the existence of a file on disk when it is not really required. Each access to disk increase the page loading time.

They show how to take the stock .htaccess configuration and modify it (still using mod_rewrite rules) to get a bit more fine-grained in the filtering of how requests are handled, things like having the index.php requests are forwarded automatically on or not caring about images or CSS.

This new tutorial from NETTUTS.com (by Joseph Pecoraro) takes a more detailed look at the mod_rewrite module for Apache and shows how it can work with PHP to grab information directly from the URL.

When people think of .htaccess configuration the first thing that pops into most people's minds is URL manipulation with mod_rewrite. People typically get frustrated with mod_rewrite's complexity. This tutorial will walk you through everything you need to know for the most mod_rewrite tasks.

He looks briefly at what the module is, what it can let you do and how to get it up and running on your web server instance. For his purposes, he puts his rewrite rules into an .htaccess file in the project's directory for easy updating (as opposed to part of the main Apache config files). He gives several examples of pattern matching and regular expressions to take the given URL and massage it into something else. A PHP example shows how to grab the rewritten information from the URL and put it into an example page.

As a part of his work being done on the WinPHP Challenge, Rob Allen has done some work with routing and Microsoft's IIS7 web server.

I've already covered the Sqlsrv adapter, so let's look at rewriting requests with IIS7's URL Rewrite module. As with everything in IIS, you get at this tool via the IIS Manager GUI. Be aware though that the Url Rewrite icon is available at server level and at the website level.

The module allows you to define rules similar to mod_rewrite with Apache and even lets you import them from a current installation. The "Import Rules" panel lets you either specify a configuration file to pull from or lets you cut and paste the rules in for import (as seen here).

Stefan Koopmanschap has a recent post to his blog about a small oversight (and gotcha other symfony developers should watch for) that he's made a few times when trying to work with a subdomain of his main symfony-powered website:

Quite often have I been staring at my virtualhost setup for the admin subdomain of this application, wondering why the hell it kept serving the frontend. I'd set the DirectoryIndex to backend.php, so why did it keep serving the frontend?

The culprit was something that's usually one of the first things set up when you load a new framework - the mod_rewrite rules in an .htaccess. Of course, since they were the default, things would get routed back to "index.php" instead of his "backend.php" as he wanted. To fix it, he moved these options out of the .htaccess and into the virtualhost configuration.

If you've a blogger and you've been thinking about moving platforms (say from MovableType to WordPress) you mightwant to check out this new blog post from Maggie Nelson about her experience switching between the two.

It's been a while [since I last tried WordPress] and things seem to have improved - some within WordPress itself, but others due to the help of the community which has provided tons of plugins that can help WordPress get around some of its problems. The move from MovableType to WordPress was easy. WordPress has import functionality that plays very nicely with MovableType's exported files. Yay!

Her only problem was making sure that references to the site weren't broken. She made the move away from her old domain to a new one (maggienelson.com) and needed to set up some redirects to bridge the gap. The mod_rewrite module of Apache made things relatively simple. All of her rules (including the ones in the path she took to get to the file result) are included in the post.

Kae Verens has posted a quick tutorial about serving up files by routing them through a "fetch" script, pulling their contents in one side and back out the other.

One thing I need to do while building the multi-user version of webme is to convert it so file references such as /f/photos/an_image.jpg get transparently converted so they serve correctly, even though the actual file may be located somewhere entirely else.

There's two steps involved - rewriting the URL request for the types of files you'd like to pull through the script (using some mod_rewrite magic in Apache) and make the script to do the actual work. Source for that is included too. Not only can something like this help you keep things organized but it also allows for extra security if you need to store the files outside of the webserver's document root.

Brett send in a link to a new post on his "Mr PHP" blog about a method he's come up with to cache images using the phpThumb library.

Generate thumbs by visiting a URL such as your.com/thumbs/images/image.50x50.jpg. This will create a 50x50px thumbnail of your.com/images/image.jpg. The thumb will be stored on your server at your.com/thumbs/images/image.50x50.jpg so the next request for the same image will be loaded without loading php for ultra fast image cache.

The phpThumb tool lets you dynamically resize an image and, if one does not exist for it, make a thumbnail that's output and cached. From then on the script just pulls from that local copy. He includes his code to get it working and the mod_rewrite rule that maps an image request back to it (so it's still "/images/myimage.jpg" instead of "/app/phpThumb.php?src=myimage.jpg&w=100&h=100" in the img src).