Coming back from some previous comments about the Zend_Http_Client in the Zend Framework, Lukas Smith admits that a certain feature has come in handy with their development, but another bug has come up that has gotten under his skin - a problem with the component's cookie handling.

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.

He had to use wireshark to finally track down the culprit - a call to urlencode on the contents of the cookie before sending it. He also includes some code to overcome a problem he had with UTF-16 in one of his feeds (a custom function that takes in and returns a string translated correctly).

Christopher Kunz has shared about a resource he came across that offers complete PHP encoding for a much lower price than some of the other services - phpshield.com. It seems a little too good to be true, though:

However, the phpShield.com home page did not offer the slightest clue who actually is behind that product. [...] It's common practice to whitelabel your solutions and sell them under different brands with different feature sets to different target audiences. However, we always clearly state who is behind the whitelabelled solution.

A little more digging shows an interesting relationship between the company that sells SourceGuardian and the company behind this PHPShield (Inovica). He sees the deception counting against the company and has just "struck one off the list" from his search for encoding methods.

Davey Shafik has done a mini-review comparing the Zend Guard software with a similar offering from IonCube, IonCube Encoder to help protect your PHP applications.

For the last several years, we have been successfully using the IonCube PHP encoder. It works well, providing us with as secure a solution as we could wish for, for our code. [...] Due to the amount of head pounding involved in finding this issue [where IonCube was removing a valid logic branch], I started to consider using Zend Guard instead, figuring that Zend has far more resources and more experience in this arena, we might see less issues.

He details their upgrade process including comments on the included GUI and how it "just works" (once it's set up)

In dealing with a little JSON encoding and objects in a project of his recently, Cal Evans bumped against a problem when he was encoding an object and moving it back and forth between the back and front ends.

The problem is simple, JSON encode a PHP object and send it back to the front end. Sounds simple and the last 100 times I wrote this code it was simple. This time, I was too smart for my own good. Here's the scenario.

He illustrates his problem - the "dropping" of properties somewhere along the way - with a sample class that encodes the object and sends it along. He missed one key bit of information, though. His protected array of properties wasn't getting passed back out correctly and we're in the resulting JSON message. A quick hack of a getProperties() function call made this problem a thing of the past.

The PHP Web Services blog has a helpful hint on getting a custom SOAP request all ready to go:

How do you get this [custom] XML to be output by the SoapClient?

Using the SoapVar method and a few newly created objects, making a custom structure is simple. It's just a matter of encoding the object and setting it with the base() method in the PHP SOAP extension. Check out the blog post for an example of both the custom XML and the code to produce it.

On the ProDevTips site, Henrik has pointed out a handy application that can make HTML encoding characters outside the norm in PHP simple.

The standard htmlentities() function will encode special characters so that they display OK in the browser. However, sometimes you might want to encode different languages to entities too. I just found a script that will do that in the form of an html encode application.

He includes an example showing how to encode a string of non-english characters out to an easy-to-display HTMLified string.

PHPBuilder.com has a new article by Hillel Aftel about his method of choice for securing the data that you send over the GET string when moving things around on your site.

In this article I'm going to show you how you can use PHP to encode your data for transit. Most importantly, it will be done in a way that makes the data decodable, and therefore much more usable, by the receiving page.

His encryption method - sending everything in a single string and modifying the scheme each time - uses static pairs of values (of your choosing) to "encode" the outgoing string. It actually consists of three different files: the script itself, a single-use script that makes the third file, an include file to handle the conversion back from the encoded results.

Stefan Esser has posted about the release of the latest version of the Suhosin security patch for PHP - version 0.9.21.

It has been a very long time since the last Suhosin extension has been released, but today this has changed with the release of Suhosin 0.9.21. Among the changes are two new features that will protect applications that put to much trust into the SERVER variables from several XSS (and SQL injection) attacks. These features are suhosin.server.strip and suhosin.server.encode.

He details these two features and gives examples of what they protect from. You can find out more about the Suhosin patch on its website.

In a new post to his blog, Chris Hartjes, spurred on by an article in the latest edition of php|architect magazine (covering protecting your code), has shared a few opinions starting with a certain paragraph near the end.

To start, I will focus on the paragraph above. What I get out of that is that if only your source was closed and hidden from prying eyes, it would not have bugs in it. Which is, of course, total nonsense. Code has bugs because it's open and they feel safer? There are two kinds of bugs: application bugs (which is the code I would write) and system bugs (in this case, bugs that that appear from PHP itself). I'm sorry, but there is nothing I can do if there is a bug in PHP that causes my application to crash except to point this bug out to the people who have the ability to fix it.

He goes on to talk more about how protection like this (the article talks about using the IonCube Encoder) will not stop someone if they're really determine to get at the code underneath the encryption. His only suggestion is to make an application good enough that people wouldn't want to try to steal it as much and would rather pay for their version.

Encode your stuff if you want, but be aware that the minute you choose to do that you are telling your customers "I don't trust you" and I have a hard time understanding a business model that assumes people are going to want to steal the stuff you sell.

In a new post on the Splitbrain blog today about creating and working with Semacode and QR Codes, specifically with PHP functionality.

I was more interested in Semacode, because it looks somehow cooler than QR in my opinion. Unfortunately I wasn't able to find any free (beer and speech) PHP library to create these codes.

He did, however, find a Javascript port (from a C library) to harvest the logic from and create his own PHP class to handle the semacode creation. He notes that it's probably still a bit buggy but is offering it for download to whoever might want to mess around with it.