Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126979
Precedence: bulk
MIME-Version: 1.0
Date: Sun, 30 Mar 2025 14:42:33 +0200
To: Ignace Nyamagana Butera <nyamsprod@gmail.com>
Cc: =?UTF-8?Q?M=C3=A1t=C3=A9_Kocsis?= <kocsismate90@gmail.com>, PHP
 Internals List <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API
In-Reply-To: <f5952335-898a-4707-aa6e-7668b678ff13@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>
 <1BCB4144-231D-45EA-A914-98EE8F0F503A@automattic.com>
 <8E614C9C-BA85-45D8-9A4E-A30D69981C5D@automattic.com>
 <CAH5C8xV69pHnSKWJrVB8EQab7vPhcaXAwYezoG6z3Oj7ZkXBaQ@mail.gmail.com>
 <bc5472e39bc607e2c7accc9d2bd6f239@bastelstu.be>
 <9bf11a89-39d9-457b-b0ea-789fd07d7370@gmail.com>
 <CAH5C8xWnoytE=jm1sxr-HcSZFzmG8SrzghinmBZa-QyGqN4uUg@mail.gmail.com>
 <6430b9ed-638d-4247-9fa9-d1a9148c382b@gmail.com>
 <CAH5C8xX3tCS3B3z2YFbRudCXi=ZNHE0scrmoFO7cXxU773EfpA@mail.gmail.com>
 <2e95e8fe-7cf0-493f-bd0a-9fff0956baaa@gmail.com>
 <CAH5C8xXuSEBx6y4ds8bhReFFZe0i05DFonvEP+sz+mdkembZtQ@mail.gmail.com>
 <f5952335-898a-4707-aa6e-7668b678ff13@gmail.com>
Message-ID: <7d715757cc2dfd71019d106b01c69aed@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

Am 2025-03-27 23:49, schrieb Ignace Nyamagana Butera:
> Hi Máté,
> 
>    for RFC 3986:
>    https://datatracker.ietf.org/doc/html/rfc3986#section-5.3), and then
>    this string is parsed and validated. Unfortunately, I recently
>    realized that this approach may leave room for some kind of parsing
>    confusion attack, namely when the scheme is for example "https", the
>    authority is empty, and the path is "example.com
>    <http://example.com>". This will result in a https://example.com
>    URI. I believe a similar bug is not possible with the rest of the
>    components because they have their delimiters. So possibly some
>    other solution will be needed, or maybe adding some additional
>    validation (?).
> 
> This is not correct according to RFC3986 
> https://datatracker.ietf.org/doc/html/rfc3986#section-3
> 
> 
> *When authority is present, the path must either be empty or begin with 
> a slash ("/") character. When authority is not present, the path cannot 
> begin with two slash characters ("//"). *
> 
> So in your example it should throw an Uri\InvalidUriException 🙂 for 
> RFC3986 and in case of the WhatwgUrl algorithm it should trigger a soft 
> error and correct the behaviour for the http(s) schemes.
> This is also one of the many reasons why at least for RFC3986 the path 
> component can never be `null` but that's another discussion. Like I 
> said having a `fromComponenta` named constructor would allow the 
> "removal" of the need for a UriBuilder (in your future section) and 
> would IMHO be useful outside of the context of the http(s) scheme but I 
> can understand it being left out of the current implementation it might 
> be brought back for future improvements.

I just tested this with the implementation and it also appears to not 
yet be correct:

     var_dump((new Uri\Rfc3986\Uri("example.com"))->getHost()); // NULL
     var_dump((new 
Uri\Rfc3986\Uri("example.com"))->withScheme('https')->getHost()); // 
string(11) "example.com"
     var_dump((new 
Uri\Rfc3986\Uri("example.com"))->withScheme('https')->toRawString()); // 
string(19) "https://example.com"

and

     var_dump((new 
Uri\Rfc3986\Uri("foo/bar"))->withPath('//foo/bar')->getHost()); // 
string(3) "foo"

Best regards
Tim Düsterhus