PHP Wiki

openssl_get_channel_binding

sjoerd (sjoerd@undisclosed.example.com) — 2026-10-30T10:43:33+00:00

rfc

sjoerd (sjoerd@undisclosed.example.com) — 2026-10-30T09:48:20+00:00

2026/10/29 20:09		current
Line 21:		Line 21:

	* [[rfc:password_bcrypt_wrap\|Add PASSWORD_BCRYPT_WRAP]] (Created 2026-10-29, Discussion started 2026-10-29)		* [[rfc:password_bcrypt_wrap\|Add PASSWORD_BCRYPT_WRAP]] (Created 2026-10-29, Discussion started 2026-10-29)
		+	* [[rfc:openssl_get_channel_binding\|openssl_get_channel_binding()]] (Created 2026-10-23, Discussion started 2026-10-27)
	* [[rfc:scope\|Scope]] (Created 2026-10-23, Discussion started 2026-10-26)		* [[rfc:scope\|Scope]] (Created 2026-10-23, Discussion started 2026-10-26)
	* [[rfc:array_partition\|array_partition()]] (Created 2026-10-25, Discussion started 2026-10-25)		* [[rfc:array_partition\|array_partition()]] (Created 2026-10-25, Discussion started 2026-10-25)

password_bcrypt_wrap - Created page

narf (narf@undisclosed.example.com) — 2026-10-29T19:52:28+00:00

2026/10/29 20:19		current
Line 94:		Line 94:

	- Generate 16 bytes of random salt.		- Generate 16 bytes of random salt.
-	- Prehash input password with chosen algorithm, and salt prepended by ''bcrypt-wrap:<version>:'' (first version is 0).	+	- Prehash input password with chosen algorithm, and salt prepended by ''bcrypt-wrap:0:'' (where 0 is current version).
	- B64-encode prehash.		- B64-encode prehash.
	- Bcrypt-Base64-encode the salt.		- Bcrypt-Base64-encode the salt.

time_instant_class - Specify the 32-bit limit in `until()`'s docblock.

timwolla (timwolla@undisclosed.example.com) — 2026-10-29T12:46:07+00:00

2026/10/29 12:46		current
Line 271:		Line 271:
	The exact representable range is unspecified and will be left to implementation constraints. It will be capable of at least representing all instants that <php>DateTimeImmutable</php> is capable of representing. This also means that the time between two instants will be able to exceed the range of <php>Time\Duration</php>. Future PHP versions may increase the supported range, but may not decrease it.		The exact representable range is unspecified and will be left to implementation constraints. It will be capable of at least representing all instants that <php>DateTimeImmutable</php> is capable of representing. This also means that the time between two instants will be able to exceed the range of <php>Time\Duration</php>. Future PHP versions may increase the supported range, but may not decrease it.

-	The ISO-8601 parser (<php>fromIso8601DateTimeString()</php>) is strict: It will only accept well-formed inputs, but may not support all legal formats. Specifying an UTC offset is required, PHP’s default timezone will not be used, since this would effectively invent information out of thin air. It naturally will support all possible return values of <php>toIso8601DateTimeString()</php>. Support for additional formats may be added in future PHP versions by a simple pull request.	+	The ISO-8601 parser (<php>fromIso8601DateTimeString()</php>) is strict: It will only accept well-formed inputs, but may not support all legal formats. Specifying a zone offset is required, PHP’s default timezone will not be used, since this would effectively invent information out of thin air. It naturally will support all possible return values of <php>toIso8601DateTimeString()</php>. Support for additional formats may be added in future PHP versions by a simple pull request.

	The <php>fromUnixTimestampMilliseconds()</php> constructor and <php>toUnixTimestampMilliseconds()</php> getter are provided for interoperability with programming languages using Unix timestamps with millisecond precision, in particular JavaScript.		The <php>fromUnixTimestampMilliseconds()</php> constructor and <php>toUnixTimestampMilliseconds()</php> getter are provided for interoperability with programming languages using Unix timestamps with millisecond precision, in particular JavaScript.
Line 443:		Line 443:
	===== Changelog =====		===== Changelog =====

-	* 2026-10-29: Clarify (in prose) that the ISO-8601 constructor requires an offset, not a timezone.	+	* 2026-10-29: Clarify (in prose) that the ISO-8601 constructor requires a zone offset, not a timezone.
	* 2026-10-29: Add exposing the nominal SystemClock resolution to future scope.		* 2026-10-29: Add exposing the nominal SystemClock resolution to future scope.
	* 2026-10-07: Make SystemClock a singleton.		* 2026-10-07: Make SystemClock a singleton.

scope - Changed implementation cost analysis for core

frodeborli (frodeborli@undisclosed.example.com) — 2026-10-28T13:06:42+00:00

2026/10/27 11:51		current
Line 1:		Line 1:
	====== PHP RFC: Scope ======		====== PHP RFC: Scope ======

-	* Version: 0.9.3	+	* Version: 0.9.4
-	* Date: 2026-10-27	+	* Date: 2026-10-28
	* Author: Frode Børli, <frode@ennerd.com>		* Author: Frode Børli, <frode@ennerd.com>
	* Status: Under Discussion		* Status: Under Discussion
Line 275:		Line 275:
	References and globals. ''%%$GLOBALS['_GET']%%'' and ''%%global $_GET%%'' refer to the current scope's value. A reference taken before switching scopes, such as ''%%$g = &$_GET%%'', continues to refer to the earlier array. Switching scopes changes the global binding, not existing references.		References and globals. ''%%$GLOBALS['_GET']%%'' and ''%%global $_GET%%'' refer to the current scope's value. A reference taken before switching scopes, such as ''%%$g = &$_GET%%'', continues to refer to the earlier array. Switching scopes changes the global binding, not existing references.

-	Implementation. The engine can swap six ''%%zval%%'' entries in the global symbol table on each scope switch, saving the old entries in the outgoing scope and loading those of the incoming scope. Arrays are not copied. Reads and writes retain their current cost. The extension's tests cover ''%%PG(http_globals)%%'', the lazily created auto-globals, ''%%unset($_GET)%%'' and ''%%global $_GET%%''; the php-src implementation must pass the same tests. Under ZTS, each thread has its own symbol table and root scope. Whether a save handler locks is declared by a new field of ''%%ps_module%%'': the files handler sets it, and modules such as the PECL redis and memcached handlers can set it from their own locking settings. A user handler built on ''%%SessionHandler%%'' locks when the handler it wraps does; other user handlers are taken not to lock.	+	Implementation. In the engine each scope holds its own six ''%%zval%%''s, and the current scope is a pointer in the executor globals. The global symbol table's entries for the six, and ''%%PG(http_globals)%%'', resolve through the current scope, so a scope switch changes where these values are read from: nothing is moved, copied or compared, and a switch costs a few pointer stores, the same whatever the scopes hold. Reads and writes retain their current cost, plus one pointer load. ext/session reaches its state (''%%$_SESSION%%'', the id, the status, the save handler and its data) through the current scope the same way. The extension cannot change where the engine reads these values, so it moves them between the symbol table and the scopes at every switch instead; its measurements below are an upper bound for the engine. The extension's tests cover ''%%PG(http_globals)%%'', the lazily created auto-globals, ''%%unset($_GET)%%'' and ''%%global $_GET%%''; the php-src implementation must pass the same tests. Under ZTS, each thread has its own symbol table and root scope. Whether a save handler locks is declared by a new field of ''%%ps_module%%'': the files handler sets it, and modules such as the PECL redis and memcached handlers can set it from their own locking settings. A user handler built on ''%%SessionHandler%%'' locks when the handler it wraps does; other user handlers are taken not to lock.

	Why include them now? These are the request values that long-running servers already need to isolate. Moving them first tests the scope-switching mechanism against existing PHP behavior. The same approach can later apply to other engine state. Vote A covers request input and sessions together.		Why include them now? These are the request values that long-running servers already need to isolate. Moving them first tests the scope-switching mechanism against existing PHP behavior. The same approach can later apply to other engine state. Vote A covers request input and sessions together.
Line 437:		Line 437:
	===== Patches and Tests =====		===== Patches and Tests =====

-	An extension implementing this RFC, including both secondary votes, is released for PHP 8.2 to 8.5 as ''%%fiber-interop/ext-scope%%'' 0.4.4 (https://github.com/fiber-interop/ext-scope, ''%%pie install fiber-interop/ext-scope%%''), with phpt tests for each rule in this text. A userland polyfill with the same class and tests is ''%%fiber-interop/scope%%'' 0.4.0. A pull request against php-src master will accompany the RFC before the vote.	+	An extension implementing this RFC, including both secondary votes, is released for PHP 8.2 to 8.5 as ''%%fiber-interop/ext-scope%%'' 0.5.0 (https://github.com/fiber-interop/ext-scope, ''%%pie install fiber-interop/ext-scope%%''), with phpt tests for each rule in this text. A userland polyfill with the same class and tests is ''%%fiber-interop/scope%%'' 0.4.0. A pull request against php-src master will accompany the RFC before the vote.

	===== Implementation =====		===== Implementation =====
Line 464:		Line 464:
	The last row is a generator created in one scope and stepped from another, so every step switches the six superglobals, the session, and the locale and timezone in and back out. It is the cost of interleaving operations, paid only when the current scope changes.		The last row is a generator created in one scope and stepped from another, so every step switches the six superglobals, the session, and the locale and timezone in and back out. It is the cost of interleaving operations, paid only when the current scope changes.

-	These figures measure the extension's hash-table-based approach, not the proposed php-src implementation. In core, each fiber and generator can hold a scope pointer directly. The php-src patch will include its own measurements.	+	These figures measure the extension's approach, not the proposed php-src implementation. The extension keeps each fiber's scope in a hash table and, at every change of scope, moves the six superglobals and copies ext/session's, the locale's and the timezone's state between the live globals and the scopes. In core, each fiber and generator holds a scope pointer directly, and the per-scope state is reached through the current scope (see vote A's implementation note), so a switch is a few pointer stores and costs the same whatever the scopes hold. The php-src patch will include its own measurements.

	==== Threads ====		==== Threads ====
Line 473:		Line 473:
	* Scope multiplexes one thread's state between operations; threads multiplex one process's state between executors. A server may use both: worker threads, each serving several requests as scopes.		* Scope multiplexes one thread's state between operations; threads multiplex one process's state between executors. A server may use both: worker threads, each serving several requests as scopes.
	* For extension authors, per-scope state is the module-globals pattern with a shorter lifetime: declared the same way, constructed when a scope first touches it, destroyed when the scope is released. The follow-up RFC describes it in that vocabulary.		* For extension authors, per-scope state is the module-globals pattern with a shorter lifetime: declared the same way, constructed when a scope first touches it, destroyed when the scope is released. The follow-up RFC describes it in that vocabulary.
-	* Cost: state converted to follow the scope is swapped on switch, not reached through an indirection, so access costs what it costs today on both builds and a switch costs a bounded number of word moves proportional to the converted state. State that hands out pointers into itself cannot be moved by value and is reached indirectly; the follow-up RFC lists such cases.	+	* Cost: state converted to follow the scope is reached through the current scope, so access costs one pointer load more than today on both builds, and a switch costs a few pointer stores whatever the scopes hold. State small enough to be swapped by value at no measurable cost, such as the default timezone, may be swapped instead; the follow-up RFC lists the choice for each kind of state.
	* Scope adds no concurrency. State that follows the scope is never visible to another operation, so code that was correct under one request per process stays correct for that state. State kept shared on purpose stays shared, as it is across requests in any long-running process today.		* Scope adds no concurrency. State that follows the scope is never visible to another operation, so code that was correct under one request per process stays correct for that state. State kept shared on purpose stays shared, as it is across requests in any long-running process today.

Line 495:		Line 495:
	* 0.9.2 (2026-10-27): Introduction rewritten; no change to the proposal.		* 0.9.2 (2026-10-27): Introduction rewritten; no change to the proposal.
	* 0.9.3 (2026-10-27): vote A: ''%%session_start()%%'' throws a ''%%RuntimeException%%'' instead of blocking the process when a locking save handler's session id is active in another scope of the process (ext-scope 0.4.4); listed under Open Issues.		* 0.9.3 (2026-10-27): vote A: ''%%session_start()%%'' throws a ''%%RuntimeException%%'' instead of blocking the process when a locking save handler's session id is active in another scope of the process (ext-scope 0.4.4); listed under Open Issues.
		+	* 0.9.4 (2026-10-28): implementation: in the engine, per-scope state is reached through the current scope, so a switch costs a few pointer stores whatever the scopes hold, and an access one pointer load more (Threads, "Cost"); the extension moves the state at each switch instead (ext-scope 0.5.0).

array_partition - Document reference handling, add it as an open issue

ayoubezzini (ayoubezzini@undisclosed.example.com) — 2026-10-27T16:22:12+00:00

2026/10/27 10:31		current
Line 62:		Line 62:
	</code>		</code>

-	The only observable difference is that the native function keeps by-reference elements of the input as references, like ''array_filter()''.	+	The only observable difference is that the native function keeps by-reference elements of the input as references, like ''array_filter()'' (see "By-reference elements" below and "Open Issues").

	The callback is called once for each element, in array order, and receives the value and the key, like ''array_find()'', ''array_find_key()'', ''array_any()'' and ''array_all()''. The function returns a list of exactly two arrays:		The callback is called once for each element, in array order, and receives the value and the key, like ''array_find()'', ''array_find_key()'', ''array_any()'' and ''array_all()''. The function returns a list of exactly two arrays:
Line 92:		Line 92:
	* The return value of the callback is interpreted with the usual boolean conversion, as in ''array_filter()''.		* The return value of the callback is interpreted with the usual boolean conversion, as in ''array_filter()''.
	* ''array_partition($a, $cb)[0]'' is identical (''==='') to ''array_filter($a, $cb, ARRAY_FILTER_USE_BOTH)'', and ''array_partition($a, $cb)[1]'' is identical to ''array_diff_key($a, array_partition($a, $cb)[0])''.		* ''array_partition($a, $cb)[0]'' is identical (''==='') to ''array_filter($a, $cb, ARRAY_FILTER_USE_BOTH)'', and ''array_partition($a, $cb)[1]'' is identical to ''array_diff_key($a, array_partition($a, $cb)[0])''.
-	* An empty input returns ''%%[[], []]%%'', so the result can always be destructured into two variables.	+	* An empty input returns <php>[[], []]</php>, so the result can always be destructured into two variables.
	* If the callback throws, the exception is propagated, no further elements are visited and no partial result is returned.		* If the callback throws, the exception is propagated, no further elements are visited and no partial result is returned.
-	* By-reference elements of the input are handled in the same way as in ''array_filter()''.	+	* Elements that are references in the input stay references in the result, as with ''array_filter()''. See "By-reference elements" below.
	* There is no ''$mode'' parameter. The callback always receives both the value and the key, following ''array_find()'' rather than ''array_filter()''. A callback that accepts only the value works unchanged, because userland functions ignore extra arguments.		* There is no ''$mode'' parameter. The callback always receives both the value and the key, following ''array_find()'' rather than ''array_filter()''. A callback that accepts only the value works unchanged, because userland functions ignore extra arguments.

Line 107:		Line 107:
	array_partition(['x'], is_string(?)); // works, partial function application (PHP 8.6+)		array_partition(['x'], is_string(?)); // works, partial function application (PHP 8.6+)
	</code>		</code>
		+
		+	==== By-reference elements ====
		+
		+	An element that is a reference in the input, and is still referenced elsewhere, is a reference in the result too. Writing to it through the result changes the input, and the other way round:
		+
		+	<code php>
		+	$input = [1, 2, 3];
		+	$ref = &$input[0];
		+
		+	[$matching, $rest] = array_partition($input, fn($v) => $v === 1);
		+
		+	$matching[0] = 'changed';
		+	var_dump($input[0]); // string(7) "changed"
		+
		+	$ref = 'again';
		+	var_dump($matching[0]); // string(5) "again"
		+	</code>
		+
		+	A reference that is no longer shared, for example after ''unset($ref)'', is copied as a plain value:
		+
		+	<code php>
		+	$input = [1, 2, 3];
		+	$ref = &$input[0];
		+	unset($ref);
		+
		+	[$matching, $rest] = array_partition($input, fn($v) => $v === 1);
		+
		+	$matching[0] = 'changed';
		+	var_dump($input[0]); // int(1)
		+	</code>
		+
		+	This is the same behaviour as ''array_filter()'', ''array_diff_key()'', ''array_slice()'', ''array_values()'' and ''array_chunk()''. Whether ''array_partition()'' should keep it is listed under "Open Issues".

	==== Why the matching elements come first ====		==== Why the matching elements come first ====
Line 195:		Line 227:
	===== Open Issues =====		===== Open Issues =====

-	None at this time.	+	* Reference handling. The proposed implementation keeps references, as described in "By-reference elements". This matches the array functions that return part of their input (''array_filter()'', ''array_diff_key()'', ''array_slice()'', ''array_values()'', ''array_chunk()''), and means that replacing the ''array_filter()'' + ''array_diff_key()'' idiom with ''array_partition()'' does not change behaviour. On the other hand, the behaviour cannot be reproduced exactly in userland, and writing to a result element can modify the input. ''array_find()'' drops references, but it returns a single value rather than an array. Dropping references instead would be a one-line change in the implementation. Feedback on which behaviour is preferred is welcome.

	===== Future Scope =====		===== Future Scope =====

reldateformatter - Add voting and implementation links

weilindu (weilindu@undisclosed.example.com) — 2026-10-27T16:07:30+00:00

2026/10/22 01:45		current
Line 6:		Line 6:
	* Implementation: https://github.com/php/php-src/pull/23514		* Implementation: https://github.com/php/php-src/pull/23514
	* Discussion thread: https://externals.io/message/132187		* Discussion thread: https://externals.io/message/132187
-	* Voting thread: TBD	+	* Voting thread: https://externals.io/message/132830

	===== Introduction =====		===== Introduction =====
Line 436:		Line 436:
	===== Patches and Tests =====		===== Patches and Tests =====

-	TBD.	+	Implementation: https://github.com/php/php-src/pull/23514

	===== Implementation =====		===== Implementation =====

min_supported_versions_php_8_6 - Add one implementation link

timwolla (timwolla@undisclosed.example.com) — 2026-10-27T16:06:18+00:00

2026/07/30 15:59		current
Line 84:		Line 84:
	===== Implementation =====		===== Implementation =====

-	N/A	+	* autoconf 2.71: https://github.com/php/php-src/commit/b092f3fff1fe6c53cdc684ea59fed77a3c8b4564

	===== References =====		===== References =====

query_params

kocsismate (kocsismate@undisclosed.example.com) — 2026-10-26T15:05:27+00:00

2026/10/26 12:42		current
Line 146:		Line 146:

	#[\NoDiscard]		#[\NoDiscard]
-	public function sort(): static {}	+	public function sortByBytes(): static {}
		+
		+	#[\NoDiscard]
		+	public function sortByUtf16(): static {}

	/**		/**
Line 260:		Line 263:
	</code>		</code>

-	When encountering malformed percent-encoded sequences, such as ''%'', ''%2'', or ''%GG'', ''Uri\QueryParams::parseRfc1866()'' and ''Uri\QueryParams::parseRfc3986()'' throw an ''Uri\InvalidQueryParamsException''. This behavior is a design decision on PHP's side, as there's no relevant mandate either in RFC 1866 or in RFC 3986.	+	When encountering malformed percent-encoded sequences, such as ''%'', ''%2'', or ''%GG'', ''Uri\QueryParams::parseRfc1866()'' and ''Uri\QueryParams::parseRfc3986()'' throw an ''Uri\InvalidQueryParamsException''.

	<code php>		<code php>
	$params = Uri\QueryParams::parseRfc3986("foo=%&bar=%2&baz=%GG");		$params = Uri\QueryParams::parseRfc3986("foo=%&bar=%2&baz=%GG");

-	var_dump($params->getFirst("foo")); // string(1) "%"	+	// Throws Uri\InvalidQueryParamsException
-	var_dump($params->getFirst("bar")); // string(2) "%2"	+
-	var_dump($params->getFirst("baz")); // string(3) "%GG"	+
-		+
-	echo $params->toRfc3986String(); // foo=%25&bar=%252&baz=%25GG	+
	</code>		</code>

-	On the other hand, WHATWG URL has detailed requirements for handling malformed percent-encoded sequences that ''Uri\QueryParams::parseWhatWgUrlSearchParams()'' respects: these sequences are also preserved during parsing.	+	On the other hand, WHATWG URL has detailed requirements for handling malformed percent-encoded sequences that ''Uri\QueryParams::parseWhatWgUrlSearchParams()'' respects: these sequences are preserved during parsing.

	<code php>		<code php>
Line 311:		Line 310:
	This replacement loses the original invalid bytes: recomposing the query string encodes the replacement character rather than recovering the original ''%FF''.		This replacement loses the original invalid bytes: recomposing the query string encodes the replacement character rather than recovering the original ''%FF''.

-	According to WHATWG URL's [[https://url.spec.whatwg.org/#dom-urlsearchparams-urlsearchparams\|new URLSearchParams(init)]] algorithm, exactly one leading "?" character is removed during the ''QueryParams::parseWhatWgUrlSearchParams()'' call. In contrast to this behavior, the leading "?" becomes part of the first query parameter name for RFC 1866 and RFC 3986 query params.	+	According to WHATWG URL's [[https://url.spec.whatwg.org/#dom-urlsearchparams-urlsearchparams\|new URLSearchParams(init)]] algorithm, exactly one leading "?" character is removed during the ''QueryParams::parseWhatWgUrlSearchParams()'' call.

	<code php>		<code php>
-	$params = Uri\QueryParams::parseRfc3986("?abc=foo");
-	// $params internally contains the ["?abc" => "foo"] key-value pair
-
	$params = Uri\QueryParams::parseWhatWgUrlSearchParams("?abc=foo");		$params = Uri\QueryParams::parseWhatWgUrlSearchParams("?abc=foo");
		+
	// $params internally contains the ["abc" => "foo"] key-value pair		// $params internally contains the ["abc" => "foo"] key-value pair
	</code>		</code>
Line 627:		Line 624:
	</code>		</code>

-	Finally, ''sort()'' sorts the query parameter list by parameter name in ascending lexicographical order, comparing byte values. The comparison is case-sensitive and locale-independent:	+	Finally, ''Uri\QueryParams::sortByBytes()'' and ''Uri\QueryParams:: sortByUtf16()'' sort the query parameter list by parameter name in ascending lexicographical order, comparing byte values. The comparison is case-sensitive and locale-independent.

	<code php>		<code php>
	$params = Uri\QueryParams::parseRfc3986("foo=bar&baz=qux&baz=quux");		$params = Uri\QueryParams::parseRfc3986("foo=bar&baz=qux&baz=quux");
-	$params = $params->sort();	+	$params = $params->sortByBytes();

	echo $params->toRfc3986String(); // baz=qux&baz=quux&foo=bar		echo $params->toRfc3986String(); // baz=qux&baz=quux&foo=bar
	</code>		</code>

-	Parameters with the same name (''baz'' in the above example) keep their original order rather than being ordered by value. This is necessary because parameters with the same name usually refer to lists, and modifying the order of list items would definitely change the original meaning.	+	The difference between the two implementations is the 'Uri\QueryParams::sortByBytes()'' compares bytes to bytes, while ''Uri\QueryParams:: sortByUtf16()'' uses UTF-16-based comparison, as specified by WHATWG URL. UTF-8 and UTF-16 comparison does not always match, as called out by WHATWG (https://infra.spec.whatwg.org/#example-code-unit-less-than):

-	This differs from WHATWG URL's ''URLSearchParams::sort()'', which compares UTF-16 code units. Consequently, the two methods can produce different orders for non-ASCII names.	+	<blockquote>
		+	For example, the code point U+FF5E FULLWIDTH TILDE (～) is obviously less than the code point U+1F600 (😀), but the tilde is composed of a single code unit 0xFF5E, while the smiley is composed of two code units 0xD83D and 0XDE00, so the smiley is code unit less than the tilde.
		+	</blockquote>
		+
		+	Parameters with the same name (''baz'' in the above example) keep their original order rather than being ordered by value. This is necessary because parameters with the same name usually refer to lists, and modifying the order of list items would definitely change the original meaning.

-	The main purpose of ''sort()'' is to provide a consistent order of the key-value pairs (e.g. to increase cache hits), therefore more advanced features such as sorting in descending order, or user-provided comparison methods are not proposed.	+	The main purpose of the sort methods is to provide a consistent order of the key-value pairs (e.g. to increase cache hits), therefore more advanced features such as sorting in descending order, or user-provided comparison methods are not proposed.

	=== Supported types ===		=== Supported types ===
Line 878:		Line 879:

	<code php>		<code php>
-	$params = Uri\QueryParams::parseRfc3986("a[b][c]=1");	+	$params = Uri\QueryParams::parseRfc3986("a%5Bb%5D%5Bc%5D=1"); // Percent-encoded form of "a[b][c]=1"

	$array = $params->toArray(maxNestingLevel: 2); // ["a" => ["b" => ["c" => "1"]]]		$array = $params->toArray(maxNestingLevel: 2); // ["a" => ["b" => ["c" => "1"]]]
Line 901:		Line 902:
	The ''QueryParams'' class is ''final'' [[https://wiki.php.net/rfc/url_parsing_api#why_should_the_uri_rfc3986_uri_and_the_uri_whatwg_url_classes_be_final\|for the same reason]] as all the other URI classes are final: mainly, in order to make followup changes possible without breaking backward compatibility.		The ''QueryParams'' class is ''final'' [[https://wiki.php.net/rfc/url_parsing_api#why_should_the_uri_rfc3986_uri_and_the_uri_whatwg_url_classes_be_final\|for the same reason]] as all the other URI classes are final: mainly, in order to make followup changes possible without breaking backward compatibility.

-	Additionally, ''QueryParams'' is a ''readonly'' class, meaning that instances are immutable value objects: modification methods such as ''append()'', ''set()'', and ''delete()'' return a new ''QueryParams'' instance rather than mutating the existing one. This design is consistent with the immutable value-object semantics of ''Uri\Rfc3986\Uri'' and ''Uri\WhatWg\Url'', prevents different layers of an application from accidentally observing each other's modifications when sharing a reference to the same instance, and makes modification explicit at the call site. Modification methods whose name doesn't start with a "with" prefix are marked with ''#[\NoDiscard]'' to warn end users not to forget to use the result. These methods (''append()'', ''set()'', ''delete()'', ''deleteValue()'', ''sort()'') are "withers" in fact, but using the usual prefix would have made the method names sound clunky (e.g. ''withAppend()'' or ''withAppendedParam()'').	+	Additionally, ''QueryParams'' is a ''readonly'' class, meaning that instances are immutable value objects: modification methods such as ''append()'', ''set()'', and ''delete()'' return a new ''QueryParams'' instance rather than mutating the existing one. This design is consistent with the immutable value-object semantics of ''Uri\Rfc3986\Uri'' and ''Uri\WhatWg\Url'', prevents different layers of an application from accidentally observing each other's modifications when sharing a reference to the same instance, and makes modification explicit at the call site. Modification methods whose name doesn't start with a "with" prefix are marked with ''#[\NoDiscard]'' to warn end users not to forget to use the result. These methods (''append()'', ''set()'', ''delete()'', ''deleteValue()'', ''sortByBytes()'', ''sortByUtf16()'') are "withers" in fact, but using the usual prefix would have made the method names sound clunky (e.g. ''withAppend()'' or ''withAppendedParam()'').

	The ''QueryParams'' class implements the ''IteratorAggregate'' and the ''Countable'' interfaces. Implementing ''IteratorAggregate'' seems straightforward at the first sight (query parameter names could be returned as iterator keys, while query parameter values could be returned as iterator values), unfortunately, it's more tricky than that due to query components that share the same name, e.g.: ''param=foo&param=bar&param=baz''. In this case, the same key (''param'') would be repeated 3 times - which would actually be very unwieldy behavior.		The ''QueryParams'' class implements the ''IteratorAggregate'' and the ''Countable'' interfaces. Implementing ''IteratorAggregate'' seems straightforward at the first sight (query parameter names could be returned as iterator keys, while query parameter values could be returned as iterator values), unfortunately, it's more tricky than that due to query components that share the same name, e.g.: ''param=foo&param=bar&param=baz''. In this case, the same key (''param'') would be repeated 3 times - which would actually be very unwieldy behavior.

context-managers-v2

lbarnaud (lbarnaud@undisclosed.example.com) — 2026-10-24T18:15:55+00:00

2026/10/24 19:43		current
Line 567:		Line 567:

	===== Voting Choices =====		===== Voting Choices =====
-	Pick a title that reflects the concrete choice people will vote on.
-
-	Please consult [[https://github.com/php/policies/blob/main/feature-proposals.rst#voting-phase\|the php/policies repository]] for the current voting guidelines.
-
-	----

	Primary Vote requiring a 2/3 majority to accept the RFC:		Primary Vote requiring a 2/3 majority to accept the RFC:

surface3d.png - created

pajoye (pajoye@undisclosed.example.com) — 2026-07-19T13:48:10+00:00

	current

scaled_on_load_rotate.png - created

pajoye (pajoye@undisclosed.example.com) — 2026-07-17T06:47:24+00:00

	current

watermarked.png - created

pajoye (pajoye@undisclosed.example.com) — 2026-07-17T03:57:25+00:00

	current

scale_entropy_visual_check.png - created

pajoye (pajoye@undisclosed.example.com) — 2026-07-14T03:12:03+00:00

	current

textcurve.png - created

pajoye (pajoye@undisclosed.example.com) — 2026-07-10T14:08:53+00:00

1783692513	current

gradient_art.png - created

pajoye (pajoye@undisclosed.example.com) — 2026-07-06T06:32:24+00:00

	current

tiger.png - created

pajoye (pajoye@undisclosed.example.com) — 2026-07-06T06:32:03+00:00

	current

gradient_operators.png - created

pajoye (pajoye@undisclosed.example.com) — 2026-07-06T06:31:36+00:00

	current

coroutine-lifecycle.svg - created

edmond (edmond@undisclosed.example.com) — 2025-04-16T07:24:46+00:00

	current

supervisor.svg - created

edmond (edmond@undisclosed.example.com) — 2025-03-16T08:38:59+00:00

	current

2026/10/29 20:09		current
Line 21:		Line 21:

	* [[rfc:password_bcrypt_wrap\|Add PASSWORD_BCRYPT_WRAP]] (Created 2026-10-29, Discussion started 2026-10-29)		* [[rfc:password_bcrypt_wrap\|Add PASSWORD_BCRYPT_WRAP]] (Created 2026-10-29, Discussion started 2026-10-29)
		+	* [[rfc:openssl_get_channel_binding\|openssl_get_channel_binding()]] (Created 2026-10-23, Discussion started 2026-10-27)
	* [[rfc:scope\|Scope]] (Created 2026-10-23, Discussion started 2026-10-26)		* [[rfc:scope\|Scope]] (Created 2026-10-23, Discussion started 2026-10-26)
	* [[rfc:array_partition\|array_partition()]] (Created 2026-10-25, Discussion started 2026-10-25)		* [[rfc:array_partition\|array_partition()]] (Created 2026-10-25, Discussion started 2026-10-25)

2026/10/30 10:36		current
Line 68:		Line 68:
	==== Return value ====		==== Return value ====

-	The function returns the raw, binary channel binding data as a non-null ''string''. Callers that need the SASL ''cb'' property must base64-encode it. It never returns ''null'': when the requested type is not applicable to the connection, it throws ''Openssl\UnsupportedChannelBindingException''. This happens for ''tls-unique'' over TLS 1.3, where that binding type is not defined, and for ''tls-server-end-point'' when no certificate is used, such as in a TLS-PSK handshake.	+	The function returns the raw, binary channel binding data as a non-null ''string''. Callers that need the SASL ''cb'' property must base64-encode it. It never returns ''null'': when the requested type is not applicable to the connection, it throws ''Openssl\UnsupportedChannelBindingException''. This happens for ''tls-unique'' over TLS 1.3, where that binding type is not defined, and for ''tls-server-end-point'' when no certificate is available, for example in a PSK handshake without a certificate.

	==== Changes from the original pull request ====		==== Changes from the original pull request ====
Line 78:		Line 78:
	^ Type ^ Standard ^ Value and applicability ^		^ Type ^ Standard ^ Value and applicability ^
	\| ''tls-unique'' \| [[https://www.rfc-editor.org/rfc/rfc5929#section-3\|RFC 5929 section 3]] \| The Finished message content of the relevant handshake. Defined for TLS 1.2 and earlier, but not for TLS 1.3. Throws ''Openssl\UnsupportedChannelBindingException'' on TLS 1.3. \|		\| ''tls-unique'' \| [[https://www.rfc-editor.org/rfc/rfc5929#section-3\|RFC 5929 section 3]] \| The Finished message content of the relevant handshake. Defined for TLS 1.2 and earlier, but not for TLS 1.3. Throws ''Openssl\UnsupportedChannelBindingException'' on TLS 1.3. \|
-	\| ''tls-server-end-point'' \| [[https://www.rfc-editor.org/rfc/rfc5929#section-4.1\|RFC 5929 section 4.1]] \| A digest of the server certificate as it appears in the Certificate message. Requires a certificate in the handshake. Throws ''Openssl\UnsupportedChannelBindingException'' when no certificate is used, such as in a TLS-PSK handshake. \|	+	\| ''tls-server-end-point'' \| [[https://www.rfc-editor.org/rfc/rfc5929#section-4.1\|RFC 5929 section 4.1]] \| A digest of the server certificate as it appears in the Certificate message. Requires a certificate. Throws ''Openssl\UnsupportedChannelBindingException'' when no certificate is available, for example in a PSK handshake without a certificate. \|
	\| ''tls-exporter'' \| [[https://www.rfc-editor.org/rfc/rfc9266#section-4\|RFC 9266 section 4]], [[https://www.rfc-editor.org/rfc/rfc5705\|RFC 5705]] \| 32 octets from the TLS exporter, using the label ''EXPORTER-Channel-Binding'' and an empty context. Defined for TLS 1.3 and also available on earlier TLS versions when the exporter is available. \|		\| ''tls-exporter'' \| [[https://www.rfc-editor.org/rfc/rfc9266#section-4\|RFC 9266 section 4]], [[https://www.rfc-editor.org/rfc/rfc5705\|RFC 5705]] \| 32 octets from the TLS exporter, using the label ''EXPORTER-Channel-Binding'' and an empty context. Defined for TLS 1.3 and also available on earlier TLS versions when the exporter is available. \|

Line 93:		Line 93:
	The digest algorithm is taken from the certificate's own signature algorithm. If that algorithm is MD5 or SHA-1, or cannot be determined, SHA-256 is used instead, as required by RFC 5929 section 4.1. For a SHA-256-signed certificate the result is identical to ''openssl_x509_fingerprint($cert, "sha256", true)''.		The digest algorithm is taken from the certificate's own signature algorithm. If that algorithm is MD5 or SHA-1, or cannot be determined, SHA-256 is used instead, as required by RFC 5929 section 4.1. For a SHA-256-signed certificate the result is identical to ''openssl_x509_fingerprint($cert, "sha256", true)''.

-	On the client side the peer certificate is used. On the server side the local certificate is used. This binding type is not applicable when the handshake does not use a certificate, such as any TLS-PSK handshake, even if a certificate happens to be configured on the connection. In that case the function throws ''Openssl\UnsupportedChannelBindingException''.	+	On the client side the peer certificate is used. On the server side the local certificate is used. If no certificate is available, for example in a PSK handshake without a certificate, the function throws ''Openssl\UnsupportedChannelBindingException''. Otherwise the binding is computed from the available certificate.

	==== tls-exporter ====		==== tls-exporter ====
Line 105:		Line 105:
	\| ''$channel_binding_type'' is not an ''Openssl\ChannelBindingType'' \| ''TypeError''. A string such as ''"tls-unique"'' is not accepted. \|		\| ''$channel_binding_type'' is not an ''Openssl\ChannelBindingType'' \| ''TypeError''. A string such as ''"tls-unique"'' is not accepted. \|
	\| ''$stream'' is a stream, but it has no active OpenSSL TLS transport (no crypto enabled, or the handshake has not completed) \| ''ValueError'' with the message ''Stream does not have transport encryption enabled'' \|		\| ''$stream'' is a stream, but it has no active OpenSSL TLS transport (no crypto enabled, or the handshake has not completed) \| ''ValueError'' with the message ''Stream does not have transport encryption enabled'' \|
-	\| The requested type is not applicable to the connection \| ''Openssl\UnsupportedChannelBindingException''. This happens for ''tls-unique'' over TLS 1.3 and for ''tls-server-end-point'' when no certificate is used, such as in a TLS-PSK handshake. \|	+	\| The requested type is not applicable to the connection \| ''Openssl\UnsupportedChannelBindingException''. This happens for ''tls-unique'' over TLS 1.3 and for ''tls-server-end-point'' when no certificate is available, for example in a PSK handshake without a certificate. \|
	\| An OpenSSL call fails while computing the value \| ''Openssl\OpensslException'' with the message ''Failed to get channel binding data: <OpenSSL error>'', or ''Failed to get channel binding data'' if OpenSSL provides no error detail \|		\| An OpenSSL call fails while computing the value \| ''Openssl\OpensslException'' with the message ''Failed to get channel binding data: <OpenSSL error>'', or ''Failed to get channel binding data'' if OpenSSL provides no error detail \|

Line 215:		Line 215:
	Channel binding data is not a secret: RFC 5929 section 10 explicitly allows authentication mechanisms to disclose it. The value is nevertheless security-relevant, because it is what prevents a relay attack. Applications must use the same type that the negotiated SASL mechanism expects. An ''Openssl\UnsupportedChannelBindingException'' means that no binding is available for that type; applications must not swallow it and continue authentication without a binding, and must not treat an unsupported binding as an authenticated connection.		Channel binding data is not a secret: RFC 5929 section 10 explicitly allows authentication mechanisms to disclose it. The value is nevertheless security-relevant, because it is what prevents a relay attack. Applications must use the same type that the negotiated SASL mechanism expects. An ''Openssl\UnsupportedChannelBindingException'' means that no binding is available for that type; applications must not swallow it and continue authentication without a binding, and must not treat an unsupported binding as an authenticated connection.

-	''tls-exporter'' is the appropriate choice for TLS 1.3. ''tls-unique'' is only meaningful for TLS 1.2 and earlier. ''tls-server-end-point'' is useful when the application needs a value that does not change after renegotiation and when the handshake uses a server certificate.	+	''tls-exporter'' is the appropriate choice for TLS 1.3. ''tls-unique'' is only meaningful for TLS 1.2 and earlier. ''tls-server-end-point'' is useful when the application needs a value that does not change after renegotiation and when a server certificate is available.

	===== Backward Incompatible Changes =====		===== Backward Incompatible Changes =====
Line 266:		Line 266:
	===== Patches and Tests =====		===== Patches and Tests =====

-	The implementation is [[https://github.com/php/php-src/pull/24035\|pull request #24035]]. It contains PHPT tests for TLS 1.2 and TLS 1.3, including checks that the client and server derive the same ''tls-unique'' and ''tls-exporter'' values, and checks of ''tls-server-end-point'' against the certificate fingerprint. A TLS-PSK test verifies that ''tls-server-end-point'' throws ''Openssl\UnsupportedChannelBindingException'' when the handshake uses no certificate. The tests also cover the error conditions, including ''ValueError'' for a stream without transport encryption and the exception hierarchy. The implementation and tests match the API described in this RFC.	+	The implementation is [[https://github.com/php/php-src/pull/24035\|pull request #24035]]. It contains PHPT tests for TLS 1.2 and TLS 1.3, including checks that the client and server derive the same ''tls-unique'' and ''tls-exporter'' values, and checks of ''tls-server-end-point'' against the certificate fingerprint. A TLS-PSK test verifies that ''tls-server-end-point'' throws ''Openssl\UnsupportedChannelBindingException'' when no certificate is available. The tests also cover the error conditions, including ''ValueError'' for a stream without transport encryption and the exception hierarchy. The implementation and tests match the API described in this RFC.

	The implementation has also been tested manually against Prosody and PostgreSQL.		The implementation has also been tested manually against Prosody and PostgreSQL.
Line 299:		Line 299:
	* Integer constants. Global constants such as ''OPENSSL_CHANNEL_BINDING_TLS_UNIQUE'' would be less discoverable and would not give the parameter a precise type.		* Integer constants. Global constants such as ''OPENSSL_CHANNEL_BINDING_TLS_UNIQUE'' would be less discoverable and would not give the parameter a precise type.
	* Accepting a stream context. The original issue suggested accepting either a stream or a stream context. A context can create multiple connections, so it does not identify one channel. The function therefore requires a connected stream.		* Accepting a stream context. The original issue suggested accepting either a stream or a stream context. A context can create multiple connections, so it does not identify one channel. The function therefore requires a connected stream.
-	* Returning ''null'' for an inapplicable type. It would force every call site to check for ''null'' and would make a successful return ambiguous. ''tls-unique'' over TLS 1.3 and ''tls-server-end-point'' in a handshake without a certificate are protocol-level incompatibilities, not silent successes. The dedicated ''Openssl\UnsupportedChannelBindingException'' lets callers explicitly choose another type.	+	* Returning ''null'' for an inapplicable type. It would force every call site to check for ''null'' and would make a successful return ambiguous. ''tls-unique'' over TLS 1.3 and ''tls-server-end-point'' without a certificate are protocol-level incompatibilities, not silent successes. The dedicated ''Openssl\UnsupportedChannelBindingException'' lets callers explicitly choose another type.
	* Adding an ''Openssl\OpensslError'' class. No such class exists today. A stream without crypto enabled is an invalid argument value, so the standard ''ValueError'' is sufficient. Introducing a new ''Error'' hierarchy is a broader API decision that should not be part of this RFC.		* Adding an ''Openssl\OpensslError'' class. No such class exists today. A stream without crypto enabled is an invalid argument value, so the standard ''ValueError'' is sufficient. Introducing a new ''Error'' hierarchy is a broader API decision that should not be part of this RFC.
	* Supporting ''tls-unique-for-telnet''. It is registered by IANA but is specific to Telnet and is not used by SASL.		* Supporting ''tls-unique-for-telnet''. It is registered by IANA but is specific to Telnet and is not used by SASL.