Socket stops at Header not handling Continuation

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

I am trying to pick up a POST request which appears to be stopping at the header which contains two '\r\n'. I'm not certain it's that or if I need to handle a Continuation differently. I have Etheral open on the request which displays the header in a POST / HTTP/1.0 and the body is on the next lined labeled Continuation.
Should the server close the $addr connection upon reading the two \r\n or should something else be set within the server? All of the data is coming to my server. It just stops at the initial Header.
I've tried closing the connection, thinking a new connection would be made upon continuation but that does not work.
I have also tried to replicate the client side by building a perl client test with the \r\n\r\n in and it works fine. The client making the request is coming from a MS tool. Is there a character conflict that anyone knows of? I also tried catching \015\012\015\012 but I am not sure what should be done at the Continuation point.

use IO::Socket;
$local = IO::Socket::INET->new(
        Proto      => 'tcp',        
        LocalAddr => '192.168.150.131:80',            Reuse     => 1
        ) or die "$!";
$local->listen();    
print "Awaiting client...\n";
my $addr;    
while ($addr = $local->accept() ) {    
$addr->autoflush(1);
    print     "Connecting from: ", $addr->peerhost();    
    print    " Port: ", $addr->peerport(), "\n";

    while (<$addr>) { 
# Should a catch go here upon the \r\n\r\n and close conn
# or a call to accept continuation?
# Everything is coming into the computer
# The server just stops
        print "Client: $_";
    }
    close $addr;    # close client
    print "Idle...\n";    
}
[download]

Any suggestions would be greatly appreciated. I have hit complete discombobulation mode.
Thanks for the help,
DWW

Comment on Socket stops at Header not handling Continuation Download Code

Replies are listed 'Best First'.
Re: Socket stops at Header not handling Continuation by kidongrok (Acolyte) on May 07, 2004 at 21:09 UTC
Im puzzled by your use of 'Continuation', ie 3 times, capitalized, but not formally defined, and not mentioned in code except as comment. have you checked your serverlog for errors ? premature end of script err ?	[reply]
Re: Re: Socket stops at Header not handling Continuation by dwatson06 (Friar) on May 07, 2004 at 21:37 UTC
Sorry about that, I don't know what else to title Continuation. That's the only thing displayed in the Info section of the packet sniffer (Ethereal) after the post. It's the body of the request, for this instance an XML file. Which is shown coming in and I can view the actual XML within the sniffer. serverlog? The code you see is the server. If you mean the client making the request, the connection is kept until the data is returned and closed on the server side. The header is sent to the Perl server, then stops. In the packet sniffer, it shows that the body of data has been sent as well but it's not coming into the server. Thanks, DWW	[reply]
Re: Socket stops at Header not handling Continuation by Duco (Sexton) on May 07, 2004 at 22:31 UTC
By "Continuation" I assume you mean HTTP's "100 Continue" feature, as documented in the HTTP RFC. If the client has "Expect: 100-continue" as one if its request headers, then try replying "100 (Continue)\r\n" when you see the blank header (i.e. "\r\n\r\n"). The client should then send the body of the request. After you've received that, then you send the final response as normal.	[reply]
Re: Re: Socket stops at Header not handling Continuation by dwatson06 (Friar) on May 10, 2004 at 14:06 UTC
Thanks for the Response Duco, I have tried that as 100-continue, 100 (Continue) and several other ways listed on the net... The body is coming in, I can see it in the packet sniffer. It is an XML file that I must parse and return a result from. Just before the XML file coming in is some strange characters (...+......._..E...i.@...). After that the xml files displays. Could there be a conflict here? Is there a way to strip this? Thanks, DWW	[reply]