Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127070
Precedence: bulk
MIME-Version: 1.0
References: <CAH5C8xUb1O20ZDrOQNC=ckFxHUUWSK7sw_njQQzFBd0qgQqoww@mail.gmail.com>
 <RYUX5rSGApW8lPGs1yovM2fIXXBHd_UcqEKAKgj8-dRrpThS4tC195Jb3kPTT5up96r7SZ2WunauAblAIEkZe41BwZxLeSE2SaKQLAYSmZo=@gpb.moe>
 <CAH5C8xXVcPM9drj-Ny5Fs_2_wnedES8-gbchaYf7z2bWne2WcQ@mail.gmail.com>
 <8b7044d1-fde1-4701-a914-a63c8ca67099@app.fastmail.com> <CAH5C8xUA8NuWiiE+yiVAdMWFptgFp45z73XdLcgEMV6MR-4mPw@mail.gmail.com>
 <CAH5C8xWGqesGVQt6T_c_0JKC2YrjJ33u5r=B3cOKJrLzHW1GEg@mail.gmail.com>
In-Reply-To: <CAH5C8xWGqesGVQt6T_c_0JKC2YrjJ33u5r=B3cOKJrLzHW1GEg@mail.gmail.com>
Date: Tue, 8 Apr 2025 00:27:06 +0100
Message-ID: <CAH5C8xXq9ttGrLxsDs4ZuPFnd690JtuYwpgjJwTzJHYo+-5-pw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API
To: Ignace Nyamagana Butera <nyamsprod@gmail.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b228240632389354"
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--000000000000b228240632389354
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Ignace,

it might be brought back for future improvements.
>
>
Yes, surely!


> I have one last question regarding the URI implementations which are rais=
ed by my polyfill:
>
> Did you also took into account the delimiters when submitting data via th=
e withers ? In other words is
>
> ```php
> $uri->withQuery('?foo=3Dbar');
> //the same as
> $uri->withQuery('foo=3Dbar');
> ```
>
> I know it is the case in of the WHATWG specification but I do not know if=
 you kept this behaviour in your implementation for the WhatWgUrl for the R=
fc3986 or for both. I would lean toward not accepting this "normalization" =
but since this is not documented in the RFC I wanted to know what is the ex=
pected behaviour.
>
> Yes, very good question! As you said, this aspect is not defined by eithe=
r
the RFC 3986, or the present PHP RFC... But yes, this normalization
won't be accepted by the RFC implementation. I've just included this piece
of information in the relevant section (
https://wiki.php.net/rfc/url_parsing_api#component_modification).

Regards,
M=C3=A1t=C3=A9

--000000000000b228240632389354
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div>Hi Ignace,</div><div dir=3D"ltr"><br=
></div><div class=3D"gmail_quote gmail_quote_container"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div><p><span style=3D"color:rgb(33,37,41)=
;font-size:16px">it might be brought back for future improvements.</span></=
p><pre style=3D"box-sizing:border-box;font-size:16px;overflow:visible;paddi=
ng:0px;width:80ch;color:rgb(33,37,41)"></pre></div></blockquote><div><br></=
div><div>Yes, surely!</div><div>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex"><div><pre style=3D"box-sizing:border-box;font-size:16px;=
overflow:visible;padding:0px;width:80ch;color:rgb(33,37,41)">I have one las=
t question regarding the URI implementations which are raised by my polyfil=
l:

Did you also took into account the delimiters when submitting data via the =
withers ? In other words is

```php
$uri-&gt;withQuery(&#39;?foo=3Dbar&#39;);
//the same as=20
$uri-&gt;withQuery(&#39;foo=3Dbar&#39;);
```</pre></div></blockquote><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x"><div><pre style=3D"box-sizing:border-box;font-size:16px;overflow:visible=
;padding:0px;width:80ch;color:rgb(33,37,41)">I know it is the case in of th=
e WHATWG specification but I do not know if you kept this behaviour in your=
 implementation for the WhatWgUrl for the Rfc3986 or for both. I would lean=
 toward not accepting this &quot;normalization&quot; but since this is not =
documented in the RFC I wanted to know what is the expected behaviour.</pre=
></div></blockquote><div><div>Yes, very good question! As you said, this as=
pect is not defined by either the RFC 3986, or the present PHP RFC... But y=
es, this normalization</div><div>won&#39;t be accepted by the RFC implement=
ation. I&#39;ve just included this piece of information in the relevant sec=
tion (<a href=3D"https://wiki.php.net/rfc/url_parsing_api#component_modific=
ation">https://wiki.php.net/rfc/url_parsing_api#component_modification</a>)=
.</div><div>=C2=A0</div></div><div>Regards,</div><div>M=C3=A1t=C3=A9</div><=
div><br></div></div></div><div class=3D"gmail_quote gmail_quote_container">=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div cla=
ss=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote></div></div>
</blockquote></div></div>

--000000000000b228240632389354--