Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126728
Precedence: bulk
MIME-Version: 1.0
References: <CAH5C8xUb1O20ZDrOQNC=ckFxHUUWSK7sw_njQQzFBd0qgQqoww@mail.gmail.com>
 <RYUX5rSGApW8lPGs1yovM2fIXXBHd_UcqEKAKgj8-dRrpThS4tC195Jb3kPTT5up96r7SZ2WunauAblAIEkZe41BwZxLeSE2SaKQLAYSmZo=@gpb.moe>
 <17bdbfa35c920a86a19690e356e05f99@bastelstu.be>
In-Reply-To: <17bdbfa35c920a86a19690e356e05f99@bastelstu.be>
Date: Wed, 12 Mar 2025 23:00:21 +0100
Message-ID: <CAH5C8xWCR9tcTS_g+7hc7kR8r4W3DCLeGoQv6cgm3sm6kv=Kvw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: "Gina P. Banyard" <internals@gpb.moe>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000008eb1a906302c55f2"
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--0000000000008eb1a906302c55f2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Tim,


> The same is true for `UriOperationException`. The RFC says that it can
> happen for memory issues. Can this actually happen? My understanding is
> that the engine bails out when an allocation fails. In any case if a
> more graceful handling is desired it should be some generic
> `OutOfMemoryError` rather than an extension-specific exception.
>

After checking the code of emalloc et al. I agree with you, the exception
won't actually
be thrown for memory errors. Therefore, I removed this part of the RFC.


>
> With regard to unserialization, let me refer to:
> https://externals.io/message/118311. ext/random uses `\Exception` and I
> suggest ext/uri to do the same. This should also be handled in a
> consistent way across extensions, e.g. by reproposing
> https://wiki.php.net/rfc/improve_unserialize_error_handling.
>

Thanks for bringing this RFC to my attention, I agree with the motivation,
so I
changed this aspect of the RFC too to throw an \Exception.


>
> And with =E2=80=9CTheoretically, URI component reading may also trigger t=
his
> exception=E2=80=9D being a theoretical issue only, the `UriOperationExcep=
tion`
> is not actually necessary at all.
>

I wanted to reserve the right for any 3rd party internal URI implementation=
s
to fail for whatever reason that prevents reading. The built-in
implementations
don't fail for sure, but it doesn't mean that 3rd party implementations
neither will.
Since potential errors can be handled in some way, I think it makes sense
to keep this exception, especially because it's now basically
non-triggerable.

I'm not sure if I'm entirely correct, but it's possible that a 3rd party
URI implementation
won't (or cannot) use PHP's memory manager, and it relies on the regular
malloc:
in this case, even memory errors could lead to failures.

Regards,
M=C3=A1t=C3=A9

--0000000000008eb1a906302c55f2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi Tim,</div><div class=3D"gmail_quote gm=
ail_quote_container"><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(77,77,77);padding-=
left:1ex">
The same is true for `UriOperationException`. The RFC says that it can <br>
happen for memory issues. Can this actually happen? My understanding is <br=
>
that the engine bails out when an allocation fails. In any case if a <br>
more graceful handling is desired it should be some generic <br>
`OutOfMemoryError` rather than an extension-specific exception.<br></blockq=
uote><div><br></div><div>After checking the code of emalloc et al. I agree =
with you, the exception won&#39;t actually</div><div>be thrown for memory e=
rrors. Therefore, I removed this part of the RFC.</div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(77,77,77);padding-left:1ex">
<br>
With regard to unserialization, let me refer to: <br>
<a href=3D"https://externals.io/message/118311" rel=3D"noreferrer" target=
=3D"_blank">https://externals.io/message/118311</a>. ext/random uses `\Exce=
ption` and I <br>
suggest ext/uri to do the same. This should also be handled in a <br>
consistent way across extensions, e.g. by reproposing <br>
<a href=3D"https://wiki.php.net/rfc/improve_unserialize_error_handling" rel=
=3D"noreferrer" target=3D"_blank">https://wiki.php.net/rfc/improve_unserial=
ize_error_handling</a>.<br></blockquote><div><br></div><div>Thanks for brin=
ging this RFC to my attention, I agree with the motivation, so I</div><div>=
changed this aspect of the RFC too to throw an \Exception.</div><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(77,77,77);padding-left:1ex">
<br>
And with =E2=80=9CTheoretically, URI component reading may also trigger thi=
s <br>
exception=E2=80=9D being a theoretical issue only, the `UriOperationExcepti=
on` <br>
is not actually necessary at all.<br></blockquote><div><br></div><div>I wan=
ted to reserve the right for any 3rd party internal URI implementations</di=
v><div>to fail=C2=A0<span style=3D"color:rgb(191,191,191)">for whatever rea=
son that prevents=C2=A0</span><span style=3D"color:rgb(191,191,191)">readin=
g. The built-in implementations</span></div><div>don&#39;t fail for sure, b=
ut it doesn&#39;t mean that 3rd party implementations neither will.</div><d=
iv>Since potential errors can be handled in some way, I think it makes sens=
e</div><div>to keep this exception,=C2=A0especially because it&#39;s now ba=
sically non-triggerable.</div><div><br></div><div>I&#39;m not sure if I&#39=
;m entirely correct, but it&#39;s possible that a 3rd party URI implementat=
ion</div><div>won&#39;t (or cannot) use PHP&#39;s memory manager, and it re=
lies on the regular malloc:</div><div>in this case, even memory errors coul=
d lead to failures.</div><div><br></div><div>Regards,</div><div>M=C3=A1t=C3=
=A9</div><div><br></div></div></div>

--0000000000008eb1a906302c55f2--