The PHP.net site as new post with some supplemental information for those users of the PHP CGI that might be effected by the recently announced bug, the reason for the most recent release. Unfortunately, this patch only fixes some of the cases of the problem, so they've amended their instructions to included a more effective mod_rewrite rule to help protect your applications.

PHP 5.3.12/5.4.2 do not fix all variations of the CGI issues described in CVE-2012-1823. It has also come to our attention that some sites use an insecure cgiwrapper script to run PHP. These scripts will use $* instead of "$@" to pass parameters to php-cgi which causes a number of issues. Again, people using mod_php or php-fpm are not affected.

The rewrite rule is there in the post, ready for copy and pasting into your config. Even if you're running the latest PHP 5.3.12 and 5.4.2., be sure to use this rule as a stop-gap measure for now. Another release is planned for tomorrow to fully correct the CGI flaw.

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.

In this new post to his blog Gaurish Patil shows users of the Yii framework how they can update their configuration settings to hide the "index.php" in their requests and make cleaner URLs.

Finally we figure out the basics of Yii. While working on basic of Yii, I want to rewrite the url to SEO friendly. So I started to search on google, forum got useful information here http://www.yiiframework.com/doc/guide/1.1/en/topics.url To hide the index.php from url I did changes in config/main.php [...] and I created new .htaccess file in the same directory as my index.php file.

The changes are pretty simple - it's mostly a change to the "urlManager" setting to provide some rules for mapping controller and actions to the right place. The .htaccess file uses Apache's mod_rewrite functionality to grab the requested URL and remap it back to lay on top of the "index.php" front controller for the request.

In a recent post to his site Keith Casey mentions something that should be obvious to most software developers (and managers of developers out there) but is easy to forget - technical debt doesn't just disappear, even if the related resources change dramatically.

Just because you set a codebase aside and do it the "right" way, your problems don't disappear. The same bugs that annoyed people yesterday will be there today and tomorrow. In fact, when the bugs are still there a week, month, or year from now, they move beyond annoyances and into frustrations as people think (or say) things like "this has been broken for years.. why haven't they fixed it!?"

He notes that, while tossing the entire codebase out the window and starting over again (a move very, very rarely shown a good idea), you'll still end up with issues - this time involving resources and the work needed to sift through all of the bugs in the new code.

On his PHP Genious blog Timir Shah has written up a new post looking at how you can configure URL rewriting (much like mod_rewrite) in an IIS7 web server running PHP applications.

Few days ago, I faced a URL rewriting problem on windows server. After checking the server configuration, I found that there is an II7 installed. After long research about this, I found that II7 is not support .HTACCESS. If youwant to male your site SEO URL friendly, then you have to use web.config file for URL rewriting instead of .HTACCESS. Now the question is how to make web.config file from .HTACCESS?

He compares the two formats, showing how different directives from the .htaccess file can be translated over. He starts with an example of default documents on either side - the .htaccess defining several "php_value" settings and the web.config setting some default routing and rewrite rules. He shows how to set up a few things on each side - error page redirects and setting up some custom URL rewrite rules for both sides (with examples).

In response to an announcement made by the phpBB group at the just-passed Symfony Live event about considerations being made to change the base platform to Symfony, Stefan Koopmanschap has posted an open letter to the phpBB community and development group with his thoughts on the potential move.

The past week was the week of Symfony Live 2010 in Paris. One of the people there was Nils Adermann, the new Lead Developer of the phpBB project. The biggest news was that phpBB is considering moving to Symfony 2 as the basis of their new version of phpBB: phpBB4.

There's an RFC posted for anyone that would like to reply back to the idea. In Stefan's response he mentions things that would be positive about the decision like not having to reinvent the wheel, getting the support of the pre-established Symfony community, making it easier to extend phpBB via Symfony code and a certain sense of security that comes with having the framework backing.

According to this new article from the Software Development Times Facebook has rewritten the PHP runtime from scratch and will be releasing it soon as an open source project.

So, why has Facebook rewritten the PHP runtime? Because PHP is obviously too slow for their tastes. A few years ago, I had a coffee meeting with some of the folks from Zend. When they asked what I had been hearing about PHP in the market from my sources, I hemmed and hawed, then told them that I had heard people complaining about how slow PHP was.

Other sources suggest the release won't be a full runtime but instead a sort of compiler for PHP applications including an interview with a Facebook employee who drops a hint about their future plans for the language.

Rob Allen has posted a look URL rewriting in IIS 6 (similar to mod_rewrite in Apache) without the URL_Rewrite module that comes with IIS7.

IIS6, which ships with Windows Server 2003 does not have this module though and guess which version my client's IT dept run? As usual, they wouldn't install ISAPI_Rewrite or one of the other solutions for me. In the past, I've simply written a new router that creates URLs with normal GET variables, but this is ugly and I wanted better. One thing IIS6 does let you do is configure a URL to be called upon a 404 error, which then allows you to have "pretty" URLs and be able to route them.

He walks you through the setup of the manager to create this 404 routing setup allowing a single script (an index.php) that uses an instance of the Zend_Controller_Request_Http component to grab the request and forward the page back out to the user's desired location.

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.

In this new post from Chris Hartjes today he continues his look at combining a CakePHP application with the Nginx web server. This time the focus is on the configuration of the web server side of things to make the CakePHP routing work.

I'm in the process of creating the website for my upcoming book *and* had recently switched back from using Apache to using Nginx again, so I thought it might be time to roll up my sleeves and figure out how to make it work in a subdirectory. After much gnashing of teeth and pissing and moaning, I figured it out.

A simple configuration example is included as a part of the post showing how to correctly configure the rewrite routes to catch everything and send it back to the index.php file. His is a two-part process: it tries to match anything with "/foo" in it then, if it wasn't caught there, it sends it off to be rerouted to the front controller.