Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129782
Message-ID: <2d741c45-9c92-4404-a0d5-02bf26a557b1@bastelstu.be>
Date: Sun, 18 Jan 2026 15:16:32 +0100
Precedence: list
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] TLS Session Resumption Support for Streams
To: Jakub Zelenka <bukka@php.net>,
 PHP internals list <internals@lists.php.net>
References: <CAEKnhAG1KW-D+THEpm+C-e5caCNRPVhx61zLkZGjn_WaLcjRTA@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CAEKnhAG1KW-D+THEpm+C-e5caCNRPVhx61zLkZGjn_WaLcjRTA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

On 12/23/25 00:07, 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

Thank you for the RFC. The feature makes sense to me and fills a clear 
gap. I'm sharing some of Derick's concerns and questions, particularly:

1. What will happen if an incorrect / outdated / malformed 
`session_data` string is provided? Will it silently be ignored? Will it 
emit an error? Will there be issues internally in OpenSSL?

2. We should avoid introducing new E_WARNINGs, particularly for clear 
error situation (session_get_cb without session_new_cb).

Best regards
Tim Düsterhus