I have small program that shows the equivalent problem when writing to a file:

use strict;
use IO::File;

my $fh = new IO::File("> qqq.txt");
defined($fh) || die "Cannot open qqq.txt\n";
#binmode($fh);

my $CRLF = "\015\012";
print $fh "test",$CRLF;
close $fh;
[download]

Without the binmode call, the file is written as "test\r\r\n". Unfortunately, the node A Little History on 0D0A says that binmode can only be used for files, not sockets. For sockets it recommends a $CRLF value like the one given above, but my test program shows that won't work. Windows sees it is supposed to print a "\012", cleverly expands that to "\015\012", and ends up doubling my carriage return.

In HTTP:Daemon, I find the following line (in the section for HTTP::Daemon::ClientConn):

my $CRLF = "\015\012";   # "\r\n" is not portable
[download]

Ironically, the given code isn't portable either! I patched it to have "012" instead.

Unfortunately, my content length still seems to be off this way, and I get the "unclosed token." Does anyone have a better work-around, or a way to set binary mode for sockets? Thanks.

Update: I have a work-around now on the client side, so I took out the patches on the server side. In Frontier::Client, I did the following:

    my $content = $response->content;

    # Second-chance attempt for a broken Windows Frontier
    # service, which puts good results into client-junk.
    if (!$content) {
       my $headers = $response->headers;
       my $cjunk = $headers->{"client-junk"};
       if (defined $cjunk) {
          # Reconstitute the result.
          $content = join("\n",@$cjunk);
       }
    }
[download]

This will work for the small amount of result contents that I need. There is clearly something wrong here that I have to make such a patch, but it will do for now.