enemyofthestate has asked for the wisdom of the Perl Monks concerning the following question:

I'm using LWP to send XML files to customers. Since upgrading to perl 5.8.5 and LWP 5.803 I've been getting the following errors on certain sites.

500 EOF when chunk header expected

Here is what the customer is actually returning (from ethereal):

HTTP/1.1 200 OK Connection: close Date: Mon, 11 Jul 2005 21:24:55 GMT Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET X-AspNet-Version: 1.1.4322 Transfer-Encoding: chunked Set-Cookie: ASP.NET_SessionId=2yacfaf5i2ga23bv22qmls45; path=/ Cache-Control: private Content-Type: text/xml 102 <?xml version="1.0" encoding="utf-8"?> <FloodStatus XMLRevision="1.45"> <StatusID>S1</StatusID> <StatusMessage>Cert Received</StatusMessage> <CertificateNumber>19861752</CertificateNumber> <ControlNumber>695428</ControlNumber> </FloodStatus>

I am guessing the error has to do with the transfer encoding but I don't know how to work around it.

Here is the code I use to send the XML:

# creation of the xml doc snipped # create the user agent $agent = new LWP::UserAgent or die "Unable to create HTTP Agent"; $agent->agent($AGENT); # if encoding is set -- client in this case wants no encoding if ($encode eq "T") { $response = $agent->request(POST $url,[xml=>$xml],content_type=>'a +pplication/x-www-form-urlencoded'); } else { # create a request $request = new HTTP::Request POST=>$url; $request->content_type('text/xml'); $request->content($xml); # send $response = $agent->request($request); } if ($response->is_success) { print $gl_logout "$certno: send to $url successful\n"; undef $agent; return 0; } print $gl_logout "$certno: send to $url failed\n"; print $gl_logout "$certno: Remote said: ",$response->status_line,"\n +"; undef $agent; return 1; }

Replies are listed 'Best First'.
Re: Problem with Dot NET and LWP
by mugwumpjism (Hermit) on Jul 12, 2005 at 06:01 UTC

    It looks like the remote end is sending a Unicode BOM (byte order mark) at the beginning of the stream, at a guess. Which is a bit naughty, because the headers didn't specify that it was going to be a UTF-8 stream. However this might be unrelated to the bug.

    Take that ethereal dump, see if you can work it into a test case for LWP, and submit it as a bug to the maintainer. Make sure you include a working one for comparison, too.

    This might involve a simple Test server, if you can't figure out how to test just the response processing component; this little script can do the trick; it takes two arguments: the response file to issue, and where to save the request that it read.

    use IO::All; my $response = shift; my $target = shift; my $server = io(":9207"); $server->autoclose(0); my $sock = $server->accept; $sock->autoclose(0); my $doc; while (my $line = $sock->readline) { last if $line =~ m/\A\r?\n\Z/; $doc .= $line; } { $doc > io($target)->assert; } $sock->print(io($response)->slurp); $sock->shutdown; # and it was over ... before it began exit(0);
    $h=$ENV{HOME};my@q=split/\n\n/,`cat $h/.quotes`;$s="$h/." ."signature";$t=`cat $s`;print$t,"\n",$q[rand($#q)],"\n";