in reply to Re: SOAP::Lite. Flush ssl session
in thread SOAP::Lite. Flush ssl session

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 ) };

[download]
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

[download]
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,
  )

[download]
I hope it will help me :)

Replies are listed 'Best First'.
Re^3: SOAP::Lite. Flush ssl session
by roboticus (Chancellor) on Jul 18, 2014 at 19:45 UTC

    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.

[reply]
[d/l]
[select]
Re^3: SOAP::Lite. Flush ssl session
by noxxi (Pilgrim) on Jul 20, 2014 at 05:35 UTC
    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.
[reply]
      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.
[reply]

In Section Seekers of Perl Wisdom