Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125299
Message-ID: <1BCB4144-231D-45EA-A914-98EE8F0F503A@automattic.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_E926BF61-55B3-49B2-B7A6-B6F7AEBA79C4"
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\))
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API
Date: Mon, 26 Aug 2024 17:25:35 -0500
In-Reply-To: <CAH5C8xV67frqOBCvLt73RM7QO86_pu40sHP5h71_kDRbKPtA8Q@mail.gmail.com>
Cc: Internals <internals@lists.php.net>
To: =?utf-8?B?TcOhdMOpIEtvY3Npcw==?= <kocsismate90@gmail.com>
References: <CAH5C8xUb1O20ZDrOQNC=ckFxHUUWSK7sw_njQQzFBd0qgQqoww@mail.gmail.com>
 <dd61999c-1ebd-4765-9add-cd8065968965@gmail.com>
 <CAOV5rgYZ_s1of-igLFEK7oqqh6=3HeYv0=JvvKvvjkcp0F6Q9Q@mail.gmail.com>
 <CAH5C8xV67frqOBCvLt73RM7QO86_pu40sHP5h71_kDRbKPtA8Q@mail.gmail.com>
From: dennis.snell@automattic.com (Dennis Snell)


--Apple-Mail=_E926BF61-55B3-49B2-B7A6-B6F7AEBA79C4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> Hi Everyone,
>=20
> I've been working on a new RFC for a while now, and time has come to=20=

> present it to a wider audience.
>=20
> Last year, I learnt that PHP doesn't have built-in support for parsing =
URLs=20
> according to any well established standards (RFC 1738 or the WHATWG =
URL=20
> living standard), since the parse_url() function is optimized for=20
> performance instead of correctness.
>=20
> In order to improve compatibility with external tools consuming URLs =
(like=20
> browsers), my new RFC would add a WHATWG compliant URL parser =
functionality=20
> to the standard library. The API itself is not final by any means, the =
RFC=20
> only represents how I imagined it first.
>=20
> You can find the RFC at the following link:=20
> https://wiki.php.net/rfc/url_parsing_api
>=20
> Regards,=20
> M=C3=A1t=C3=A9
>=20
M=C3=A1t=C3=A9, thanks for putting this together.

Whenever I need to work with URLs there are a few things missing that I =
would love to see incorporated into any change in PHP that brings us a =
spec-compliant parsing class.

First of all, I typically care most about WhatWG URLs because the PHP =
code I=E2=80=99m working with is making decisions about HTML that a =
browser will interpret. Paramount above all other concerns that code on =
the server can understand content in the same way that the browsers =
will, otherwise we will invite security issues. People may have valid =
critiques with the WhatWG specification, but it=E2=80=99s also the =
most-relevant specification for users of much or most of the PHP code we =
write, and it=E2=80=99s valuable because it allows us to talk about URLs =
in the same way a browser would.

I=E2=80=99m worried about the side-effects that having a global =
uri.default_handler could have with code running differently for no =
apparent reason, or differently based on what is calling it. If someone =
is writing code for a controlled system I could see this being valuable, =
but if someone is writing a framework like WordPress and has no control =
over the environments in which code runs, it seems dangerous to hope =
that every plugin and every host runs compatible system configurations. =
Nobody is going to check `ini_get( =E2=80=98uri.default_handler=E2=80=99 =
)` before every line that parses URLs. Beyond this, even just allowing a =
pluggable parser invites broken deployments because PHP code that is =
reading from a browser or sending output to one needs to speak the =
language the browser is speaking, not some arbitrary language that=E2=80=99=
s similar to it.

> One thing I feel is missing, is a method to parse a (partial) URL =
relative to another


Being able to parse a relative URL and know if a URL is relative or =
absolute would help WordPress, which often makes decisions differently =
based on this property (for instance, when reading an `href` property of =
a link). I know these aren=E2=80=99t spec-compliant URLs, but they  =
still represent valid values for URL fields in HTML and knowing if they =
are relative or not requires some amount of parsing specific details =
everywhere, vs. in a class that already parses URLs. Effectively, this =
would imply that PHP=E2=80=99s new URL parser decodes  =
`document.querySelector( =E2=80=98a=E2=80=99 ).getAttribute( =E2=80=98href=
=E2=80=99 )`, which should be the same as `document.querySelector( =
=E2=80=98a=E2=80=99 ).href`, and indicates whether it found a full URL =
or only a portion of one.

  * `$url->is_relative` or `$url->is_absolute`
  * `$url->specificity =3D URL::Relative | URL::Absolute`

> the URI parser libraries used don't support modification of the URI

Having methods to add query arguments, change the path, etc=E2=80=A6 =
would be a great way to simplify user-space code working with URLs. For =
instance, read a URL and then add a query argument if some condition =
within the URL warrants it (for example, the path ends in `.png`).

Was it intended to add this to the RFC before it=E2=80=99s finalized?

> I would not make Url final. "OMG but then people can extend it!" =
Exactly.

My counter-point to this argument is that I see security exploits appear =
everywhere that functions which implement specifications are pluggable =
and extendable. It=E2=80=99s easy to see the need to create a class that =
limits possible URLs, but that also doesn=E2=80=99t require extending a =
class. A class can wrap a URL parser just as it could extend one. Magic =
methods would make it even easier.

A problem that can arise with adding additional rules onto a =
specification like this is that the subclass gets used in more places =
than it should and then somewhere some PHP code allows a malicious URL =
because it failed to parse and then the inspection rules weren=E2=80=99t =
applied.

----

Finally, I frequently find the need to be able to consider a URL in both =
the display context and the serialization context. With Ada we have =
`normalize_url()`, `parse_search_params()`, and the IDNA functions to =
convert between the two representations. In order to keep strong =
boundaries between security domains, it would be nice if PHP could =
expose the two variations: one is an encoded form of a URL that machines =
can easily parse while the other is a =E2=80=9Cplain string=E2=80=9D in =
PHP that=E2=80=99s easier for humans to parse but which might not even =
be a valid URL. Part of the reason for this need is that I often see =
user-space code treating an entire URL as a single text span that =
requires one set of rules for full decoding; it=E2=80=99s multiple =
segments that each have their own decoding rules.

 - Original [ https://xn--google.com/secret/../search?q=3D=F0=9F=8D=94 ]
 - `$url->normalize()` [ https://xn--google.com/search?q=3D%F0%9F%8D%94 =
]
 - `$url->for_display()` Displayed [ =
https://=E4=95=AE=E4=95=B5=E4=95=B6=E4=95=B1.com/search?q=3D=F0=9F=8D=94 =
]

Having this in the RFC would give everyone the tools they need to =
effectively and safely set links within an HTML document.

----

All the best,
Dennis Snell


--Apple-Mail=_E926BF61-55B3-49B2-B7A6-B6F7AEBA79C4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;"><p =
style=3D"box-sizing: border-box; border-width: 0px; border-style: solid; =
border-color: rgba(229, 231, 235, var(--tw-border-opacity)); margin: =
0.5rem 0px 0.75rem; font-family: ui-sans-serif, system-ui, =
-apple-system, BlinkMacSystemFont, &quot;Segoe UI&quot;, Roboto, =
&quot;Helvetica Neue&quot;, Arial, &quot;Noto Sans&quot;, sans-serif, =
&quot;Apple Color Emoji&quot;, &quot;Segoe UI Emoji&quot;, &quot;Segoe =
UI Symbol&quot;, &quot;Noto Color Emoji&quot;;"></p><blockquote =
type=3D"cite"><p style=3D"box-sizing: border-box; border-width: 0px; =
border-style: solid; border-color: rgba(229, 231, 235, =
var(--tw-border-opacity)); margin: 0.5rem 0px 0.75rem; font-family: =
ui-sans-serif, system-ui, -apple-system, BlinkMacSystemFont, &quot;Segoe =
UI&quot;, Roboto, &quot;Helvetica Neue&quot;, Arial, &quot;Noto =
Sans&quot;, sans-serif, &quot;Apple Color Emoji&quot;, &quot;Segoe UI =
Emoji&quot;, &quot;Segoe UI Symbol&quot;, &quot;Noto Color =
Emoji&quot;;">Hi Everyone,</p><p style=3D"box-sizing: border-box; =
border-width: 0px; border-style: solid; border-color: rgba(229, 231, =
235, var(--tw-border-opacity)); margin: 0.5rem 0px 0.75rem; font-family: =
ui-sans-serif, system-ui, -apple-system, BlinkMacSystemFont, &quot;Segoe =
UI&quot;, Roboto, &quot;Helvetica Neue&quot;, Arial, &quot;Noto =
Sans&quot;, sans-serif, &quot;Apple Color Emoji&quot;, &quot;Segoe UI =
Emoji&quot;, &quot;Segoe UI Symbol&quot;, &quot;Noto Color =
Emoji&quot;;">I've been working on a new RFC for a while now, and time =
has come to&nbsp;<br style=3D"box-sizing: border-box; border-width: 0px; =
border-style: solid; border-color: rgba(229, 231, 235, =
var(--tw-border-opacity)); --tw-border-opacity: 1; --tw-shadow: 0 0 =
#0000; --tw-ring-inset: var(--tw-empty, ); --tw-ring-offset-width: 0px; =
--tw-ring-offset-color: #fff; --tw-ring-color: rgba(59, 130, 246, 0.5); =
--tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 =
#0000;">present it to a wider audience.</p><p style=3D"box-sizing: =
border-box; border-width: 0px; border-style: solid; border-color: =
rgba(229, 231, 235, var(--tw-border-opacity)); margin: 0.5rem 0px =
0.75rem; font-family: ui-sans-serif, system-ui, -apple-system, =
BlinkMacSystemFont, &quot;Segoe UI&quot;, Roboto, &quot;Helvetica =
Neue&quot;, Arial, &quot;Noto Sans&quot;, sans-serif, &quot;Apple Color =
Emoji&quot;, &quot;Segoe UI Emoji&quot;, &quot;Segoe UI Symbol&quot;, =
&quot;Noto Color Emoji&quot;;">Last year, I learnt that PHP doesn't have =
built-in support for parsing URLs&nbsp;<br style=3D"box-sizing: =
border-box; border-width: 0px; border-style: solid; border-color: =
rgba(229, 231, 235, var(--tw-border-opacity)); --tw-border-opacity: 1; =
--tw-shadow: 0 0 #0000; --tw-ring-inset: var(--tw-empty, ); =
--tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; =
--tw-ring-color: rgba(59, 130, 246, 0.5); --tw-ring-offset-shadow: 0 0 =
#0000; --tw-ring-shadow: 0 0 #0000;">according to any well established =
standards (RFC 1738 or the WHATWG URL&nbsp;<br style=3D"box-sizing: =
border-box; border-width: 0px; border-style: solid; border-color: =
rgba(229, 231, 235, var(--tw-border-opacity)); --tw-border-opacity: 1; =
--tw-shadow: 0 0 #0000; --tw-ring-inset: var(--tw-empty, ); =
--tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; =
--tw-ring-color: rgba(59, 130, 246, 0.5); --tw-ring-offset-shadow: 0 0 =
#0000; --tw-ring-shadow: 0 0 #0000;">living standard), since =
the&nbsp;<code style=3D"box-sizing: border-box; border-width: 0px; =
border-style: solid; border-color: rgba(229, 231, 235, =
var(--tw-border-opacity)); --tw-border-opacity: 1; --tw-shadow: 0 0 =
#0000; --tw-ring-inset: var(--tw-empty, ); --tw-ring-offset-width: 0px; =
--tw-ring-offset-color: #fff; --tw-ring-color: rgba(59, 130, 246, 0.5); =
--tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; =
font-family: ui-monospace, SFMono-Regular, Menlo, Monaco, Consolas, =
&quot;Liberation Mono&quot;, &quot;Courier New&quot;, monospace; =
font-size: 0.75rem; border-radius: 0.25rem; --tw-bg-opacity: 1; =
background-color: rgba(254, 242, 242, var(--tw-bg-opacity)); padding: =
0.25rem; line-height: 1rem; --tw-text-opacity: 1; color: rgba(185, 28, =
28, var(--tw-text-opacity));">parse_url()</code>&nbsp;function is =
optimized for&nbsp;<br style=3D"box-sizing: border-box; border-width: =
0px; border-style: solid; border-color: rgba(229, 231, 235, =
var(--tw-border-opacity)); --tw-border-opacity: 1; --tw-shadow: 0 0 =
#0000; --tw-ring-inset: var(--tw-empty, ); --tw-ring-offset-width: 0px; =
--tw-ring-offset-color: #fff; --tw-ring-color: rgba(59, 130, 246, 0.5); =
--tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 =
#0000;">performance instead of correctness.</p><p style=3D"box-sizing: =
border-box; border-width: 0px; border-style: solid; border-color: =
rgba(229, 231, 235, var(--tw-border-opacity)); margin: 0.5rem 0px =
0.75rem; font-family: ui-sans-serif, system-ui, -apple-system, =
BlinkMacSystemFont, &quot;Segoe UI&quot;, Roboto, &quot;Helvetica =
Neue&quot;, Arial, &quot;Noto Sans&quot;, sans-serif, &quot;Apple Color =
Emoji&quot;, &quot;Segoe UI Emoji&quot;, &quot;Segoe UI Symbol&quot;, =
&quot;Noto Color Emoji&quot;;">In order to improve compatibility with =
external tools consuming URLs (like&nbsp;<br style=3D"box-sizing: =
border-box; border-width: 0px; border-style: solid; border-color: =
rgba(229, 231, 235, var(--tw-border-opacity)); --tw-border-opacity: 1; =
--tw-shadow: 0 0 #0000; --tw-ring-inset: var(--tw-empty, ); =
--tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; =
--tw-ring-color: rgba(59, 130, 246, 0.5); --tw-ring-offset-shadow: 0 0 =
#0000; --tw-ring-shadow: 0 0 #0000;">browsers), my new RFC would add a =
WHATWG compliant URL parser functionality&nbsp;<br style=3D"box-sizing: =
border-box; border-width: 0px; border-style: solid; border-color: =
rgba(229, 231, 235, var(--tw-border-opacity)); --tw-border-opacity: 1; =
--tw-shadow: 0 0 #0000; --tw-ring-inset: var(--tw-empty, ); =
--tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; =
--tw-ring-color: rgba(59, 130, 246, 0.5); --tw-ring-offset-shadow: 0 0 =
#0000; --tw-ring-shadow: 0 0 #0000;">to the standard library. The API =
itself is not final by any means, the RFC&nbsp;<br style=3D"box-sizing: =
border-box; border-width: 0px; border-style: solid; border-color: =
rgba(229, 231, 235, var(--tw-border-opacity)); --tw-border-opacity: 1; =
--tw-shadow: 0 0 #0000; --tw-ring-inset: var(--tw-empty, ); =
--tw-ring-offset-width: 0px; --tw-ring-offset-color: #fff; =
--tw-ring-color: rgba(59, 130, 246, 0.5); --tw-ring-offset-shadow: 0 0 =
#0000; --tw-ring-shadow: 0 0 #0000;">only represents how I imagined it =
first.</p><p style=3D"box-sizing: border-box; border-width: 0px; =
border-style: solid; border-color: rgba(229, 231, 235, =
var(--tw-border-opacity)); margin: 0.5rem 0px 0.75rem; font-family: =
ui-sans-serif, system-ui, -apple-system, BlinkMacSystemFont, &quot;Segoe =
UI&quot;, Roboto, &quot;Helvetica Neue&quot;, Arial, &quot;Noto =
Sans&quot;, sans-serif, &quot;Apple Color Emoji&quot;, &quot;Segoe UI =
Emoji&quot;, &quot;Segoe UI Symbol&quot;, &quot;Noto Color =
Emoji&quot;;">You can find the RFC at the following link:&nbsp;<br =
style=3D"box-sizing: border-box; border-width: 0px; border-style: solid; =
border-color: rgba(229, 231, 235, var(--tw-border-opacity)); =
--tw-border-opacity: 1; --tw-shadow: 0 0 #0000; --tw-ring-inset: =
var(--tw-empty, ); --tw-ring-offset-width: 0px; --tw-ring-offset-color: =
#fff; --tw-ring-color: rgba(59, 130, 246, 0.5); --tw-ring-offset-shadow: =
0 0 #0000; --tw-ring-shadow: 0 0 #0000;"><a =
href=3D"https://wiki.php.net/rfc/url_parsing_api" rel=3D"nofollow" =
target=3D"_blank" style=3D"box-sizing: border-box; border-width: 0px; =
border-style: solid; border-color: rgba(229, 231, 235, =
var(--tw-border-opacity)); --tw-border-opacity: 1; --tw-shadow: 0 0 =
#0000; --tw-ring-inset: var(--tw-empty, ); --tw-ring-offset-width: 0px; =
--tw-ring-offset-color: #fff; --tw-ring-color: rgba(59, 130, 246, 0.5); =
--tw-ring-offset-shadow: 0 0 #0000; --tw-ring-shadow: 0 0 #0000; color: =
rgba(220, 38, 38, var(--tw-text-opacity)); text-decoration: inherit; =
--tw-text-opacity: =
1;">https://wiki.php.net/rfc/url_parsing_api</a></p><p =
style=3D"box-sizing: border-box; border-width: 0px; border-style: solid; =
border-color: rgba(229, 231, 235, var(--tw-border-opacity)); margin: =
0.5rem 0px 0.75rem; font-family: ui-sans-serif, system-ui, =
-apple-system, BlinkMacSystemFont, &quot;Segoe UI&quot;, Roboto, =
&quot;Helvetica Neue&quot;, Arial, &quot;Noto Sans&quot;, sans-serif, =
&quot;Apple Color Emoji&quot;, &quot;Segoe UI Emoji&quot;, &quot;Segoe =
UI Symbol&quot;, &quot;Noto Color Emoji&quot;;">Regards,&nbsp;<br =
style=3D"box-sizing: border-box; border-width: 0px; border-style: solid; =
border-color: rgba(229, 231, 235, var(--tw-border-opacity)); =
--tw-border-opacity: 1; --tw-shadow: 0 0 #0000; --tw-ring-inset: =
var(--tw-empty, ); --tw-ring-offset-width: 0px; --tw-ring-offset-color: =
#fff; --tw-ring-color: rgba(59, 130, 246, 0.5); --tw-ring-offset-shadow: =
0 0 #0000; --tw-ring-shadow: 0 0 =
#0000;">M=C3=A1t=C3=A9</p></blockquote><div>M=C3=A1t=C3=A9, thanks for =
putting this together.</div><div><br></div><div>Whenever I need to work =
with URLs there are a few things missing that I would love to see =
incorporated into any change in PHP that brings us a spec-compliant =
parsing class.</div><div><br></div><div>First of all, I typically care =
most about WhatWG URLs because the PHP code I=E2=80=99m working with is =
making decisions about HTML that a browser will interpret. Paramount =
above all other concerns that code on the server can understand content =
in the same way that the browsers will, otherwise we will invite =
security issues. People may have valid critiques with the WhatWG =
specification, but it=E2=80=99s also the most-relevant specification for =
users of much or most of the PHP code we write, and it=E2=80=99s =
valuable because it allows us to talk about URLs in the same way a =
browser would.</div><div><br></div><div>I=E2=80=99m worried about the =
side-effects that having a global&nbsp;<span style=3D"caret-color: =
rgb(51, 51, 51); color: rgb(51, 51, 51); font-family: &quot;Source Code =
Pro&quot;, &quot;Courier New&quot;, Courier, monospace, sans-serif; =
background-color: rgb(255, 255, =
255);">uri.default_handler</span>&nbsp;could have with code running =
differently for no apparent reason, or differently based on what is =
calling it. If someone is writing code for a controlled system I could =
see this being valuable, but if someone is writing a framework like =
WordPress and has no control over the environments in which code runs, =
it seems dangerous to hope that every plugin and every host runs =
compatible system configurations. Nobody is going to check `ini_get( =
=E2=80=98uri.default_handler=E2=80=99 )` before every line that parses =
URLs. Beyond this, even just <i>allowing</i>&nbsp;a pluggable parser =
invites broken deployments because PHP code that is reading from a =
browser or sending output to one needs to speak the language the browser =
is speaking, not some arbitrary language that=E2=80=99s similar to =
it.</div><div><br></div><div><blockquote type=3D"cite">One thing I feel =
is missing, is a method to parse a (partial) URL relative to =
another</blockquote></div><div><br></div><div>Being able to parse a =
relative URL and know if a URL is relative or absolute would help =
WordPress, which often makes decisions differently based on this =
property (for instance, when reading an `href` property of a link). I =
know these aren=E2=80=99t spec-compliant URLs, but they &nbsp;still =
represent valid values for URL fields in HTML and knowing if they are =
relative or not requires some amount of parsing specific details =
everywhere, vs. in a class that already parses URLs. Effectively, this =
would imply that PHP=E2=80=99s new URL parser decodes =
&nbsp;`document.querySelector( =E2=80=98a=E2=80=99 ).getAttribute( =
=E2=80=98href=E2=80=99 )`, which should be the same as =
`document.querySelector( =E2=80=98a=E2=80=99 ).href`, and indicates =
whether it found a full URL or only a portion of =
one.</div><div><br></div><div>&nbsp; * `$url-&gt;is_relative` or =
`$url-&gt;is_absolute`</div><div>&nbsp; * `$url-&gt;specificity =3D =
URL::Relative | URL::Absolute`</div><div><br></div><blockquote =
type=3D"cite"><div><div>the URI parser libraries used don't support =
modification of the =
URI</div></div></blockquote><div><br></div><div>Having methods to add =
query arguments, change the path, etc=E2=80=A6 would be a great way to =
simplify user-space code working with URLs. For instance, read a URL and =
then add a query argument if some condition within the URL warrants it =
(for example, the path ends in `.png`).</div><div><br></div><div>Was it =
intended to add this to the RFC before it=E2=80=99s =
finalized?</div><div><br></div><div><blockquote type=3D"cite">I would =
not make Url final. "OMG but then people can extend it!" =
Exactly.</blockquote><br></div><div>My counter-point to this argument is =
that I see security exploits appear everywhere that functions which =
implement specifications are pluggable and extendable. It=E2=80=99s easy =
to see the need to create a class that <i>limits</i>&nbsp;possible URLs, =
but that also doesn=E2=80=99t require extending a class. A class can =
wrap a URL parser just as it could extend one. Magic methods would make =
it even easier.</div><div><br></div><div>A problem that can arise with =
adding additional rules onto a specification like this is that the =
subclass gets used in more places than it should and then somewhere some =
PHP code allows a malicious URL <i>because</i>&nbsp;it failed to parse =
and then the inspection rules weren=E2=80=99t =
applied.</div><div><br></div><div>----</div><div><br></div><div>Finally, =
I frequently find the need to be able to consider a URL in both the =
<i>display</i>&nbsp;context and the <i>serialization</i>&nbsp;context. =
With Ada we have `normalize_url()`, `parse_search_params()`, and the =
IDNA functions to convert between the two representations. In order to =
keep strong boundaries between security domains, it would be nice if PHP =
could expose the two variations: one is an encoded form of a URL that =
machines can easily parse while the other is a =E2=80=9Cplain string=E2=80=
=9D in PHP that=E2=80=99s easier for humans to parse but which might not =
even be a valid URL. Part of the reason for this need is that I often =
see user-space code treating an entire URL as a single text span that =
requires one set of rules for full decoding; it=E2=80=99s multiple =
segments that each have their own decoding =
rules.</div><div><br></div><div>&nbsp;- Original =
[&nbsp;https://xn--google.com/secret/../search?q=3D=F0=9F=8D=94 =
]</div><div>&nbsp;- `$url-&gt;normalize()` =
[&nbsp;https://xn--google.com/search?q=3D%F0%9F%8D%94 =
]</div><div>&nbsp;- `$url-&gt;for_display()` Displayed [ =
https://=E4=95=AE=E4=95=B5=E4=95=B6=E4=95=B1.com/search?q=3D=F0=9F=8D=94 =
]</div><div><br></div><div>Having this in the RFC would give everyone =
the tools they need to effectively and safely set links within an HTML =
document.</div><div><br></div><div>----</div><div><br></div><div>All the =
best,</div><div>Dennis Snell</div><div><br></div></body></html>=

--Apple-Mail=_E926BF61-55B3-49B2-B7A6-B6F7AEBA79C4--