ramblings on PHP, SQL, the web, politics, ultimate frisbee and what else is on in my life
back

One thumb up and two down

Ok, so as the project moves on from our initial issues with Zend Framework we now come to really appreciate the transparent proxy support that Zend_Http_Client offers. A real time saver for us. But after this short praising I must once again get back to complaining about Zend Framework. We ran into a really hard to find bug in the cookie handling of Zend_Http_Client, which has been filed as a bug back in August 2007 against version 1.0.1 (today we are at 1.5.2). More over this is a bug that other similar packages have gotten over in 2004.

Short rambling paragraph: This reminds me again why one-way open source is a bad idea. With this clean IP ho-ha suddenly you have managed to totally forgo the chance to stand on the shoulders of giants. I am convinced that one of the main strengths of MDB2 was the fact that is was build upon the code from PEAR::DB and Metabase. It even took some ideas from ADODB and Creole. Doctrine followed this tradition by being a PHP5 only PDO based fork of MDB2 (would be nice if they could resync with MDB2 some day). So I hope that standing on the shoulders of lawyers is worth the regression bugs (yes I consider it a regression bug if we as an open source community have solved a problem and then someone reinvents the wheel without making sure the old solutions are applied).

Anyways this bug was nasty sneaky enough that it almost killed the project and the much bigger follow up bug. I think this is the first time I needed to debug my web application with wireshark to find out that Zend_Http_Client modified the cookie in an incorrect way (it was calling urlencode() on the cookie value) that I needed to pass along.

The other issue is again with my UTF-16 feed. After some hackery by by Hannes (nice if your boss and project manager can actually code .. envious? .. then apply at Liip for a job) we managed to get things working via file_get_contents().


<?php
/**
 * Decode UTF-16 encoded strings.
 *
 * Can handle both BOM'ed data and un-BOM'ed data.
 * Assumes Big-Endian byte order if no BOM is available.
 *
 * @param   string  $str  UTF-16 encoded data to decode.
 * @return  string  UTF-8 / ISO encoded data.
 * @access  public
 * @version 0.1 / 2005-01-19
 * @author  Rasmus Andersson {@link http://rasmusandersson.se/}
 */
function utf16_decode($str) {
    if(strlen($str) < 2 ) return $str;
    $bom_be = true;
    $c0 = ord($str{0});
    $c1 = ord($str{1});
    if( $c0 == 0xfe && $c1 == 0xff ) { $str = substr($str,2); }
    elseif( $c0 == 0xff && $c1 == 0xfe ) { $str = substr($str,2); $bom_be = false; }
    $len = strlen($str);
    $newstr = '';
    for($i=0;$i<$len;$i+=2) {
        if( $bom_be ) {
            $val = ord($str{$i})   << 4; $val += ord($str{$i+1});
        }
        else {
            $val = ord($str{$i+1}) << 4; $val += ord($str{$i});
        }
        $newstr .= ($val == 0x228) ? "\n" : chr($val);
    }
    return $newstr;
}

$rssURL = 'http://cmo.argus.ch/cmorss/rss.ashx?p1=finanzen&p2=24363';
$rssContent = trim(utf16_decode(file_get_contents($rssURL)));
var_dump(str_replace('encoding="utf-16"', 'encoding="iso-8859-1"', $rssContent));
?>

However if we try to fetch the same feed via Zend_Http_Client (with or without the proxy) the "utf16_decode()" function stumbles. I presume that Zend_Http_Client does some futile encoding juggeling. Finding out whats going on there is my task for tomorrow.

Comments



Re: One thumb up and two down

It would be great if you could repost when you find the new bug, this sounds like an important issue.

Cheers,

DM

Re: One thumb up and two down

I think I will be using this example in my discussions with open source users.... to beware of one-way open source projects, because it leads to developmental regressions.

That said, one thing I don't understand is why people continue to use one-way open source tools when there are other "community open-source" options available (and there are certainly no shortage of options available when it comes to php frameworks!) ? Wouldn't it be better for companies like Liip to speak out against Zend framework, and throw their own development effort (like bug fixing and explaining solutions) into a framework that has more community lead participation?

Re: One thumb up and two down

We at Liip usually don't use "one true framework" for a project. We have our own little framework ( http://okapi.liip.ch/ ), which we use and handles the MVC part and then we add libraries from other "frameworks" as we need them. They usually come from PEAR, ez components or Zend Framework. ezc has the same CLA/one-way issue as Zend Framework and PEAR doesn't have evertything :)

There are certainly many many other php frameworks out there, but we're usually only interested in self-contained libraries for doing eg. Auth, RSS-parsing, ACL, etc.. And then the field gets much smaller.

Why doing it that way and not take one true framework like symfony? Usually something is always wrong with those frameworks, not from a bug perspective, but from the way we work perspective. We like tools, which do it like we want, not the other way round .)

Re: One thumb up and two down

Oh, I am not neccessarily recommending "the one true framework" approach, or you would have seen me say to switch to rails :-) But there are enough other choices (solar, cake, symfoney, etc...) that you could use them when appropriate, and that they are more open to community development would also be more likely to use your feedback as a means of determining community direction.

Before you can post a comment please solve the following captcha.

your name: