Re: Redirect (and cookies) support in HTTP_Request2 / HTTP_Client2?

From: Date: Sun, 01 Nov 2009 21:28:50 +0000
Subject: Re: Redirect (and cookies) support in HTTP_Request2 / HTTP_Client2?
References: 1 2  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-53002@lists.php.net to get a copy of this message
Hi Michael, Michael Gauthier wrote:
Now, skip to HTTP_Request2. I suspect that if one enables redirect support in cURL adapter, it will work out of the box. It also isn't that difficult to add naïve redirect implementation to Socket adapter, only a matter of porting the relevant code from HTTP_Client::_performRequest(). I'd also like to implement cookie storage support, though, and make us of Public Suffix List (http://publicsuffix.org/). The big question is implementing that *and* redirect support. Cookies can easily be extracted from redirect responses via Observers, but can they also be injected there (esp. with Curl)? If it's not possible, then Curl's native redirect support can not be used and the same PHP-based implementation should be used for both adapters. It will be easier to push that to a separate class (HTTP_Client2?). Also I'm interested whether other features of HTTP_Client are still as relevant with HTTP_Request2 as they were with HTTP_Request.
I think splitting cookie-handling and redirect support into a separate package makes sense. It's the easiest way to make it possible to get the complete response history for redirects, and to have persistent cookie storage backends.
Note that complete response history for redirects will be available in either case due to Observers. I am also not planning to do any persistent cookie storage myself, I'll only implement serialization helpers __sleep() and __wakeup() like in current HTTP_Client_CookieManager.
By putting these features in HTTP_Client2, you can keep the HTTP_Request2 API lean and focused, like it is now.
API bloat is a justified concern, but these features may only add a couple of configuration parameters ('allow_redirects' and 'max_redirects') and a couple of methods (setCookieJar() and getCookieJar()).
I don't (currently) have a need for either of these features, but a separate package seems like the logical place to put them.
I made a quick check with Curl adapter, and as I expected enabling redirects with that required only changing CURLOPT_FOLLOWLOCATION => false to CURLOPT_FOLLOWLOCATION => true in one strategic place. It worked correctly, sending proper events to an Observer and returning the response with the page it was redirected to. Setting CURLOPT_COOKIE from within the callback (i.e. after the original request but before the redirect) also worked. So Curl can use its native redirect handling and will only need Cookie Jar implemented. Since this Cookie Jar will be used from within Curl Adapter, it makes no sense putting it into the separate package... Looks like we won't see HTTP_Client2 after all, no sense implenenting a package for a few convenience methods. :]

« previous php.pear.dev (#53002) next »