Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129734
Date: Mon, 5 Jan 2026 11:28:01 +0000 (GMT)
To: Jakub Zelenka <bukka@php.net>
cc: PHP internals list <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] TLS Session Resumption Support for Streams
In-Reply-To: <CAEKnhAG1KW-D+THEpm+C-e5caCNRPVhx61zLkZGjn_WaLcjRTA@mail.gmail.com>
Message-ID: <0d53cf4c-dc42-41f9-cd71-14658988c511@php.net>
References: <CAEKnhAG1KW-D+THEpm+C-e5caCNRPVhx61zLkZGjn_WaLcjRTA@mail.gmail.com>
Precedence: list
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1018591978-1767612481=:13281"
From: derick@php.net (Derick Rethans)

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-1018591978-1767612481=:13281
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Tue, 23 Dec 2025, Jakub Zelenka wrote:

> I would like to introduce a TLS Session Resumption Support for Streams=20
> RFC that is part of my stream evolution work (PHP Foundation project=20
> funded by Sovereign Tech Fund) :
>=20
> https://wiki.php.net/rfc/tls_session_resumption_api

I have a few questions/comments:

| Client-Only Options:
|=20
| session_data (string) - Binary session data from a previous connection=20
| to resume. Data must be from a session_new_cb callback.
=2E..
| session_new_cb (callable) - Callback invoked when a new session is
| established.
| ...
| - $sessionData: Serialized session (OpenSSL format via=20
|   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=20
openssl data is exposed to the user, for which this is mainly an opaque=20
blob of data=C2=A0=E2=80=94 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=20
situation to be caused by supplying options that have no effect.

| Server Behaviour
| ...
| With External Cache (session_get_cb provided):=20
| - 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=20
error for which an Error-type exception ought to be thrown. On many=20
occasions warnings appear in a logging black hole.

| - session_cache_size and session_timeout are ignored (application=20
| manages storage)

For similar reasons, I don't think these should be just ignored either=20
(again: it's a programming error).

| Backward Incompatible Changes
| ...
| - New options are ignored in older PHP versions (standard stream=20
|   context behavior)

That's not a Backward Compatibility issue, but a *Forward Compatibility*=20
issue.=20

| Potential Considerations:=20
| ...
| - The new callbacks use resources passed as parameters - these must=20
|   not be stored beyond the callback scope (documented limitation)

Would it be possible to do this *without* introducing new=20
resources/resource types?

cheers,
Derick

--=20
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/suppo=
rt

mastodon: @derickr@phpc.social @xdebug@phpc.social
--8323329-1018591978-1767612481=:13281--