Alexey Borzov | 1 Nov 10:51 2009
Picon

Re: [PEAR-BUG][Reminder] Reminder about open bugs in HTML_Common

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 http://pear.php.net/bugs/bug.php?id=15787&edit=1
> 

--

-- 
PEAR QA Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Alexey Borzov | 1 Nov 14:30 2009
Picon

[PEPr] Comment on Authentication::OpenID


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

Craig Constantine | 1 Nov 13:43 2009
Picon
Picon

Re: [PEAR-QA] Re: [PEAR-BUG][Reminder] Reminder about open bugs in HTML_Common

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)

Alexey Borzov | 1 Nov 13:50 2009
Picon

Re: [PEPr] Comment on Authentication::OpenID

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

Martin Jansen | 1 Nov 14:14 2009
Picon

Re: [PEAR-DEV] Re: [PEAR-BUG][Reminder] Reminder about open bugs in HTML_Common

On 01.11.09 10:51, Alexey Borzov wrote:
> 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?

The cron job should be gone now.

http://svn.php.net/viewvc/systems/trunk/boxen/pb12.pair.com?r1=237739&r2=290124

Martin

--

-- 
PEAR QA Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Alexey Borzov | 1 Nov 14:17 2009
Picon

Re: [PEAR-DEV] Re: [PEAR-BUG][Reminder] Reminder about open bugs in HTML_Common

Hi Martin,

Martin Jansen wrote:
> On 01.11.09 10:51, Alexey Borzov wrote:
>> 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?
> 
> The cron job should be gone now.
> 
> http://svn.php.net/viewvc/systems/trunk/boxen/pb12.pair.com?r1=237739&r2=290124 

Thanks, hopefully this time it is *really* gone. :]

--

-- 
PEAR QA Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Alexey Borzov | 1 Nov 16:40 2009
Picon

Redirect (and cookies) support in HTTP_Request2 / HTTP_Client2?

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)

Bill Shupp | 1 Nov 18:22 2009

[PEPr] Comment on Authentication::OpenID


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

till | 1 Nov 17:30 2009
Picon

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

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)

Bill Shupp | 1 Nov 17:59 2009

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

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)


Gmane