Hi, On Mon, Jan 5, 2026 at 12:28 PM Derick Rethans <[email protected]> wrote:
> 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 just done a significant update (version 0.2 of RFC) that introduces OpenSSLSession class and re-implementation of the SSL_CTX creation (mainly for server) and some other changes. > 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? > > Yes, I introduced OpenSSLSession which represent the actual session so sessionData can be only instance of this class. > 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*. > > It was ASN.1 DER representation but I agree that using object is better which I introduced in the update. It also allows serialization / deserialization (import / export) from DER and PEM. Just a note that constant (not enum) is used because that constant already exist and it's used in other function so adding enum would be out of scope and inconsistent here (please don't ask for it :) ). > | 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. > > There is now error thrown for some illogical combination that can be checked easily. Unknown stream options are always ignored but I agree that in some cases it could be confusing so throwing ValueError there. > | 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. > > This has been changed to exceptions > | - 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). > As I noted all unknown stream options are ignored. This has been always the case. This would require redesign of stream option and big BC break to change it. I removed this note from RFC because it's just how things work there. I also addressed some missing cases that now throws but can't really go any further as it would make things inconsistent with the rest of the code. > | 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. > > I removed that note. > | 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? > > This was meant for provided stream but it can be actually used so I removed it. Cheers Jakub
