Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126910
Feedback-ID: id5114917:Fastmail
Date: Sun, 23 Mar 2025 12:04:10 +0000
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Potential RFC: mb_rawurlencode() ?
User-Agent: K-9 Mail for Android
In-Reply-To: <4D8DD31A-E982-4D63-8671-2A35A886C609@pmjones.io>
References: <C47E5955-E75E-49A7-88D3-6957669057F0@pmjones.io> <CAEPPVa1p9tiTZLs69Mjo05KTyLi2RwLJ+Z4SSWKEwCZdR9RnOw@mail.gmail.com> <CAEPPVa38tgc=K5Hgcf+-d7JNfi+v97fjFQpwA0J7cOMCz1FxNw@mail.gmail.com> <EEC27D2D-BDBE-41F4-95F1-45EBD0B328BC@pmjones.io> <c0b86fc1b3a5eb1d144f80c931febeaa@bastelstu.be> <36e83b76-6bab-42a3-9c5d-07a35d43851f@rwec.co.uk> <4D8DD31A-E982-4D63-8671-2A35A886C609@pmjones.io>
Message-ID: <508C6326-89F9-4CCB-A3C7-4982850F5B39@rwec.co.uk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")



On 22 March 2025 16:08:54 GMT, "Paul M=2E Jones" <pmjones@pmjones=2Eio> wr=
ote:

>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 i=
s a good alternative, and can it be achieved independently from (but in sup=
port 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", no=
t "UrlParser"/"UriParser", so could maybe be expanded to creating *from* pa=
rts=2E I don't know where exactly IRIs should fit in, but maybe as a new ob=
ject in the same hierarchy?

There's also definitely a place for standalone functions for handling spec=
ific jobs on fragments of URIs=2E It would actually be really great to have=
 a replacement for parse_str which didn't carry the baggage of old PHP vers=
ions - no by-reference output, no name mangling of keys (at least not by de=
fault)=2E 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=2E

Whether each function should take an enum flag for encoding variants, or b=
e split into a family of similar functions, I don't know=2E At the moment, =
http_build_query accepts constants, (raw)urlencode is split into two functi=
ons, and parse_str doesn't give any option=2E

I don't want to have to memorise a bunch of RFC numbers in order to know w=
hether spaces will be encoded as plus signs, but maybe we can find somethin=
g more descriptive than "raw" to distinguish them=2E

In short, I wouldn't start from the point of "how do we extend current fun=
ctions 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]