Re: [RFC] TLS Session Resumption Support for Streams

On Tue, 23 Dec 2025, Jakub Zelenka wrote: > I would like to introduce a TLS Session Resumption Support for Streams > RFC that is part of my stream evolution work (PHP Foundation project > funded by Sovereign Tech Fund) : > > https://wiki.php.net/rfc/tls_session_resumption_api I have a few questions/comments: | Client-Only Options: | | session_data (string) - Binary session data from a previous connection | to resume. Data must be from a session_new_cb callback. .. | session_new_cb (callable) - Callback invoked when a new session is | established. | ... | - $sessionData: Serialized session (OpenSSL format via | i2d_SSL_SESSION) 1. Would it be possible to ensure this data is from the callback? 2. I am asking mostly whether we think it is wise that this internal openssl data is exposed to the user, for which this is mainly an opaque blob of data — or in other words, an implementation detail of *OpenSSL*. | Client Behavior | ... | 3. Server-only options (''session_get_cb'', ''session_remove_cb'', | ''session_cache'', ''num_tickets'', etc.) are ignored I don't think it is wise to *ignore* these, and I would prefer an error situation to be caused by supplying options that have no effect. | Server Behaviour | ... | With External Cache (session_get_cb provided): | - session_new_cb becomes required (E_WARNING if missing) | - session_context_id becomes required (E_WARNING if missing) If is is required, it shouldn't be a warning as it is a programming error for which an Error-type exception ought to be thrown. On many occasions warnings appear in a logging black hole. | - session_cache_size and session_timeout are ignored (application | manages storage) For similar reasons, I don't think these should be just ignored either (again: it's a programming error). | Backward Incompatible Changes | ... | - New options are ignored in older PHP versions (standard stream | context behavior) That's not a Backward Compatibility issue, but a *Forward Compatibility* issue. | Potential Considerations: | ... | - The new callbacks use resources passed as parameters - these must | not be stored beyond the callback scope (documented limitation) Would it be possible to do this *without* introducing new resources/resource types? cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support mastodon: @derickr@phpc.social @xdebug@phpc.social