Skip Menu |

This queue is for tickets about the POE-Component-Client-HTTP CPAN distribution.

Report information
The Basics
Id: 48354
Status: resolved
Priority: 0/
Queue: POE-Component-Client-HTTP

Owner: Nobody in particular
Requestors: x542d44174a72dfe3 [...]

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

Received: from ( []) by (Postfix) with SMTP id 0AA3519B82D1 for <bug-POE-Component-Client-HTTP [...]>; Fri, 31 Jul 2009 08:24:00 -0400 (EDT)
Received: (qmail 2975 invoked by uid 103); 31 Jul 2009 12:24:00 -0000
Received: from ( by with QMQP; 31 Jul 2009 12:24:00 -0000
Received: from (HELO ( by (qpsmtpd/0.80) with SMTP; Fri, 31 Jul 2009 05:23:53 -0700
Received: (qmail 23849 invoked by uid 1000); 31 Jul 2009 12:31:48 -0000
Delivered-To: cpan-bug+POE-Component-Client-HTTP [...]
MIME-Version: 1.0
Subject: Excessively small Streaming size causes header to mix with content?
X-Spam-Status: No, hits=2.8 required=8.0 tests=FROM_LOCAL_HEX,RDNS_DYNAMIC
Return-Path: <x542d44174a72dfe3 [...]>
X-Original-To: bug-POE-Component-Client-HTTP [...]
Content-Disposition: inline
Date: Fri, 31 Jul 2009 14:31:48 +0200
X-Spam-Level: **
content-type: text/plain; charset="utf-8"
Message-ID: <20090731123148.GA13730 [...]>
To: bug-POE-Component-Client-HTTP [...]
From: Steve <x542d44174a72dfe3 [...]>
X-RT-Original-Encoding: us-ascii
Content-Length: 2241
Download (untitled) / with headers
text/plain 2.1k
First a warning: I have tested this with POE-Component-Client-HTTP-0.890, but my version of perl is ancient: 5.8.8 (don't laugh). If it works for you then please close the bug. Description: Posting a request with a very small Streaming size causes part of the header to be recognized as content. If the server uses chunked responses, the final "0" chunk is not taken as eof and the request does not finish until it times out. I don't know if there's any real use for such small Streaming sizes, but if the smallest allowed size depends on the server's response, then there is of course a problem anyway. Sample code: #!/usr/bin/perl use POE; use POE::Component::Client::HTTP; use HTTP::Request::Common; POE::Component::Client::HTTP->spawn( Alias => 'ua', Streaming => 30 ); POE::Session->create( inline_states => { _start => \&start, _stop => \&stop, got_data => \&got_data } ); POE::Kernel->run(); sub start { $_[KERNEL]->post( ua => request => got_data => GET( '' ) ) } sub stop { print STDERR "stopping\n"; $_[KERNEL]->alias_remove( 'ua' ) } sub got_data { unless ( $_[HEAP]->{printed}++ ) { print STDERR "*** request:\n" . $_[ARG0]->[0]->as_string() . "\n***\n\n"; print STDERR "*** response:\n" . $_[ARG1]->[0]->as_string() . "\n***\n\n"; } print STDERR "*** data:\n" . (defined($_[ARG1]->[1]) ? $_[ARG1]->[1] : "(eof)" ) . "\n***\n\n"; } __END__ Output (cookie has been masked): *** request: GET HTTP/1.1 Host: User-Agent: POE-Component-Client-HTTP/0.890 (perl; N; POE; en; rv:0.890000) *** *** response: HTTP/1.1 200 OK Content-Type: text/plain Last-Modified: Thu, 16 Jul 2009 15:25:04 GMT Set-Cookie: PREF=ID=aaaaaaaaaaaaaaaa:TM=0000000000:LM=0000000000:S=aaaaaaaaaaaaaaaa; expires=Sun, 31-Jul-2011 12:06:10 GMT; path=/; *** *** data: Date: Fri, 31 Jul 2009 12:06: *** (snip, contains more of the header as well as the real data) *** data: maps_webmasters.xml 0 *** Seeing "Date:" as data is unexpected, and that last "0" is seen because the HTTPChunk filter is never applied. I'm brand new to POE, so sorry for not hunting it down further, or if it's just because of some beginner's mistake on my part.
MIME-Version: 1.0
In-Reply-To: <20090731123148.GA13730 [...]>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <20090731123148.GA13730 [...]>
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-14813-1266214615-1818.48354-0-0 [...]>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 207
Download (untitled) / with headers
text/plain 207b
Thank you for the test case. I have finally been able to track down and fix the issue. The fix is in commit 38323e64b15d9e6c8d540bb70ed88a058bfa9453 (github, gitorious) ... and will be in the next release.

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to