in reply to SOAP::Lite. Flush ssl session

schetchik:

Without seeing the code and exact error messages, it's hard to guess exactly which of the thousands of potential issues is the one you're having.

...roboticus

When your only tool is a hammer, all problems look like your thumb.

Replies are listed 'Best First'.
Re^2: SOAP::Lite. Flush ssl session
by schetchik (Beadle) on Jul 18, 2014 at 16:37 UTC
    Code is very simple
    use SOAP::Lite; my $proxy="https://some/address"; my $client = SOAP::Lite->proxy( $proxy ); ... my $response; eval { $response = $client->call( $method => @params ) };
    I've turned on debug on IO::Socket::SSL and its output is sort of like this
    DEBUG: .../IO/Socket/SSL.pm:1596: new ctx 73492512 DEBUG: .../IO/Socket/SSL.pm:338: socket not yet connected DEBUG: .../IO/Socket/SSL.pm:340: socket connected DEBUG: .../IO/Socket/SSL.pm:358: ssl handshake not started DEBUG: .../IO/Socket/SSL.pm:406: set socket to non-blocking to enforce + timeout=30 DEBUG: .../IO/Socket/SSL.pm:419: Net::SSLeay::connect -> -1 DEBUG: .../IO/Socket/SSL.pm:429: ssl handshake in progress DEBUG: .../IO/Socket/SSL.pm:439: waiting for fd to become ready: SSL w +ants a read first DEBUG: .../IO/Socket/SSL.pm:459: socket ready, retrying connect DEBUG: .../IO/Socket/SSL.pm:419: Net::SSLeay::connect -> -1 DEBUG: .../IO/Socket/SSL.pm:429: ssl handshake in progress DEBUG: .../IO/Socket/SSL.pm:439: waiting for fd to become ready: SSL w +ants a read first DEBUG: .../IO/Socket/SSL.pm:459: socket ready, retrying connect DEBUG: .../IO/Socket/SSL.pm:419: Net::SSLeay::connect -> 1 DEBUG: .../IO/Socket/SSL.pm:474: ssl handshake done DEBUG: .../IO/Socket/SSL.pm:1633: free ctx 73492512 open=73492512 DEBUG: .../IO/Socket/SSL.pm:1641: OK free ctx 73492512
    so I think that remote server administrator is a litle bit wrong. Furthermore, I'm going to add ssl_opts to my soap client transport for next tests.
    $client->transport->ssl_opts( SSL_session_cache_size => 0, )
    I hope it will help me :)

      sketchik:

      Tracing through the docs for connect information: SOAP::Lite leads us to SOAP::Transport which references LWP::UserAgent which mentions the conn_cache method. That sounds like a promising "this is how they reuse connections" though, so we follow onwards to LWP::ConnCache where, sure enough, it seems that it's used for caching connections. The drop routine lets you specify the policy for caching connections. So it looks like you can call it to set the policy to undef, which indicates that connections shoulnd't be cached at all.

      Alternatively (probably the first one I should've though of), if you could simply let your $client go out of scope, it may be enough to close the connection and force a new connection next time.

      Hopefully, one of these two methods should get you going.

      ...roboticus

      When your only tool is a hammer, all problems look like your thumb.

      From the comments I see some confusion over terms like connection, SSL session or handshake. Maybe it will help to clarify these terms:
      • Connection: this can be either the TCP connection or the SSL connection (HTTPS) on top of the TCP connection. There might be multiple HTTP requests inside same connection, which is called persistent HTTP connections or keep alive. Keep alive is controlled by conn_cache or keep_alive settings from LWP::UserAgent. My understanding of LWP::UserAgent is, that keep_alive is disabled by default and I cannot see that SOAP::Lite enables it.
      • SSL session: An SSL session starts with a full SSL handshake, e.g. negotiating of ciphers, validation of certificate etc. A single SSL session can span multiple TCP/SSL connections, i.e. server and client can cache session information so that the session can be resumed on the next TCP/SSL connection. If you want to get this behavior on the client site with IO::Socket::SSL (which is the underlying class used for HTTPS) you explicitly need to enable it by using session_cache.
      • Handshake: In SSL context this refers to the SSL handshake. There might be a full SSL handshake at the beginning of an SSL session and there might be a shortened SSL handshake if a session gets resumed. Also, inside an established SSL session there can be renegotiations which again do SSL handshakes. In HTTP context handshake would probably refer to the pair of HTTP request and HTTP response, but I've seen it rarely used in this context.
      Which leads to the question, what you actually want:
      • Do you want to make sure that no SSL resumption is done? This should be the default.
      • Do you want to disable keep-alive, e.g. have only a single HTTP request per TCP/SSL connection? From my understanding this would be the default too.
        Thank you for detailed explanation. An yes, I talk about SSL resumption. I thought that it is default behavior, but I have some doubt now.