Re: [RFC] [Discussion] Query Parameter Manipulation Support
| From: | Máté Kocsis | Date: | Tue, 06 Oct 2026 13:37:52 +0000 |
| Subject: | Re: [RFC] [Discussion] Query Parameter Manipulation Support | ||
| References: | 1 2 3 4 5 6 7 8 9 10 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-132810@lists.php.net to get a copy of this message | ||
Hi Ignace,
Finally, I had the capacity to work on this proposal again, after the PHP
8.6 release is now close to the finish line.
I made a lot of changes to the QueryParams RFC, covering a lot of edge
cases, and explicitly documenting many so far undefined behavior. Here is a
short "changelog":
- Immutability: QueryParams is now documented to be readonly (previously it
was TBD)
- Null handling: As proposed by Ignace, QueryParamNullPolicy replaces the
boolean option with three choices: SkipTuple, KeyOnly (the default), and
EmptyString
- Limits and errors: Parsing limits apply only during parsing, while the
nesting limit belongs exclusively to toArray(). Exception behavior is now
specified
- Type conversions: Type conversion rules are documented much more
thoroughly than before
- Array API: Previously open questions are decided and documented,
including nested lists, duplicate keys, conflicting structures, and
malformed bracket notation
- URI/URL integration: The Uri/Url classes will have getQueryParams() and
withQueryParams() methods to make usage and interoperability easier
- Parsing details: The RFC now specifies the handling of empty fields,
missing values, malformed percent-encoding, and invalid UTF-8 etc.
Please give the RFC a thorough read, because I'd like to bring this
proposal to a vote as soon as possible (but not sooner ^^), of course still
giving interested folks a chance
to provide feedback. I'm specifically looking forward to naming
improvements, if there's anything to improve.
Regards,
Máté