Bug #18591 for POE: POE::Component::Server::TCP + POE::Filter::HTTPD broken in 0.34

Fri Apr 07 17:24:57 2006 Guest - Ticket created

Subject:

POE::Component::Server::TCP + POE::Filter::HTTPD broken in 0.34

The handler for ClientInput no longer receives an HTTP::Request object as ARG0; it receives the stringified version of the request. Obviously this breaks a lot of programs (including the example web server in the cookbook).

Fri Apr 07 18:11:40 2006 Guest - Correspondence added

From:

tpetersen [...] ocv.com

The problem appears to be in POE::Filter::clone, which POE::Filter::HTTPD inherits. The method handles either an array or a class literal. In the second case, shouldn't it bless the new object as ref($self) || $self to handle a literal class name? In code that uses POE::Component::Server::TCP and POE::Filter::HTTPD, changing ClientFilter from 'POE::Filter::HTTPD' to ['POE::Filter::HTTPD'] works around the bug.

Fri Apr 07 18:11:41 2006 The RT System itself - Status changed from 'new' to 'open'

Fri Apr 07 18:28:28 2006 Guest - Correspondence added

My mistake, that doesn't fix the problem at all, it just gets past receiving the stringified request. Now I get an HTTP::Response object instead of an HTTP::Request object; the response contains this message of any URL: Error 400: Bad Request Did not want any more data. Got this: and then the hex dump of the request.

Thu May 04 12:42:39 2006 immute [...] cpan.org - Correspondence added

Myself and dw have been looking at this problem, and it appears to be a problem in how PoCoServerTCP ran though the *Filter arguments, it should be fixed in the next POE release. Also, clone() is an object method, it should *always* have an object as the first argument, if you wanted to use a string literal, you would use new(). On Fri Apr 07 18:28:28 2006, guest wrote: Show quoted text

> My mistake, that doesn't fix the problem at all, it just gets past > receiving the stringified request. > > Now I get an HTTP::Response object instead of an HTTP::Request

object; Show quoted text

> the response contains this message of any URL: > > Error 400: Bad Request > Did not want any more data. Got this: > > and then the hex dump of the request. >

Thu May 04 12:44:21 2006 tpetersen [...] ocv.com - Correspondence added

Subject:	RE: [rt.cpan.org #18591] POE::Component::Server::TCP + POE::Filte r::HTTPD broken in 0.34
Date:	Thu, 4 May 2006 10:44:59 -0600
To:	"'bug-POE [...] rt.cpan.org'" <bug-POE [...] rt.cpan.org>
From:	Theo Petersen <tpetersen [...] ocv.com>

Thanks for the update. ..Theo Show quoted text

-----Original Message----- From: Matt Sickler via RT [mailto:bug-POE@rt.cpan.org] Sent: Thursday, May 04, 2006 10:43 AM To: tpetersen@ocv.com Subject: [rt.cpan.org #18591] POE::Component::Server::TCP + POE::Filter::HTTPD broken in 0.34 <URL: http://rt.cpan.org/Ticket/Display.html?id=18591 > Myself and dw have been looking at this problem, and it appears to be a problem in how PoCoServerTCP ran though the *Filter arguments, it should be fixed in the next POE release. Also, clone() is an object method, it should *always* have an object as the first argument, if you wanted to use a string literal, you would use new(). On Fri Apr 07 18:28:28 2006, guest wrote:

> My mistake, that doesn't fix the problem at all, it just gets past > receiving the stringified request. > > Now I get an HTTP::Response object instead of an HTTP::Request

object;

> the response contains this message of any URL: > > Error 400: Bad Request > Did not want any more data. Got this: > > and then the hex dump of the request. >

This message and its attachments are for the sole use of the intended recipient(s) and may contain confidential, proprietary and privileged information. Any unauthorized review, copying, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender immediately by replying to the address listed in the From: field and destroy all copies of the original message and its attachments.

Mon May 15 17:59:20 2006 immute [...] cpan.org - Correspondence added

Theo, I am led to believe this was caused by the component not registering the correct filter. This should be fixed in the next POE release. On Thu May 04 12:44:21 2006, tpetersen@ocv.com wrote: Show quoted text

> Thanks for the update. > > ..Theo > > -----Original Message----- > From: Matt Sickler via RT [mailto:bug-POE@rt.cpan.org] > Sent: Thursday, May 04, 2006 10:43 AM > To: tpetersen@ocv.com > Subject: [rt.cpan.org #18591] POE::Component::Server::TCP + > POE::Filter::HTTPD broken in 0.34 > > > <URL: http://rt.cpan.org/Ticket/Display.html?id=18591 > > > Myself and dw have been looking at this problem, and it appears to be > a problem in how PoCoServerTCP ran though the *Filter arguments, it > should be fixed in the next POE release. > Also, clone() is an object method, it should *always* have an object > as the first argument, if you wanted to use a string literal, you > would use new(). > > On Fri Apr 07 18:28:28 2006, guest wrote:

> > My mistake, that doesn't fix the problem at all, it just gets past > > receiving the stringified request. > > > > Now I get an HTTP::Response object instead of an HTTP::Request

> object;

> > the response contains this message of any URL: > > > > Error 400: Bad Request > > Did not want any more data. Got this: > > > > and then the hex dump of the request. > >

> > > > > > This message and its attachments are for the sole use of the intended > recipient(s) and may contain confidential, > proprietary and privileged information. Any unauthorized review, > copying, use, disclosure or distribution is prohibited. If > you are not the intended recipient, please notify the sender > immediately by replying to the address listed in the From: > field and destroy all copies of the original message and its > attachments.

Mon May 15 17:59:40 2006 immute [...] cpan.org - Status changed from 'open' to 'resolved'