I think the best thing to do here would be to:

1. test that you can get a working HTTPS server working first (and tested against your Java client),
2. then to add a handler to it for SOAP::Lite (and anything else you please... eg: Pod::WSDL).

The following modules all allow you to easily construct an HTTPS server:

• HTTP::Daemon::SSL
  Read more... (881 Bytes)
• Net::Server, using Net::Server::Proto::SSL as protocol and Net::Server::Fork as your "personality".
  (This approach seems quite flexible)

• Net::Daemon::SSL
  Read more... (778 Bytes)

(Please test with just an SSL-capable webbrowser - ie: Firefox - to rule out the client-side as a problem.)

If you're on windows (not cygwin) and you need to service more than one request simultaneously, you'll need to work around the problems caused by the partial lack of thread-safety in Net::SSLeay. It can be done, but I found it involved writing a much more complicated webserver.

-David

PS: are you definately prohibited from using Apache as your HTTPS/CGI server ? I could not use it in my situation, but it's a much easier solution than writing your own.

I managed to get this code working. I had to modify /site/lib/SOAP/HTTP.pm and change the call to

    $self->{_daemon} = HTTP::Daemon::SSL->new(@params) or Carp::croak 
+"Can't create daemon: $!";
[download]

so it would use the SSL version. This is going to make it tough to propagate my code.

Excellent, so you have a working HTTPS server. (You can put it on whatever port you wish... 443 is just a convention.)

Now, you don't want to be changing SOAP or SOAP::Lite for deployment, so the trick is to invert control;
instead of SOAP::Lite calling HTTP::Daemon, you create a one-shot HTTP::Request handler around SOAP::Lite, and have that handle the request passed to it by HTTP::Daemon::SSL.

So inside your pre-existing HTTP::Daemon::SSL loop...
(where you'd normally parse the HTTP request and construct some HTTP response)
... firstly, construct an HTTP::Request object:


  # I usually molest $raw_request_string a little here...
  my $request = HTTP::Request->parse($raw_request_string);
[download]

create a one-off soap handler:

  my $soap = SOAP::Transport::HTTP::Server
     -> new(YOUR_SOAP_SPECIFIC_ARGS) 
     -> dispatch_to(YOUR_CLASS);
[download]

then feed the request object to the soap handler:

  # and I usually munge headers/SOAPaction here...
  $soap->request($request);
[download]

dispatch the request to your class via SOAP::Lite:

  $soap->handle();
[download]

finally, pull out the response it built:

  my $response = $soap->response;
[download]

As I implied earlier in this thread, doing it this way gives you more control over the HTTP request life-cycle... which means you can serve more than just SOAP rpc's from the service.

As an example, you can inspect the request (say before constructing the HTTP::Request object) and determine (based on the URI) whether you want to respond as SOAP rpc, respond with WSDL describing the service, or even respond with HTML explaining how to use the service.

(In my webservice framework I do all those, plus JSONRPC and some dynamic web content.)

-David