Are there any issues in HTTP_Request2 that prevent using it here and require using PHP4 HTTP_Request instead? -- http://pear.php.net/pepr/pepr-proposal-show.php?id=603 -- -- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
me too! (and I've been whining about this for *months*) -- Craig Constantine - PEAR web/CVS: cconstantine - cconstantine <at> php.net -------- Original Message -------- Subject: [PEAR-QA] Re: [PEAR-BUG][Reminder] Reminder about open bugs in HTML_Common From: Alexey Borzov <borz_off <at> cs.msu.su> To: PEAR QA <pear-qa <at> lists.php.net> Date: Sun Nov 1 04:51:01 2009 Hi, I am still receiving "reminders" for bugs closed half a year ago. Received: from pb12.pair.com (pb12.pair.com [216.92.131.66]) Can someone having access to that box AND a bit of clue about cron finally kill that job? PEAR QA wrote: PEAR Bug Database summary for HTML_Common - http://pear.php.net/bugs ID Status Summary 15787 Open _parseAttributes with strings trimmed blank of attribute values. Further comments can be seen at http://pear.php.net/bugs/15787 Edit this bug report at(Continue reading)
Hi, Alexey Borzov wrote: > Are there any issues in HTTP_Request2 that prevent using it here and > require using PHP4 HTTP_Request instead? Ah, me stupid, me no can read. :[ I'll think about enabling redirect support in HTTP_Request2 and / or porting HTTP_Client to PHP5. -- -- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
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(Continue reading)
Alexey: Yes. From the proposal description: "HTTP_Request is used instead of HTTP_Request2 because following redirects was not included in HTTP_Request2...". However, I do need ssl peer/host verification, and I'm not sure if HTTP_Request even supports that at this time. So something needs to change. -- http://pear.php.net/pepr/pepr-proposal-show.php?id=603 -- -- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
On Sun, Nov 1, 2009 at 4:40 PM, Alexey Borzov <borz_off <at> cs.msu.su> 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(). > >(Continue reading)
On Nov 1, 2009, at 7:40 AM, 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(Continue reading)
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(Continue reading)
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.(Continue reading)
Hi Bill, Bill Shupp wrote: > My feeling is that I don't think we need both HTTP_Client2 and > HTTP_Request2 going forward. Just put the missing features in > HTTP_Request2. My current feature interest is that of redirects, but I > can see the other HTTP_Client features being useful as well if you want > to bring them over. I tend to agree that a separate package doesn't make sense. I'll probably be able to add redirect support to HTTP_Request2 in a few weeks, Cookie jar support is a more exotic feature and can wait a bit longer. -- -- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RSS Feed1 | |
|---|---|
20 | |
11 | |
30 | |
24 | |
17 | |
37 | |
9 | |
25 | |
29 | |
34 | |
9 | |
17 | |
27 | |
48 | |
52 | |
58 | |
114 | |
55 | |
43 | |
34 | |
48 | |
48 | |
62 | |
55 | |
54 | |
36 | |
70 | |
85 | |
118 | |
34 | |
14 | |
33 | |
87 | |
100 | |
27 | |
86 | |
73 | |
62 | |
105 | |
35 | |
60 | |
91 | |
84 | |
78 | |
165 | |
211 | |
256 | |
403 | |
90 | |
88 | |
132 | |
47 | |
142 | |
182 | |
203 | |
167 | |
129 | |
186 | |
169 | |
130 | |
253 | |
356 | |
381 | |
155 | |
218 | |
203 | |
259 | |
159 | |
302 | |
153 | |
590 | |
217 | |
399 | |
388 | |
354 | |
215 | |
151 | |
339 | |
226 | |
604 | |
370 | |
236 | |
429 | |
453 | |
291 | |
381 | |
487 | |
390 | |
286 | |
298 | |
201 | |
369 | |
318 | |
589 | |
645 | |
481 | |
424 | |
421 | |
602 | |
541 | |
522 | |
612 | |
494 | |
611 | |
492 | |
824 | |
992 | |
1596 | |
1147 | |
1759 | |
923 | |
595 | |
679 | |
713 | |
835 | |
923 | |
1287 | |
1832 | |
1238 | |
1010 | |
1107 | |
1012 | |
689 | |
1159 | |
885 | |
700 | |
862 | |
667 | |
934 | |
686 | |
687 | |
733 | |
748 | |
755 | |
1 | |
1 | |
1 | |
1 |
