Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124280
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>
 <CAH5C8xVVHMn3Q4U2Aa9n3sED3tGdnWoabryTSL6Dk0MrenD+3g@mail.gmail.com>
In-Reply-To: <CAH5C8xVVHMn3Q4U2Aa9n3sED3tGdnWoabryTSL6Dk0MrenD+3g@mail.gmail.com>
Date: Mon, 8 Jul 2024 09:51:27 +0200
Message-ID: <CAOWwgp=33qk0+fPF0CUMWcpBVSk5_k8DDMAO6P2B6vUnCWcn_g@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API
To: =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= <kocsismate90@gmail.com>
Cc: nyamsprod@gmail.com, internals@lists.php.net, 
	Stephen Reay <php-lists@koalephant.com>
Content-Type: multipart/alternative; boundary="000000000000f2c1f0061cb7ae2e"
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--000000000000f2c1f0061cb7ae2e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Mat=C3=A9,

Fantastic RFC :)

Le dim. 7 juil. 2024 =C3=A0 11:17, M=C3=A1t=C3=A9 Kocsis <kocsismate90@gmai=
l.com> a =C3=A9crit :

> 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().
>

If I may, parse_url is showing its age and issues like
https://github.com/php/php-src/issues/12703 make it unreliable. We need an
escape plan from it.

FYI, we're discussing whether a Uri component should make it in Symfony
precisely to work around parse_url's issues in
https://github.com/php/php-src/issues/12703
Your RFC would be the perfect answer to this discussion but IRI would need
to be part of it.

I agree with everything Ignace said. Supporting RFC3986 from day-1 would be
absolutely great!

Note that we use parse_url for http-URLs, but also to parse DSNs like
redis://localhost and the likes.


> And of course, we can (and should) add
> support for other standards later. If we wanted to do all these in the sa=
me
> 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 i=
n
> 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 ther=
e
> 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 unti=
l
> 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 ar=
e
> 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
>

--000000000000f2c1f0061cb7ae2e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Mat=C3=A9,</div><div><br></div><div>Fantastic RFC =
:)<br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_=
attr">Le=C2=A0dim. 7 juil. 2024 =C3=A0=C2=A011:17, M=C3=A1t=C3=A9 Kocsis &l=
t;<a href=3D"mailto:kocsismate90@gmail.com">kocsismate90@gmail.com</a>&gt; =
a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex"><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.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">As far as I unde=
rstand it, if this RFC were to pass as is it will model<br>PHP URLs to the =
WHATWG specification. While this specification is<br>getting a lot of tract=
ion lately I believe it will restrict URL usage in<br>PHP instead of making=
 developer life easier. While PHP started as a<br>&quot;web&quot; language =
it is first and foremost a server side general purpose<br>language. The WHA=
TWG spec on the other hand is created by browsers<br>vendors and is geared =
toward browsers (client side) and because of<br>browsers history it restric=
ts by 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 IA=
NA registered scheme, which is not<br>the case for the WHATWG specification=
.</blockquote><div><br></div><div>Supporting IANA registered schemes is a v=
alid request, and is definitely useful.</div><div>However, I think this fea=
ture is not strictly required to have in the current RFC.</div><div>Anyone =
we needs to support features that are not offered by the WHATWG</div><div>s=
tandard can still rely on parse_url().</div></div></div></blockquote><div><=
br></div><div>If I may, parse_url is showing its age and issues like <a hre=
f=3D"https://github.com/php/php-src/issues/12703">https://github.com/php/ph=
p-src/issues/12703</a> make it unreliable. We need an escape plan from it.<=
/div><div><br></div><div>FYI, we&#39;re discussing whether a Uri component =
should make it in Symfony precisely to work around parse_url&#39;s issues i=
n <a href=3D"https://github.com/php/php-src/issues/12703">https://github.co=
m/php/php-src/issues/12703</a></div><div>Your RFC would be the perfect answ=
er to this discussion but IRI would need to be part of it.<br></div><div><b=
r></div><div>I agree with everything Ignace said. Supporting=C2=A0RFC3986 f=
rom day-1 would be absolutely great!</div><div><br></div><div>Note that we =
use parse_url for http-URLs, but also to parse DSNs like redis://localhost =
and the likes.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>And of cou=
rse, we can (and should) add</div><div>support for other standards later. I=
f we wanted to do all these in the same</div><div>RFC, then the scope of th=
e RFC would become way too large IMO. That&#39;s why I</div><div>opt for in=
cremental improvements.</div><div><br></div><div>Besides, I fail to see why=
 a WHATWG compliant parser wouldn&#39;t be useful in PHP:</div><div>yes, PH=
P is server side, but it still interacts with browsers very heavily. Among =
other</div><div>use-cases I cannot 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, currently 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><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">- pa=
rse_url and parse_str predates RFC3986<br>- URLSearchParans was ratified be=
fore PSR-7 BUT the first implementation<br>landed a year AFTER PSR-7 was re=
leased and already implemented.<br></blockquote><div><br></div><div>Thank y=
ou 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_u=
rl()<br></div><div>is still useful and ext/url needs quite some additional =
capabilities until this function</div><div>really becomes superfluous. That=
&#39;s why it now seems to me that the behavior of</div><div>parse_url() co=
uld be leveraged in ext/url so that it would work with a Url/Url class (e.g=
.</div><div>we had a PhpUrlParser class extending the Url/UrlParser, or a U=
rl\Url::fromPhpParser()</div><div>method, depending on which object model w=
e=C2=A0choose. Of course the names are TBD).</div><div><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid 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>
</blockquote></div></div>

--000000000000f2c1f0061cb7ae2e--