Re: Redirect (and cookies) support in HTTP_Request2 / HTTP_Client2?
| From: | Michael Gauthier | Date: | Sun, 01 Nov 2009 20:24:44 +0000 |
| Subject: | Re: Redirect (and cookies) support in HTTP_Request2 / HTTP_Client2? | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-53001@lists.php.net to get a copy of this message | ||
On Sun, 2009-11-01 at 18:40 +0300, Alexey Borzov wrote:
> Hi,
>
> I'd like to gather some feedback on how to properly implement redirect and
> cookies support in HTTP_Request2 and / or HTTP_Client2.
>
>
> First, a bit of background. Redirect support was first done in HTTP_Request by
> its original author, but as the class wasn't designed from the ground up for
> performing multiple requests, redirect implementation was a bit of a hack. It is
> currently disabled by default and its use is discouraged.
>
> HTTP_Client has a cleaner implementation, it uses a new instance of HTTP_Request
> for doing a redirect, has proper code for resolving relative URLs.
>
> HTTP_Client also has the following useful features:
> * Stores cookies between requests (persistent storage is also possible);
> * Stores default headers, default request parameters and default listeners.
> These are added to all created instances of HTTP_Request;
> * Can store complete response history;
> * get() / post() / head() / put() / delete() convenience methods.
>
>
> 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.
By putting these features in HTTP_Client2, you can keep the
HTTP_Request2 API lean and focused, like it is now.
I don't (currently) have a need for either of these features, but a
separate package seems like the logical place to put them.
Cheers,
Mike