Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124252
Precedence: bulk
MIME-Version: 1.0
References: <71a73b87-cc2f-4ee5-a961-7bf2b191fbb6@gmail.com>
 <5159E0AB-C8B0-4A54-9654-986C1D9C858F@koalephant.com> <07160e83-7333-44a1-81f2-b121e2cf0ffd@gmail.com>
In-Reply-To: <07160e83-7333-44a1-81f2-b121e2cf0ffd@gmail.com>
Date: Sun, 7 Jul 2024 12:13:58 +0300
Message-ID: <CAH5C8xVVHMn3Q4U2Aa9n3sED3tGdnWoabryTSL6Dk0MrenD+3g@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API
To: nyamsprod@gmail.com
Cc: internals@lists.php.net, Stephen Reay <php-lists@koalephant.com>
Content-Type: multipart/alternative; boundary="000000000000240202061ca4b8f3"
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--000000000000240202061ca4b8f3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Ignace,

As far as I understand it, if this RFC were to pass as is it will model
> 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.


Supporting IANA registered schemes is a valid request, and is definitely
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 should)
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.

Besides, I fail to see why a WHATWG compliant parser wouldn't be useful in
PHP:
yes, PHP is server side, but it still interacts with browsers very heavily.
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 there
is no acceptably
reliable possibility to decide whether a URL can be opened in browsers or
not.

- parse_url and parse_str predates RFC3986
> - URLSearchParans was ratified before PSR-7 BUT the first implementation
> landed a year AFTER PSR-7 was released and already implemented.
>

Thank you for the historical context!

Based on your and others' feedback, it has now become clear for me that
parse_url()
is still useful and ext/url needs quite some additional capabilities until
this function
really becomes superfluous. That's why it now seems to me that the behavior
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).

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
> representation. And defer this debate to its own RFC regarding query
> string parsing handling in PHP.
>

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 is
fine. It was neither my
top prio, but somewhere I had to start the object design, so I went with
this.

Again, thank you for your constructive criticism.

Regards,
M=C3=A1t=C3=A9

--000000000000240202061ca4b8f3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div>Hi Ignace,</div><div><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex">As far as I understa=
nd it, if this RFC were to pass as is it will model<br>PHP URLs to the WHAT=
WG specification. While this specification is<br>getting a lot of traction =
lately I believe it will restrict URL usage in<br>PHP instead of making dev=
eloper life easier. While PHP started as a<br>&quot;web&quot; language it i=
s first and foremost a server side general purpose<br>language. The WHATWG =
spec on the other hand is created by browsers<br>vendors and is geared towa=
rd browsers (client side) and because of<br>browsers history it restricts b=
y design a lot of what PHP developers can<br>currently do using `parse_url`=
. In my view the `Url` class in<br>PHP should allow dealing with any IANA r=
egistered scheme, which is not<br>the case for the WHATWG specification.</b=
lockquote><div><br></div><div>Supporting IANA registered schemes is a valid=
 request, and is definitely useful.</div><div>However, I think this feature=
 is not strictly required to have in the current RFC.</div><div>Anyone we n=
eeds to support features that are not offered by the WHATWG</div><div>stand=
ard can still rely on parse_url(). And of course, we can (and should) add</=
div><div>support for other standards later. If we wanted to do all these in=
 the same</div><div>RFC, then the scope of the RFC would become way too lar=
ge IMO. That&#39;s why I</div><div>opt for incremental improvements.</div><=
div><br></div><div>Besides, I fail to see why a WHATWG compliant parser wou=
ldn&#39;t be useful in PHP:</div><div>yes, PHP is server side, but it still=
 interacts with browsers very heavily. Among other</div><div>use-cases I ca=
nnot yet image, the major one is most likely validating user-supplied URLs<=
/div><div>for opening in the browser. As far as I see the situation, curren=
tly there is no acceptably</div><div>reliable possibility to decide whether=
 a URL can be opened in browsers or not.</div><div><br></div><div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">- parse_url and parse_str predates=
 RFC3986<br>- URLSearchParans was ratified before PSR-7 BUT the first imple=
mentation<br>landed a year AFTER PSR-7 was released and already implemented=
.<br></blockquote><div><br></div><div>Thank you for the historical context!=
</div></div><div><br></div><div>Based on your and others&#39; feedback, it =
has now become=C2=A0clear for me that parse_url()<br></div><div>is still us=
eful and ext/url needs quite some additional capabilities until this functi=
on</div><div>really becomes superfluous. That&#39;s why it now seems to me =
that the behavior of</div><div>parse_url() could be leveraged in ext/url so=
 that it would work with a Url/Url class (e.g.</div><div>we had a PhpUrlPar=
ser class extending the Url/UrlParser, or a Url\Url::fromPhpParser()</div><=
div>method, depending on which object model we=C2=A0choose. Of course the n=
ames are TBD).</div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">
For all these arguments I would keep the proposed `Url` free of all<br>
these concerns and lean toward a nullable string for the query string <br>
representation. And defer this debate to its own RFC regarding query <br>
string parsing handling in PHP.<br></blockquote><div><br></div><div>My WIP =
implementation still uses nullable properties and return types. I only chan=
ged those</div><div>when I wrote the RFC. Since I see that PSR-7 compatibil=
ity is very low prio for everyone</div><div>involved=C2=A0in the discussion=
, then I think making these types nullable is fine. It was neither my</div>=
<div>top prio, but somewhere I had to start the object design, so I went wi=
th this.</div><div><br></div><div>Again, thank you for your constructive cr=
iticism.</div><div><br></div><div>Regards,</div><div>M=C3=A1t=C3=A9</div></=
div></div>

--000000000000240202061ca4b8f3--