Re: Potential RFC: mb_rawurlencode() ?
On 22 March 2025 16:08:54 GMT, "Paul M. Jones" <[email protected]> wrote:
>Next up: what exactly should the API around this functionality look like? I suggested functions
>but that's clearly a non-starter; what do we feel is a good alternative, and can it be achieved
>independently from (but in support of) the URI+WHATWG-URL proposal?
As I say, I haven't followed the previous conversation at all, but from a glance at the RFC, it
seems the proposed classes are called "Url"/"Uri", not
"UrlParser"/"UriParser", so could maybe be expanded to creating *from* parts. I
don't know where exactly IRIs should fit in, but maybe as a new object in the same hierarchy?
There's also definitely a place for standalone functions for handling specific jobs on
fragments of URIs. It would actually be really great to have a replacement for parse_str which
didn't carry the baggage of old PHP versions - no by-reference output, no name mangling of keys
(at least not by default). http_build_query isn't as urgently in need of replacement, but a
clean start could default the separator to '&' rather than pulling from an INI
setting.
Whether each function should take an enum flag for encoding variants, or be split into a family of
similar functions, I don't know. At the moment, http_build_query accepts constants,
(raw)urlencode is split into two functions, and parse_str doesn't give any option.
I don't want to have to memorise a bunch of RFC numbers in order to know whether spaces will be
encoded as plus signs, but maybe we can find something more descriptive than "raw" to
distinguish them.
In short, I wouldn't start from the point of "how do we extend current functions to handle
IRIs?", I'd start from the point of "what functions do we need for handling
URI/URL/IRI parts, and what variations of each?"
Rowan Tommins
[IMSoP]
Thread (6 messages)