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).

On the PHPFreaks website, there's a new tutorial talking about sessions and cookies in PHP:

HTTP is a stateless protocol. This means that each request is handled independently of all the other requests and it means that a server or a script cannot remember if a user has been there before. However, knowing if a user has been there before is often required and therefore something known as cookies and sessions have been implemented in order to cope with that problem.

The tutorial is pretty introductory, so if you're not new to the PHP world, you won't learn much. New developers, though, will learn how to set cookies, use sessions and learn a bit about the security of both.

Brian Moon has posted a tip (and a bit of code) he's worked up to help make a users cookies last a bit longer than they were originally designed to:

When you start a session, if the user had no cookie, they get a new session id and they get a cookie. You can configure that cookie to last for n seconds via php.ini or session_cookie_set_params(). But, and this is a HUGE but for me, that cookie will expire in n seconds no matter what.

His method provides a way to extend the life of the cookies currently set for the domain by changing the time to live through a series of ini_get calls wrapped in a setcookie() call.

Stoyan Stefanov has come up against one of the frustrations of web development involving cookies - problems caused by the switch from a "www." in the host to none. He's come up with a test to show you how cookies are set and where you can access them from.

One of the implications of following the rule is related to the whole www vs no-www question. Basically you should always use www if you're planning to use any other sub-domains and you want them cookie-free. This is because you have no way to set a cookie only to the top-level domain.

His code sets cookies for the ".phpied.com", "phpied.com" and "www.phpied.com" domains. Since the domains without the "www" offer a bit broader range of possible matches, he recommends that if you're ever going to use any kind of subdomain, you'll want to use the more broad cookie to cover it.

Ed Finkler, not normally a big fan of the WordPress PHP-based blogging system, has pointed out some positive steps that were made in the latest release in the security arena.

Anyone who gets me liquored up knows that I'm not a fan of Wordpress. I think it's great from a user (that is, the person writing the content) standpoint, but it has lagged behind severely in terms of security, and I don't believe its popularity is the sole reason WP has been the subject of dozens of vulnerability reports every year. That being said, the WP 2.5 release appears to offer significant improvements in a couple areas: password hashes and cookie data encryption.

He mentions two things in particular - their addition of salted passwords and secure cookies.

In one of his recent blog entries, Brian Moon takes a look at what he considers the "proper use" of the PHP superglobal $_REQUEST (as brought on by a thread on the PHP internals mailing list.

I have seen more than one person make the following logic mistake: I may get data via GET, I may get data via POST - Ah, I should use $_REQUEST as it will catch both.

Brian points out the error - cookies aren't in $_REQUEST so improper handling of those values could lead to cookie data overwriting GET/POST data from $_REQUEST. Several of the comments on the post also warn against improper handling of the values, noting that doing so could lead to holes open for attacks (like session fixation).

On PHP-Learn-It.com today, there's a new tutorial looking to get you, the budding PHP developer, into working with cookies in PHP.

A cookie is often used to store data which can be used to identify a user, for example, person's username. [...] In this tutorial, we will learn how to write, read and delete cookies in PHP.

They show how to create the cookie (with set_cookie) - both one that will timeout when the browser closes and one that stays after - how to read the value from them and how to remove them by setting the data in the past.

Gareth Heyes has posted about a new plugin he's created , spam protection for his WordPress blog - SpamBam.

The latest plugin uses my PHP/JS randomisation techniques to create a key and protect against spam. I've took this bold move to see what affect it has and if the blog spammers will get round it because it no longer uses javascript cookies.

His plugin includes features including a lack of cookie use, delay on spammers (slows spam scripts) and doesn't use CAPTCHAs. You can also check out this section on Gareth's blog for the latest on the plugin.

Brian Nelson has posted a follow-up to his previous article on creating a reverse proxy with PHP5, this time expanding on the functionality of it and reworking some to increase performance.

It's gotten a bit more complex; The proxy handler didn't pass all the client headers to the proxy server. This caused problems with having the wrong client type, no Etag caching, cookie passing, etc. Here's the current rev, which solves a lot of these issues.

The complete code for the proxy class included in the post and a note was added that there's now a Google Code project that's been created for it (svn repository).

Continuing on with their look at the Factory Pattern (part one), DevShed has part two posted - a look at applying what was learned previously into a simple cookie-handling and file manipulation script.

At this stage you should have a more accurate idea of how to include the factory pattern into your own PHP applications, at least at a very basic level. But don't you worry because this scenario is going to change quickly, since in this second tutorial I'm going to teach you how to take advantage of the capacity offered by the pattern to create objects that are capable of saving data to different locations, including files and cookies.

The tutorial starts off by creating the classes needed to save strings and objects based off of the abstract DataSaverFactory class. On top of this, they build the classes to save the cookies and work with the files using the Factory objects.