Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124255
Feedback-ID: ifab94697:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-566-g3812ddbbc-fm-20240627.001-g3812ddbb
Precedence: bulk
MIME-Version: 1.0
Message-ID: <883a7cc2-c63c-479b-a8be-3a5fdac43c03@app.fastmail.com>
In-Reply-To: 
 <CAH5C8xVVHMn3Q4U2Aa9n3sED3tGdnWoabryTSL6Dk0MrenD+3g@mail.gmail.com>
References: <71a73b87-cc2f-4ee5-a961-7bf2b191fbb6@gmail.com>
 <5159E0AB-C8B0-4A54-9654-986C1D9C858F@koalephant.com>
 <07160e83-7333-44a1-81f2-b121e2cf0ffd@gmail.com>
 <CAH5C8xVVHMn3Q4U2Aa9n3sED3tGdnWoabryTSL6Dk0MrenD+3g@mail.gmail.com>
Date: Sun, 07 Jul 2024 12:40:02 +0200
To: =?UTF-8?Q?M=C3=A1t=C3=A9_Kocsis?= <kocsismate90@gmail.com>,
 nyamsprod@gmail.com
Cc: internals@lists.php.net, "Stephen Reay" <php-lists@koalephant.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API
Content-Type: multipart/alternative;
 boundary=a24729788ef140a1a92eacf04415bffd
From: rob@bottled.codes ("Rob Landers")

--a24729788ef140a1a92eacf04415bffd
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Sun, Jul 7, 2024, at 11:13, M=C3=A1t=C3=A9 Kocsis wrote:
> Hi Ignace,
>=20
>> As far as I understand it, if this RFC were to pass as is it will mod=
el
>> PHP URLs to the WHATWG specification. While this specification is
>> getting a lot of traction lately I believe it will restrict URL usage=
 in
>> PHP instead of making developer life easier. While PHP started as a
>> "web" language it is first and foremost a server side general purpose
>> language. The WHATWG spec on the other hand is created by browsers
>> vendors and is geared toward browsers (client side) and because of
>> browsers history it restricts by design a lot of what PHP developers =
can
>> currently do using `parse_url`. In my view the `Url` class in
>> PHP should allow dealing with any IANA registered scheme, which is not
>> the case for the WHATWG specification.
>=20
> Supporting IANA registered schemes is a valid request, and is definite=
ly useful.
> However, I think this feature is not strictly required to have in the =
current RFC.
> Anyone we needs to support features that are not offered by the WHATWG
> standard can still rely on parse_url(). And of course, we can (and sho=
uld) add
> support for other standards later. If we wanted to do all these in the=
 same
> RFC, then the scope of the RFC would become way too large IMO. That's =
why I
> opt for incremental improvements.

It's also worth pointing out (as another reason not to do this) is that =
IANA may-or-may not be valid in the current network. For example, TOR, H=
andshake, IPFS, Freenet, etc. all have their own DNS schemes and do not =
(usually) use IANA registered schemes, and many people create sites that=
 cater to those networks.

>=20
> Besides, I fail to see why a WHATWG compliant parser wouldn't be usefu=
l in PHP:
> yes, PHP is server side, but it still interacts with browsers very hea=
vily. Among other
> use-cases I cannot yet image, the major one is most likely validating =
user-supplied URLs
> for opening in the browser. As far as I see the situation, currently t=
here is no acceptably
> reliable possibility to decide whether a URL can be opened in browsers=
 or not.

Looking at the spec for WHATWG, it looks like `example%2Ecom` will be pa=
rsed as a valid URL, and transformed to `example.com`, while this doesn'=
t currently happen in parse_url():

https://3v4l.org/NtqQm

I don't know if that may be an issue, but might be if you are expecting =
the string to remain URL encoded.

>=20
>> - parse_url and parse_str predates RFC3986
>> - URLSearchParans was ratified before PSR-7 BUT the first implementat=
ion
>> landed a year AFTER PSR-7 was released and already implemented.
>=20
> Thank you for the historical context!
>=20
> Based on your and others' feedback, it has now become clear for me tha=
t parse_url()
> is still useful and ext/url needs quite some additional capabilities u=
ntil this function
> really becomes superfluous. That's why it now seems to me that the beh=
avior of
> parse_url() could be leveraged in ext/url so that it would work with a=
 Url/Url class (e.g.
> we had a PhpUrlParser class extending the Url/UrlParser, or a Url\Url:=
:fromPhpParser()
> method, depending on which object model we choose. Of course the names=
 are TBD).
>=20
>> For all these arguments I would keep the proposed `Url` free of all
>> these concerns and lean toward a nullable string for the query string=20
>> representation. And defer this debate to its own RFC regarding query=20
>> string parsing handling in PHP.
>=20
> My WIP implementation still uses nullable properties and return types.=
 I only changed those
> when I wrote the RFC. Since I see that PSR-7 compatibility is very low=
 prio for everyone
> involved in the discussion, then I think making these types nullable i=
s fine. It was neither my
> top prio, but somewhere I had to start the object design, so I went wi=
th this.

The spec contains elements and their types. It would be good to adhere t=
o the spec (simplifies documentation):

 1. scheme may be null or empty string
 2. port may be null
 3. path is never null, but may be empty string
 4. query may be null
 5. fragment may be null
 6. user/password may be null (to differentiate between an empty passwor=
d or no password)
 7. host may be null (for relative URLs

>=20
> Again, thank you for your constructive criticism.
>=20
> Regards,
> M=C3=A1t=C3=A9

=E2=80=94 Rob
--a24729788ef140a1a92eacf04415bffd
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Sun, Jul 7, =
2024, at 11:13, M=C3=A1t=C3=A9 Kocsis wrote:<br></div><blockquote type=3D=
"cite" id=3D"qt" style=3D""><div dir=3D"ltr"><div class=3D"qt-gmail_quot=
e"><div>Hi Ignace,<br></div><div><br></div><blockquote class=3D"qt-gmail=
_quote" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margi=
n-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-c=
olor:rgb(204, 204, 204);padding-left:1ex;"><div>As far as I understand i=
t, if this RFC were to pass as is it will model<br></div><div>PHP URLs t=
o the WHATWG specification. While this specification is<br></div><div>ge=
tting a lot of traction lately I believe it will restrict URL usage in<b=
r></div><div>PHP instead of making developer life easier. While PHP star=
ted as a<br></div><div>"web" language it is first and foremost a server =
side general purpose<br></div><div>language. The WHATWG spec on the othe=
r hand is created by browsers<br></div><div>vendors and is geared toward=
 browsers (client side) and because of<br></div><div>browsers history it=
 restricts by design a lot of what PHP developers can<br></div><div>curr=
ently do using `parse_url`. In my view the `Url` class in<br></div><div>=
PHP should allow dealing with any IANA registered scheme, which is not<b=
r></div><div>the case for the WHATWG specification.<br></div></blockquot=
e><div><br></div><div>Supporting IANA registered schemes is a valid requ=
est, and is definitely useful.<br></div><div>However, I think this featu=
re is not strictly required to have in the current RFC.<br></div><div>An=
yone we needs to support features that are not offered by the WHATWG<br>=
</div><div>standard can still rely on parse_url(). And of course, we can=
 (and should) add<br></div><div>support for other standards later. If we=
 wanted to do all these in the same<br></div><div>RFC, then the scope of=
 the RFC would become way too large IMO. That's why I<br></div><div>opt =
for incremental improvements.<br></div></div></div></blockquote><div><br=
></div><div>It's also worth pointing out (as another reason not to do th=
is) is that IANA may-or-may not be valid in the current network. For exa=
mple, TOR, Handshake, IPFS, Freenet, etc. all have their own DNS schemes=
 and do not (usually) use IANA registered schemes, and many people creat=
e sites that cater to those networks.<br></div><div><br></div><blockquot=
e type=3D"cite" id=3D"qt" style=3D""><div dir=3D"ltr"><div class=3D"qt-g=
mail_quote"><div><br></div><div>Besides, I fail to see why a WHATWG comp=
liant parser wouldn't be useful in PHP:<br></div><div>yes, PHP is server=
 side, but it still interacts with browsers very heavily. Among other<br=
></div><div>use-cases I cannot yet image, the major one is most likely v=
alidating user-supplied URLs<br></div><div>for opening in the browser. A=
s far as I see the situation, currently there is no acceptably<br></div>=
<div>reliable possibility to decide whether a URL can be opened in brows=
ers or not.<br></div></div></div></blockquote><div><br></div><div>Lookin=
g at the spec for WHATWG, it looks like `example%2Ecom` will be parsed a=
s a valid URL, and transformed to `example.com`, while this doesn't curr=
ently happen in parse_url():<br></div><div><br></div><div><a href=3D"htt=
ps://3v4l.org/NtqQm">https://3v4l.org/NtqQm</a><br></div><div><br></div>=
<div>I don't know if that may be an issue, but might be if you are expec=
ting the string to remain URL encoded.</div><div><br></div><blockquote t=
ype=3D"cite" id=3D"qt" style=3D""><div dir=3D"ltr"><div class=3D"qt-gmai=
l_quote"><div><br></div><div><blockquote class=3D"qt-gmail_quote" style=3D=
"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;bor=
der-left-width:1px;border-left-style:solid;border-left-color:rgb(204, 20=
4, 204);padding-left:1ex;"><div>- parse_url and parse_str predates RFC39=
86<br></div><div>- URLSearchParans was ratified before PSR-7 BUT the fir=
st implementation<br></div><div>landed a year AFTER PSR-7 was released a=
nd already implemented.<br></div></blockquote><div><br></div><div>Thank =
you for the historical context!<br></div></div><div><br></div><div>Based=
 on your and others' feedback, it has now become&nbsp;clear for me that =
parse_url()<br></div><div>is still useful and ext/url needs quite some a=
dditional capabilities until this function<br></div><div>really becomes =
superfluous. That's why it now seems to me that the behavior of<br></div=
><div>parse_url() could be leveraged in ext/url so that it would work wi=
th a Url/Url class (e.g.<br></div><div>we had a PhpUrlParser class exten=
ding the Url/UrlParser, or a Url\Url::fromPhpParser()<br></div><div>meth=
od, depending on which object model we&nbsp;choose. Of course the names =
are TBD).<br></div><div><br></div><blockquote class=3D"qt-gmail_quote" s=
tyle=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.=
8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(=
204, 204, 204);padding-left:1ex;"><div>For all these arguments I would k=
eep the proposed `Url` free of all<br></div><div> these concerns and lea=
n toward a nullable string for the query string <br></div><div> represen=
tation. And defer this debate to its own RFC regarding query <br></div><=
div> string parsing handling in PHP.<br></div></blockquote><div><br></di=
v><div>My WIP implementation still uses nullable properties and return t=
ypes. I only changed those<br></div><div>when I wrote the RFC. Since I s=
ee that PSR-7 compatibility is very low prio for everyone<br></div><div>=
involved&nbsp;in the discussion, then I think making these types nullabl=
e is fine. It was neither my<br></div><div>top prio, but somewhere I had=
 to start the object design, so I went with this.<br></div></div></div><=
/blockquote><div><br></div><div>The spec contains elements and their typ=
es. It would be good to adhere to the spec (simplifies documentation):<b=
r></div><div><br></div><ol><li>scheme may be null or empty string<br></l=
i><li>port may be null<br></li><li>path is never null, but may be empty =
string<br></li><li>query may be null<br></li><li>fragment may be null<br=
></li><li>user/password may be null (to differentiate between an empty p=
assword or no password)<br></li><li>host may be null (for relative URLs<=
br></li></ol><div><br></div><blockquote type=3D"cite" id=3D"qt" style=3D=
""><div dir=3D"ltr"><div class=3D"qt-gmail_quote"><div><br></div><div>Ag=
ain, thank you for your constructive criticism.<br></div><div><br></div>=
<div>Regards,<br></div><div>M=C3=A1t=C3=A9<br></div></div></div></blockq=
uote><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob<br></div></bo=
dy></html>
--a24729788ef140a1a92eacf04415bffd--