Description: ------------ Original developer of Cookie Manager assumed that everyone will want to cleanup their cookies when the code is serialised or unserialised. __sleep function of HTTP_Client_CookieManager automatically removes all the cookies that have an empty 'expires' value. The logic should be simpler - as long as there is an instance of a Cookie Manager, all the session cookies (without 'expires' value) should persist. Currently, __sleep and __wakeup functions are trying to mimic a web browser starting up and closing, what I'm after is not closing and reopening, but just to minimise the browser window. Hopefully, the analogy is clear. I'm serialising and storing the HTTP_Client so that it can be reused later as if it were all the same session, so for me the session cookies should persist. For others the existing behaviour might be enough. An extra bit needs to be passed to HTTP Client that will make it keep the session cookies beyond the serialisation. Essentially, with the 'persistent' flag set to on, as long as HTTP Client exists, the imaginary browser window is open. This persistent flag can be passed on to the cookie manager and will use it to clean up (or not) session cookies. I've overcome this by writing my own class that extends Cookie Manager and replaced __sleep and __wakeup with my own versions, but would prefer that the required logic be in PEAR for all to enjoy. I'm glad that HTTP Client allows a cookie manager to be passed in.

I think your last paragraph sums everything nicely: HTTP_Client allows passing a custom cookie manager and thus the behavior can be changed in any way you like. :) Frankly, I find the proposed behaviour counter-intuitive. I may add the proposed cookie manager class (if you provide the code) as either a separate class or an usage example, but I won't change the default CookieManager.

The assumption that serialisation of CookieManager is equivalent to developer's desire to remove session cookies is what's counter-intuitive. By your logic, I don't need PEAR, because I can write all the code myself. What I'm interested in is for PEAR to provide the flexibility, so I can focus on Business Logic, not on workarounds. That's why I'm providing my feedback (an input of sorts, just like your code is an input). I'm not even trying to challenge the default behaviour. All I'm asking for is for the default behaviour to be configurable. What we need is a way to tell the cookie manager how to behave without having to write a new class. Have a look at my code to see how ridiculous it is to write a new class for this functionality. class Persistent_Cookie_Manager extends HTTP_Client_CookieManager { function __sleep() { return Array('_cookies'); }//end __sleep() function __wakeup() { foreach ($this->_cookies as $hash => $cookie) { if (!empty($cookie['expires']) && strtotime($cookie['expires']) < time()) { unset($this->_cookies[$hash]); } } }//end __wakeup() function deleteSessionCookies() { foreach ($this->_cookies as $hash => $cookie) { if (empty($cookie['expires'])) { unset($this->_cookies[$hash]); } } }//end deleteSessionCookies() }//end class ---------------- I use it like this: $cookie_man =& new Persistent_Cookie_Manager(); $HTTP_Client =& new HTTP_Client($request_parameters, $default_headers, $cookie_man); Then, somewhere else in the execution (most likely after serialisation/unserialisation) if ( we think session cookies should be expired ) { $HTTP_Client->_cookieManager->deleteSessionCookies(); } ---------------- What i'm writing is a form of a proxy, where the serialised HTTP_Client is equivalent to the web browser window being open but not active (minimized). The session cookies in it should be maintained until the real browser window is closed, which is tracked elsewhere.

I couldn't agree more with you Andrei. An (optional) configuration variable to specify this behavior would be the most appropriate solution. I have an application where it is critical to persist all cookies between end user requests.

Implemented in CVS. Added a switch to CookieManager controlling serialization of session cookies. The default behaviour is of course unchanged due to BC requirements.