Perl IO::Socket::SSL with web server hang - perl

Question

I've got a problem when using IO::Socket::SSL.
Everything works fine under normal operation but I had an issue where the web server (IIS) locked up and Perl got stuck, even after the web server became active again.
I'm running the Perl script as an exe under Windows and I can't actually see the program running as it is hidden - here is the code:
sub api_action
{
$api_action = $_[0];
use IO::Socket::SSL;
$EOL = "\015\012";
$BLANK = $EOL x 2;
$remote = IO::Socket::SSL->new( Proto => "tcp",
PeerAddr => "api.xxxxx",
PeerPort => "443",
SSL_verify_mode => SSL_VERIFY_NONE,
verify_hostname => 0,
Timeout => 120,
);
unless ($remote) { print "cannot connect to API\n"; return "ERROR"
}
$remote->autoflush(1);
print $remote "GET /API/?action=$api_action" . $BLANK;
return <$remote>;
close $remote;
}
My thought is that it has made the initial connection, but is still waiting for a return from the GET command. I would have thought setting the Timeout would just cause it to return the error but it doesn't look like it works.
Any ideas on where I'm going wrong or what I've missed?

Answer 1

You actually send this to the server inside the SSL connection:
GET /path\r\n
\r\n
This is no valid HTTP/1.0 or HTTP/1.1 request but a HTTP/0.9 request. Since HTTP/0.9 is obsolete since 20 years I would not expect to IIS still support this old protocol so it might just show unexpected behavior when confronted with such a request. A proper HTTP/1.0 request would look like this:
GET /path HTTP/1.0\r\n
Host: www.example.com\r\n
\r\n
For more information on how to send proper requests and how to properly deal with the response see the HTTP/1.0 and HTTP/1.1 standards.
Apart from that:
SSL_verify_mode => SSL_VERIFY_NONE,
verify_hostname => 0,
verify_hostname has no meaning in IO::Socket::SSL. You probably saw this with LWP::UserAgent and it is only relevant there.
Everything works fine under normal operation but I had an issue where the web server (IIS) locked up and Perl got stuck, even after the web server became active again.
Unfortunately this is not usable as an error description because it is unclear what you consider as "locked up" and "active again" but essentially if the server behaves erratically then the client might be affected by this.
Currently your are dealing with the request by reading until end of TCP connection. If the server behaves erratically and will not close this connection then you will wait forever.
Note, that the timeout you set might only be relevant for the initial connect and not for further reads. And it might not even work properly on Windows depending on the version of IO::Socket::SSL you use. You might instead add a alarm(60) or similar to make sure that the client does not wait forever on a broken server or you might try to work with non-blocking sockets to deal with the issue.