Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127115
Message-ID: <2fde0354-7d45-47a7-8ac1-b9b8eea8b3e7@gmail.com>
Date: Tue, 15 Apr 2025 19:12:37 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>,
 =?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>
 <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>
Content-Language: fr
Cc: PHP Internals List <internals@lists.php.net>
In-Reply-To: <33427cd03035ef084245c44290b56a55@bastelstu.be>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: nyamsprod@gmail.com (Ignace Nyamagana Butera)

> Perhaps the correct solution would be to offer only the non-raw 
> methods for WHATWG URL and to not attempt any additional 
> percent-decoding there? My reasoning is that the WHATWG URL is a 
> living standard anyways, so trying to add additional semantics on top 
> will result in sadness. My understanding is also that it is primarily 
> intended for interaction with web browsers or to embed these URLs into 
> HTML. For access control, e.g. in your framework the RFC3986 URI 
> should be used. It's what HTTP uses internally and it supports 
> well-defined normalization.
>
> What do you think?
>
Hi Tim and Maté

As a primary user of RFC3986/87 and with my experiences with WHATWG URL 
I fully support the removal of the `raw` methods on the WhatWgUrl 
implementation. The specification defines in one go via a state machine 
parsing, validation and normalization basically you always work with 
normalized URLs. I believe Javascript developers and browser vendors 
expect normalization out of the box for security and coherence between 
browsers. So in the context of browsers raw values are never expected 
nor wanted. I always wonder how you could extract raw value since the 
specification always talk about codepoints and parse the URL while 
normalizing the input.

As Tim also pointed out, the WHATWG is a living standard so the URL 
produces today may not be the one produces tomorrow which would then add 
more burden on the maintenance side if you constantly need to update how 
raw values are being extract in a specification that does not even 
consider them (does not offer an official way to access them).

Last but not least I tried several time to implement a polyfill for the 
Whatwg Url and I fail for that specific reason. I always go back to my 
initial comment both specs are great in that they complement each other. 
They may overlaps but they are fundamently different, so their public 
API should probably also reflect that. (ie WhatwgURL supports IDN host, 
RFC3986 does not) encoding differs for query string and so on. Trying to 
offer the same API for both even for `raw` method is IMHO not helping. 
And probably it may ease even your implementation since you would not 
have to worry about more edge cases.

Best regards,

Ignace Nyamagana Butera