Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130073
Precedence: list
MIME-Version: 1.0
References: <CAEKnhAG1KW-D+THEpm+C-e5caCNRPVhx61zLkZGjn_WaLcjRTA@mail.gmail.com>
 <0d53cf4c-dc42-41f9-cd71-14658988c511@php.net>
In-Reply-To: <0d53cf4c-dc42-41f9-cd71-14658988c511@php.net>
Date: Fri, 13 Feb 2026 20:15:28 +0100
Message-ID: <CAEKnhAEujXLjDUCTduEZDx6faFNd8OY8Ytygm4gEfYVsRwkREA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] TLS Session Resumption Support for Streams
To: Derick Rethans <derick@php.net>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000004bfdba064ab96eb0"
From: bukka@php.net (Jakub Zelenka)

--0000000000004bfdba064ab96eb0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Mon, Jan 5, 2026 at 12:28=E2=80=AFPM Derick Rethans <derick@php.net> wro=
te:

> 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 =E2=80=94 or in other words, an implementation detail of *Op=
enSSL*.
>
>
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

--0000000000004bfdba064ab96eb0
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 Mon, Jan 5, 2026 at 12:28=
=E2=80=AFPM Derick Rethans &lt;<a href=3D"mailto:derick@php.net">derick@php=
.net</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">On Tue, 23 Dec 2025, Jakub Zelenka wrote:<br>
<br>
&gt; I would like to introduce a TLS Session Resumption Support for Streams=
 <br>
&gt; RFC that is part of my stream evolution work (PHP Foundation project <=
br>
&gt; funded by 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></blockquote><div><br></div><div>I have just done a significant update =
(version 0.2 of RFC) that introduces OpenSSLSession class and re-implementa=
tion of the SSL_CTX creation (mainly for server) and some other changes.</d=
iv><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I have a few questions/comments:<br>
<br>
| Client-Only Options:<br>
| <br>
| session_data (string) - Binary session data from a previous connection <b=
r>
| to resume. Data must be from a session_new_cb callback.<br>
...<br>
| session_new_cb (callable) - Callback invoked when a new session is<br>
| established.<br>
| ...<br>
| - $sessionData: Serialized session (OpenSSL format via <br>
|=C2=A0 =C2=A0i2d_SSL_SESSION)<br>
<br>
1. Would it be possible to ensure this data is from the callback?<br>
<br></blockquote><div><br></div><div>Yes, I introduced=C2=A0OpenSSLSession =
which represent the actual session so sessionData can be only instance of t=
his class.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex">
2. I am asking mostly whether we think it is wise that this internal <br>
openssl data is exposed to the user, for which this is mainly an opaque <br=
>
blob of data=C2=A0=E2=80=94 or in other words, an implementation detail of =
*OpenSSL*.<br>
<br></blockquote><div><br></div><div>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=C2=A0 an=
d PEM.</div><div><br></div><div>Just a note that constant (not enum) is use=
d because that constant already exist and it&#39;s used in other function s=
o adding enum would be out of scope and inconsistent here (please don&#39;t=
 ask for it :) ).</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex">
| Client Behavior<br>
| ...<br>
| 3. Server-only options (&#39;&#39;session_get_cb&#39;&#39;, &#39;&#39;ses=
sion_remove_cb&#39;&#39;,<br>
| &#39;&#39;session_cache&#39;&#39;, &#39;&#39;num_tickets&#39;&#39;, etc.)=
 are ignored<br>
<br>
I don&#39;t think it is wise to *ignore* these, and I would prefer an error=
 <br>
situation to be caused by supplying options that have no effect.<br>
<br></blockquote><div><br></div><div>There is now error thrown for some ill=
ogical combination that can be checked easily. Unknown stream options are a=
lways ignored but I agree that in some cases it could be confusing so throw=
ing ValueError there.</div><div>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">
| Server Behaviour<br>
| ...<br>
| With External Cache (session_get_cb provided): <br>
| - session_new_cb becomes required (E_WARNING if missing)<br>
| - session_context_id becomes required (E_WARNING if missing)<br>
<br>
If is is required, it shouldn&#39;t be a warning as it is a programming <br=
>
error for which an Error-type exception ought to be thrown. On many <br>
occasions warnings appear in a logging black hole.<br>
<br></blockquote><div><br></div><div>This has been changed to exceptions</d=
iv><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
| - session_cache_size and session_timeout are ignored (application <br>
| manages storage)<br>
<br>
For similar reasons, I don&#39;t think these should be just ignored either =
<br>
(again: it&#39;s a programming error).<br></blockquote><div><br></div><div>=
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 cha=
nge it. I removed this note from RFC because it&#39;s just how things work =
there. I also addressed some missing cases that now throws but can&#39;t re=
ally go any further as it would make things inconsistent with the rest of t=
he code.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">
| Backward Incompatible Changes<br>
| ...<br>
| - New options are ignored in older PHP versions (standard stream <br>
|=C2=A0 =C2=A0context behavior)<br>
<br>
That&#39;s not a Backward Compatibility issue, but a *Forward Compatibility=
* <br>
issue. <br>
<br></blockquote><div><br></div><div>I removed that note.</div><div>=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex">
| Potential Considerations: <br>
| ...<br>
| - The new callbacks use resources passed as parameters - these must <br>
|=C2=A0 =C2=A0not be stored beyond the callback scope (documented limitatio=
n)<br>
<br>
Would it be possible to do this *without* introducing new <br>
resources/resource types?<br><br></blockquote><div><br></div><div>This was =
meant for provided stream but it can be actually used so I removed it.</div=
><div><br></div><div>Cheers</div><div><br></div><div>Jakub=C2=A0</div></div=
></div>

--0000000000004bfdba064ab96eb0--