Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130074
Precedence: list
MIME-Version: 1.0
References: <CAEKnhAG1KW-D+THEpm+C-e5caCNRPVhx61zLkZGjn_WaLcjRTA@mail.gmail.com>
 <2d741c45-9c92-4404-a0d5-02bf26a557b1@bastelstu.be>
In-Reply-To: <2d741c45-9c92-4404-a0d5-02bf26a557b1@bastelstu.be>
Date: Fri, 13 Feb 2026 20:22:52 +0100
Message-ID: <CAEKnhAFndXvd=YKFx5aN8yH=kw2NJ5NW_+mOX8OxUYfOYOpapw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] TLS Session Resumption Support for Streams
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000bf99d8064ab988ad"
From: bukka@php.net (Jakub Zelenka)

--000000000000bf99d8064ab988ad
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Sun, Jan 18, 2026 at 3:16=E2=80=AFPM Tim D=C3=BCsterhus <tim@bastelstu.b=
e> wrote:

> 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?
>
>
So this changed a bit as only OpenSSLSession instance can be passed in. So
passing invalid and mallformed instance is not possible (TypeError is
thrown if different type is passed in). But if it's expired, it should just
result in warning and full handshake. This should be later covered as part
of new stream error handling as non terminating error (stored error in
exception mode).


> 2. We should avoid introducing new E_WARNINGs, particularly for clear
> error situation (session_get_cb without session_new_cb).
>

The programmer errors have been converted to ValueErrors and TypeErrors.
There are few new warning but those are for non programmer errors and
should be later handled by new stream error handling (another RFC that I
have).

Cheers

Jakub

--000000000000bf99d8064ab988ad
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,</div><br><div class=3D"gmail_quote gmail_quote_co=
ntainer"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Jan 18, 2026 at 3:16=
=E2=80=AFPM Tim D=C3=BCsterhus &lt;<a href=3D"mailto:tim@bastelstu.be">tim@=
bastelstu.be</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex">Hi<br>
<br>
On 12/23/25 00:07, Jakub Zelenka wrote:<br>
&gt; I would like to introduce a TLS Session Resumption Support for Streams=
 RFC<br>
&gt; that is part of my stream evolution work (PHP Foundation project funde=
d by<br>
&gt; Sovereign Tech Fund) :<br>
&gt; <br>
&gt; <a href=3D"https://wiki.php.net/rfc/tls_session_resumption_api" rel=3D=
"noreferrer" target=3D"_blank">https://wiki.php.net/rfc/tls_session_resumpt=
ion_api</a><br>
<br>
Thank you for the RFC. The feature makes sense to me and fills a clear <br>
gap. I&#39;m sharing some of Derick&#39;s concerns and questions, particula=
rly:<br>
<br>
1. What will happen if an incorrect / outdated / malformed <br>
`session_data` string is provided? Will it silently be ignored? Will it <br=
>
emit an error? Will there be issues internally in OpenSSL?<br>
<br></blockquote><div><br></div><div>So this changed a bit as only OpenSSLS=
ession instance can be passed in. So passing invalid and mallformed instanc=
e is not possible (TypeError is thrown if different type is passed in). But=
 if it&#39;s expired, it should just result in warning and full handshake. =
This should be later covered as part of new stream error handling as non te=
rminating error (stored error in exception mode).</div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex">
2. We should avoid introducing new E_WARNINGs, particularly for clear <br>
error situation (session_get_cb without session_new_cb).<br></blockquote><d=
iv><br></div><div>The programmer errors have been converted to ValueErrors =
and TypeErrors. There are few new warning but those are for non programmer =
errors and should be later handled by new stream error handling (another RF=
C that I have).</div><div><br></div><div>Cheers</div><div><br></div><div>Ja=
kub</div></div></div>

--000000000000bf99d8064ab988ad--