There and Back Again

HTML_AJAX 0.3.0 Released and new Website

HTML_AJAX 0.3.0 is huge leap forward from the previous versions, although it still remains mostly backward compatible with earlier releases. Currently the only change in API occurs in Main.js – some event handlers were colliding so name changes were made. The effected methods are onOpen -> Open, onLoad -> Load, onProgress -> Progress, onSend -> Send. This shouldn’t affect too much code.

One of the most important and exciting changes with HTML_AJAX 0.3.0 is the addition of three new developers who have been putting a lot of time into the project. They totally eradicated every item on the original todo list, and the feature roadmap has jumped ahead.

There are considerable improvements in the behind the scenes code. Using the new HTTP client pooling reuses XMLHttpRequest? clients, giving you a speed up when making lots of requests. This is especially useful for IE, where activex object creation can really slow things down. The new priority queue allows you to make many requests and tag the ones that are more important to be sure they are executed first. HTML_AJAX_Util received several bugfixes and new methods to make debugging javascript a little easier, including a varDump() and getType(). As the code base grows, both in javascript files and in php files, some minor rearranging has been done as well.

On the user end, there are several new serializers to use – you don’t have to be limited to just JSON, Error or NULL. Now you can use php based serialization, url encoding serialization, or HTML_AJAX_Action – which eliminates the need to write client side javascript to handle the data returned from ajax callbacks. There were several bugs fixed – most importantly was a huge bug in Opera and the way it handles unknown Content-Types – it seems to translate them to binary so a workaround was needed.

The examples directory has some great new code to show the power and flexibility that HTML_AJAX can provide in applications. There’s still a lot to do, just take a look at the roadmap, but with this release a huge amount has been accomplished.

As always were still looking for new people to help out. People willing to put time in testing and supply bug fixes for there browser of choice would be especially helpful. It doesn’t take a lot of time unless your favorite browser is horribly broken, but the through testing makes a huge quality difference.

You can upgrade your install as always using the pear installer. If your looking for a full changelog you’ll want to check out our new wiki.

The couple pages of docs I’ve had here on my blog are moving there. Were using yawiki from Paul M Jones, and aside from a couple minor points its been great to work with.

3 thoughts on “HTML_AJAX 0.3.0 Released and new Website

  1. Harry Fuecks

    Cool to see HTML_Ajax is moving along. Would strongly recommend taking a close look at that PHP serializer though. There’s two problems I can see with the current implementation.

    First Javascript has a different concept of string length, being smarter than PHP in that area. What it means is if people attempt to send multi byte characters from Javascript to PHP, they will get errors from PHP’s unserialize. I described the problem a little here: http://www.sitepoint.com/blogs/2004/10/31/how-long-is-a-piece-of-string/ – in JPSpan finally gave up on trying to support multibyte charaters via this approach, warned people off and had the PHP serializer strip anything non-ASCII. See the encodeString function here: http://cvs.sourceforge.net/viewcvs.py/jpspan/jpspan/JPSpan/js/encode/php.js?view=markup

    Second and more serious is, on the PHP side it’s blindly unserializing whatever it receives. Where that’s a problem is someone could “inject” class names via the serialized string and PHP’s unserialize will create an object from them, meaning the class constructor get’s executed.

    Whether that’s a danger is will depend on the class itself – in PHP4 the risk / impact is probably quite low. You also can’t pass arguments to the constructor. But in PHP5, where there are now alot of built-in classes registered by default, the chances of finding something where the constructor is “dangerous” is much higher plus autoload potentially widens the net.

    Described that problem here http://www.php.net/manual/en/function.unserialize.php#45503 along with solution that pulls out class names from a serialized string which hasn’t yet been unserialized. You’ll find unit tests for that function in the “TestOfJPSpan_Unserializer_PHP_getClasses” class here: http://cvs.sourceforge.net/viewcvs.py/jpspan/jpspan/tests/php/unserializer_php.test.php?view=auto

  2. Joshua Eichorn Post author

    Thanks for the code examples, i actually had it on my list to look at those problems, I just haven’t had the chance to do it yet.

    I’ll point this info to the guys who are working with the php Serializer. I think we also need to detect the versions of php with exploitable bugs in unserialize and refuse to run.

  3. Pingback: SitePoint Blogs » unserialize Yahoo! search results