Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127175
Precedence: bulk
MIME-Version: 1.0
Date: Wed, 23 Apr 2025 12:50:44 +0200
To: =?UTF-8?Q?M=C3=A1t=C3=A9_Kocsis?= <kocsismate90@gmail.com>
Cc: Internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API
In-Reply-To: <CAH5C8xU+rnp4e5=CzqhEncRww6nhZ7x1s68NjWtu+HQMpoNZ8g@mail.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>
 <CAH5C8xW_auVf+ig7odhTK8dVWwmXTg4ZVZN-0Fhh4SUBzrWxVw@mail.gmail.com>
 <8df04e01-deac-404b-beb7-cd982423db63@bastelstu.be>
 <CAH5C8xU0JcnmC2Hdd=Hj0CQUaL0-LN=1X8+5-eUbFH3ZMxCvBA@mail.gmail.com>
 <33427cd03035ef084245c44290b56a55@bastelstu.be>
 <CAH5C8xXwDO6Ui8pLmqoxEguURh97fAaL4CfLK-oitqC85N7+8w@mail.gmail.com>
 <0aa1eefc3941bdea0092e935074daa58@bastelstu.be>
 <CAH5C8xU+rnp4e5=CzqhEncRww6nhZ7x1s68NjWtu+HQMpoNZ8g@mail.gmail.com>
Message-ID: <76d96ea8a78c6025128c0a4b01c94c0a@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-04-17 13:18, schrieb Máté Kocsis:
>> Sweet. I believe this was/is the last remaining blocker for the RFC or
>> is there still anyone else from your side that needs to be discussed? 
>> I
>> need to give the RFC another read once you made the adjustment to 
>> remove
>> the WhatWg raw methods (and adjusted the corresponding explanations),
>> but I think I'm happy then :-)
>> 
> 
> No, I also think that was the last one, as I don't have any questions 
> left.
> Although,
> we should finalize what the WHATWG getters should be named? I like the
> explicit "raw"
> that you suggested, but I can also see that it may be confusing for 
> some
> people. Altogether
> I think I prefer adding "raw" so that it's clear that they behave 
> similarly
> how the raw RFC 3986 getters
> do.

In https://news-web.php.net/php.internals/127114 I suggest to only 
provide the "non-raw" methods, so I believe you misread that. I've just 
given the RFC another read and thought about the naming and I believe I 
still prefer not having the "raw" in the name:

- Having the `raw` in the name makes the API very clunky / verbose to 
use.
- Other implementations, such as in browsers or node.js, also simply use 
the component name without any indication of the output being raw.
- Future changes to the WHATWG URL specification might introduce some 
normalization for components that currently doesn't have normalization. 
This would make the `raw` naming a misnomer and might require new 
methods / deprecations on PHP's end.

So it seems to be safer to use the naming without the `raw` and then in 
the documentation explain what happens with useful examples, just like 
the RFC already does.

------------

Other than that, I noticed the following small issues:

1.

The `UrlValidationError` class is `final` in the implementation, but not 
in the RFC text. I assume that is an oversight.

2.

In the "Advanced examples" section, the "another tricky example". There 
is a duplicate `?foo=bar%26baz%3Dqux` in the query-string. I assume that 
is unintentional and not part of the example.

3.

In the "Advanced examples" section, the "another tricky example". I 
think it would be useful to have an explicit comparison to the output of 
the WHATWG URL, especially around the IPv6 normalization. I've seen that 
this is also mentioned later, but it's probably useful to have here as 
well.

4.

In the "Component modification" section, for the "In order to offer 
consistent behavior with the parsing rules of RFC 3986, withers of 
Uri\Rfc3986\Uri also only accept properly formatted input," example:

There is a `echo $uri->getRawHost(); // 
[2001:0db8:0001:0000:0000:0ab9:C0A8:0102]` call, but the host is never 
modified. That appears to be an error.

5.

In the "Serialization" section: The explanation of the serialization 
format is overly specific regarding the implementation details. I would 
simplify that to just say "it supports serialization by using the 
toRawString() output and performs strict checks during unserialization" 
or similar. The reason is that I want to make some suggestions to the 
serialization format to provide greater flexibility for future changes 
during the technical review of the implementation :-)

------------

I did not give the implementation another test, since with the removal 
of the percent-decoding for WHATWG, the RFC just does what the other 
specifications already require. So this all makes sense to me and any 
differences would simply be a regular bug in the code, rather than the 
RFC text.

Best regards
Tim Düsterhus