Remote attackers might be able to exploit these issues in PHP applications making use of the affected functions, potentially resulting in the execution of arbitrary code, Denial of Service, execution of scripted contents in the context of the affected site, security bypass or information leak.

On the right hand side, we have HTTP_RAW_POST_DATA bug in PHP 5.2.2.

So $GLOBALS['HTTP_RAW_POST_DATA'] is not set. The PEAR::XML_RPC package actually uses $HTTP_RAW_POST_DATA on the receiving end, but that doesn’t appear to be set either. And the always_populate_raw_post_data option in php.ini doesn’t make a difference.

That means, any PHP code that assumes the existence of $HTTP_RAW_POST_DATA will simply fail as that variable is no longer populated. With all the API, web services, etc, there are actually many applications that use raw post data, which could be XML, JSON, or any other package formats. Pingbacks simply won’t work in WordPress, although WP 2.2 has a work around on this PHP 5.2.2 bug.

So I basically upgraded all my servers to PHP 5.2.2 early last week. found many web services code I wrote were broken, and was forced to revert back to vulnerable PHP 5.2.1. The bug has been fixed and there’s a work around, but I would rather wait for 5.2.3 to hit the street, which I hope to be sooner than later.

Well. The bug has been fixed now, and it is now 0.6.2. Go and download it if you are using WP2.1′s new feature.

Thanks to Brian for pointing it out.

• Django is fast, and can be very light on memory as well.
• RoR 1.1.6 is significantly faster than 1.2.1, which was a bit disappointing.
• PHP frameworks can be very slow, unless a opcode cache is used.
• Symfony is way too complex and too slow.

Alright, I guess after all performance is only half the story, and I am pretty sure the RoR guys are willing to trade performance with speed of development. Lucky for the Python guys that they can have both.

Some of my thoughts:

• I won’t say it represents the “big picture”. Ohloh is only indexing open source projects from major source code forges, and 3,000 projects certainly sound small in comparison to the scope of open source world.

  Moreover, Ohloh indexing on the open source projects that they have access to, and proprietary software is yet another world. Majority of SaaS/ASP projects never release their source code, even though they are popping up all over the place because of this Web 2.0 boom. Many are developed using open source languages and frameworks.

  Stating “PHP Eats Rails for Breakfast” is far away from truth.

• PHP is a language, but most, if not all open source projects are for the web. Rails is a framework, but there are many Ruby projects that (1) don’t depend on Rails (2) aren’t serving the web. And the world is more than just the web.

  I think it somehow affects the last graph which shows the number of new projects. I have seen quite a few useful Ruby apps that have nothing to do with Rails, runs from the command line, and are small because of expressiveness of Ruby.

• Another interesting observation from that graph is, number of new projects in Ruby actually surpasses all the P’s (Python, PHP and Perl) at around the same time between 2003 and 2004, if I am reading the graph correctly. But DHH did not even release the first public version of RoR until mid 2004, which arguably was the push that created the momentum behind Ruby today.

  Hmm. I am confused. So there are already more new projects done in Ruby before Rails was announced?

• Looks like the real looser here is Perl. How come no one is talking about it?

The bottom line is, the data revealed in the comparison does not really prove what its title has suggested. What people put on SourceForge also does not tell us what the world is using, especially when a lot of software has moved to SaaS model.

I have also added gravatar onto the comments section of FuCoder.com, utilising the gravatar cache. Cache is served from another server — not DreamHost but a VPS I rented from unixshell# running Gentoo + lighttpd. We’ll see how it goes.

…all the PHP code I’ve seen in that experience has been messy, unmaintainable crap. Spaghetti SQL wrapped in spaghetti PHP wrapped in spaghetti HTML, replicated in slightly-varying form in dozens of places.

I have seen some well designed PHP code, but generally Tim’s observation stands valid.

The problem is more than wild spread of spaghetti PHP code found in many open source applications. Programs are bounded to be a mess if they are not designed, but were hacked together by non-programmers trying to quickly (and often temporarily) fill his/her needs. Nothing wrong with that — you can write spaghetti code in every language of your choice (debugging spaghetti Python is part of my daily job). In fact it might be a compliment to PHP as it is just so easy to get up and running. Even a non-programmer can add a bit of “dynamics” to his/her own website, without begging/paying the professionals.

Things only get messy when your temporary “Hello World” application starts to need database support, need to manage large XML documents, need to talk in different charsets, and need to scale to hundreds of requests per second.

However, what I see the fundamental problem of PHP is not that there are zillions lines of messy code out there, but the language itself. Scanning through Tim’s comment list, two other posts caught my eyes.

First of all, Jonas Maurus wrote “PHP sucks”. It’s a bit technical, but I very much agree with what he has said. There are simply too many “warts” in PHP-land that can catch even a seasoned developer by surprise. For example the pass by reference difference between PHP4 and PHP5, and you usually need to use === (3 equal signs) to correctly validate the value as boolean false.

Another nice write up about PHP language comes from Aristotle Pagaltzis — “Why PHP is good but bad“. I especially agree with the point “The easy, obvious way to do things is often the incorrect one”.

There are lots of tutorials which will either not tell you to quote user input before interpolating it into SQL statements at all, or tell you to use addslashes for the purpose. In either case you are open to injection attacks — either gaping wide or just wide…

What annoys me is, there are way too many PHP programmers (who probably have no other SQL experience) automatically assume ‘addslashes‘ with escaping in SQL string literal, and subsequently think that they are safe from SQL injection by adding slashes everywhere in their SQL concatenations. Related “magic quote” that gets applied to all incoming GET/POST/Cookie data also does more voodoo than good.

And Aristotle concluded the problem with PHP:

… the morass is simply the result of the language being a templating system that grew too big for its breeches. I don.t believe the problems can be corrected in any sensible fashion; PHP will always be a templating system, however much it may be straining against its clothes.

Yes — it was initially designed as a template language that grew out from Perl CGI scripts. New functions were added onto a flat name space so they can be easily called from inside the templates. It is working hard to become a full object oriented language itself, but the baggage was still very visible.

On the other hand, you have Harry Fuecks having his pro-PHP rant. “Shared nothing” has been one of his main argument why PHP is scalable. And it works — with Apache and mod_php — as the web development platform it was designed to be.

“Shared nothing” being scalable is quite arguable, and I believe it really depends on the application. Your clusters of Apache/PHP nodes pushes all states into database assuming that the DB is going to scale — that is a very big assumption. It only really works with applications with far more reading than writing, where you can easily set up clusters of slave DBs. But heh, it covers most of the “Web 2.0″ style of applications and I guess that’s what they care.

Moreover, “shared nothing” is a design philosophy that is not unique to PHP. I can have my JSP or Django with FastCGI, etc application that does exactly the same thing. Now, with other applications where a per-process in-memory cache would be very useful, what option do I have with PHP? Most caching options I have seen rely on external processes or external storage.

The rest of Harry’s article talks about how PHP plays catching up — generic database support (I was using Perl DBI in 1997), SPL (how long have we had STL?), XML (finally!), Unicode (finally 2!), etc.

Language wise, I do not think PHP’s Schwarz is bigger. It is getting there, but I’ll rather code in Python or Ruby than PHP. The only redeeming value I see in PHP is — it works (most of the time). Thanks to mod_php that gets installed almost everywhere (and becoming a resource hog with Apache’s prefork MPM), your PHP application is most likely to run in the $10/month budget shared hosts.

Yahoo‘s PHP development centre has just gone live. It is not hard to see that PHP has got Yahoo as its backing. Well, they have Rasmus — maybe that’s why. At the same time, Google has got Guido. Interesting competition ahead :)

Here’s what I propose: screw Web frameworks for now. We won’t win in the Rails generation… For today, let’s work on making generic Python products. Let’s make a kick-ass community forums system, an incredible blogging system, a news script, a CPanel/Webmin clone that people will use because of their features, not their programming language.

However, when you look around searching for re-usable open source web applications, what do you see? PHP applications. When you go to open source application directories like OpenSourceCMS, most the apps (if not all) listed in there are written in PHP.

To me, PHP provides a gentler learning curve — you can easily add PHP tags to existing static HTML files to create dynamic sites. But so is many other Python-based template engines (like Spyce). The language itself is only so-so — Perl’ish, and probably has many more warts than Python, even in its current object-oriented incarnation. I do not think it is as attractive to the developers as 5 years ago when LAMP(HP) was the buzzword. However, PHP-developed applications still rule the market of cheap-ass shared hosting. Why?

Ease of deployment.

Peter said in his post:

And, most importantly, let’s all get behind what I believe is the most pressing and important concept in the Python web development world today: Paste Deploy. What Python needs more than anything is a brainless, quick-and-easy way of connecting applications to gateways.

WordPress guys are proud of their famous 5 minute install. Not just WordPress, there is simply “no step 3″ in many PHP application installations. You upload files into your web-root, point the browser to install.php, and then just follow the steps to set up database, create configuration, initialise super user, etc. There is no need to compile your own Python executable to install easy install so you can download eggs to power your supa-dupa forum application downloaded from sourceforge…

But how do you get ease of deployment? I have no experience with Paste before, so I briefly looked at the Deployment documentation. While it looks very promising, its installation goes like this:

sudo easy_install.py PasteDeploy

Aargh! It seems for those do no think paying for dedicated server or VPS is justifiable, they can only rely on their web hosts to install those libraries for them. Most hosting customers won’t have a clue on compiling their own Python, and it is unlikely that hosting companies will have every possible egg installed, unless there’s enough demand. There will not be demands unless there are enough compelling Python web applications. However, sometimes even a seasoned Python developer will choose to develop his next re-usable killer app in PHP, if he knows how difficult it will be to deploy…

At the end a good framework still matters. Ease of deployment is crucial, but is also a vicious cycle that needs some momentum to break out. RoR has that momentum — look at how many shared hosts are now claiming their support of RoR deployments. We only wish the same can be said about Django and TurboGears.

From this comment, Quercus (the PHP module for Resin application server) actually implemented most of the PHP API’s (which is massive) to provide compatibility, and even their own Mantis bug tracker, an open source PHP app, is now running on their Java platform.

Nice!

I guess it would be more of a threat to other PHP accelerators like PHPA and Zend. PHP’s poor performance is obvious in large applications — every script is parsed and compiled everytime it is executed, and many of those accelerators provide nothing but bytecode cache to save on the parsing and compilation time. Now there’s another platform that does on-demand compilation.

However, I guess it is more than just caching the bytecode. What makes PHP on Java fast is actually the VM itself. We cannot deny that JVM is probably one of the fastest and most well-optimised VM out there, and JVM bytecodes are usually dynamically compiled into native code in JIT. The same can be said about the .NET’s CLR — a well optimised VM can sometimes run close to native code speed.

Therefore sometimes I wonder whether it is a better idea to compile your language as bytecode to run on a well-optimised VM, than spend time coding the actual virtual machine to run your intepreted scripting language. As a Python programmer (not yet a hyper-enthusiasts), I am interested in projects like PyPy, Jython and IronPython that might eventually and constantly out-perform CPython.

Interesting description about Java:

Java is much more programmer-friendly than C or C++, or was for a few years there until they made just as complicated. It’s become arguably even harder to learn than C++…

How true! Java, the language itself, is simple and easy to understand — at least the first few incarnation of it. However, over the years when the standard JDK gets bigger and bigger to download, the built-in libraries gets incredibly huge, and just the sheer complexity to set up a J2EE server. It has turned itself into a beast now, and no one now can claim that he knows the “Java API”. Which one? You ask.

Or maybe it is just me who cannot get my head wrapped around Java. Used to make my living in Java 5 years ago, but am too scared to touch it now.

PHP is certainly easier to use, and much faster to develop a site with. The language itself left a lot to be desired, and even with PHP 5.1, it still feels like some ex-Perl scripts hacked together templating HTML files. I guess the evil of “backward compatibility” has somehow hindered how the language can evolve. But that’s not the point — it is simple. It gets the job done.

People might think that scripting language without n-tier application server architecture is not scalable (can we say IBM? thou some might beg to differ). Even Andreessen himself would have his Java application server clusters behind the PHP web server layer.

But that’s not the point. Why would “scalability” be important anyway? At least not in this Bubble 2.0 Web 2.0 world. You just need to have some nifty idea, quickly build the app, make sure it is buzzword compliant, be the first on the market and hope the VC will knock on your door.

Still implementing your J2EE solution? You might finish when Burst 2.0 arrives. Give PHP, Python or the Rails a try instead.

The latest version of PHP XML-RPC is already available, and you can also use:

# pear clear-cache
# pear upgrade XML_RPC

to update PEAR automatically. However, there are many hosts out, who do not follow security news closely, will not update the PEAR library for you. There are also versions of PHP XML-RPC libraries bundled with other existing applications that will not be updated, unless you also manually upgrade the whole package. As this vulnerability is serious – an attacker can insert arbitary PHP code which can easily lead to compromise of the whole system – I can smell the storm coming.

By the way, it has little to do with WordPress 1.5.1.3 security fix. While both are related to XML-RPC calls, they are actually quite independent patches. WordPress’ issue is to do with not escaping the incoming data properly, which might result SQL injection. While all security bugs are bad, I reckon a SQL injection is not as easy to exploit as PHP code injection. Still, please upgrade your WordPress version.

And WordPress team still have not fixed the backslash issue in XML-RPC calls. Eagerly waiting for 1.5.1.4…

Update: Matt M addressed the potentially confused Slashdot crowd that the recent WordPress patch has little to do with XML-RPC vulnerability previously discovered, probably taken from someone’s suggestion.