I think you need to split assert and the call to SSL_set_app_data. Otherwise, the call to the OpenSSL function will be eliminated when NBEGUG is set.

I am not sure if it is correct to use SSL_get_session here.

sock->ssl->handshake.client.session_cache is our client-side session cache, and the lifetime of the objects that are registered to the cache should be incremented before they are added to the cache. The h2o_socket_ssl_destroy_session_cache_entry function destroys the entries in the cache when they are to be evicted, by decrementing the reference count.

If there is a concern in using SSL_get1_session here, I think what we should be doing is call i2d_SSL_SESSION and store the serialized form of the resumption token in our session cache.

Thanks for the review! Based on your concern here, I think we can use get1_session here and return 0 with the same effect, as openssl is concerned.
Will push a commit soon which will address the other two as well. 👍

Actually, I'm not sure get1_session would make any difference. Looking at how the new session cb is called in openssl, and it looks like the ref count is incremented before the cb is invoked:

        if (s->session_ctx->new_session_cb != NULL) {
            SSL_SESSION_up_ref(s->session);
            if (!s->session_ctx->new_session_cb(s, s->session))
                SSL_SESSION_free(s->session);
        }

https://github.com/openssl/openssl/blob/master/ssl/ssl_lib.c#L3569

It looks like the current behavior is sound? Please let me me know if this works for you.

Thank you for checking.

Actually, now it seems to me that there is no need to call SSL_get_session at all.

I think we can simply use sess (the argument passed to this function)? And return 1 if we called h2o_cache_set. Does that make sense?

ah yeah 😄the get_session is really unnecessary there will push the change. thanks!

yes and your observation points to a bug in the function: within the ifdef is_resumable may still set the session variable, but not store in the cache, which will leak the sess. Will fix that.

I believe 0a077f3 addresses the concerns. Could you please confirm that h2o_cache_set always add the new value even if the key already exists (in which case the function returns 1).
heh hope there is no path in which we destroy the cache without decrementing the SSL ref too, btw.

Could you please confirm that h2o_cache_set always add the new value even if the key already exists (in which case the function returns 1).

Yes. The function guarantees that the new value to be always added.

These changes look good.

The only suggestion I have is to define a macro for the arguments of SSL_CTX_set_session_id_context, possibily declaring them in include/h2o/socket.h, and using them throughout this PR.