Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124429
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-568-g843fbadbe-fm-20240701.003-g843fbadb
Precedence: bulk
MIME-Version: 1.0
Message-ID: <6b078c2a-91fa-48dd-b7d9-154eb6136249@app.fastmail.com>
In-Reply-To: 
 <CAH5C8xXtaNy_74n4=w2_PcO7sO_ZeBeFFARctWcCbQGvJA-UQQ@mail.gmail.com>
References: <71a73b87-cc2f-4ee5-a961-7bf2b191fbb6@gmail.com>
 <5159E0AB-C8B0-4A54-9654-986C1D9C858F@koalephant.com>
 <07160e83-7333-44a1-81f2-b121e2cf0ffd@gmail.com>
 <CAH5C8xXtaNy_74n4=w2_PcO7sO_ZeBeFFARctWcCbQGvJA-UQQ@mail.gmail.com>
Date: Mon, 15 Jul 2024 13:23:10 +0000
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Jul 15, 2024, at 9:20 AM, M=C3=A1t=C3=A9 Kocsis wrote:
> Hey Ignace, Nicolas,
>
> Based on your request for adding support for RFC 3986 spec compatible=20
> parsing,
> I evaluated another library (https://github.com/uriparser/uriparser/)=20
> in the recent days
> in order to add support for the requested functionality. As far as I=20
> can tell, the results
> were very promising, so I'm ok to include this into my proposal (I=20
> haven't pushed my
> changes yet and haven't updated the RFC yet).
>
> Regarding the reference resolution=20
> (https://uriparser.github.io/doc/api/latest/#resolution)
> feature which has also already been asked for, I'm genuinely wondering=20
> what the use-case is?
> But in any case, I'm fine with incorporating this as well into the RFC=
,=20
> since apparently
> both Lexbor and uriparser support this (naturally).
>
> What I became puzzled about is the correct object structure and naming=
.=20
> Now that uriparser
> which can deal with URIs came into the picture, while Lexbor can parse=20
> URLs, I don't
> know if it's a good idea to have a dedicated URI and a URL class=20
> extending the former one...
> If it is, then in my opinion, the logical behavior would be that Lexbo=
r=20
> always instantiates URL
> classes, while uriparser would have to decide if the passed-in URI is=20
> actually an URL, and
> choose the instantiated class based on this factor... But in this case=20
> the differences between
> the RFC 3986 and WHATWG specifications couldn't be spelled out, since=20
> URL objects
> could hold URLs parsed based on both specs (and therefore having a=20
> unified interface is required).
>
> Or rather we should have a separate URI and a WhatwgUrl class so that=20
> the former one would
> always be created by uriparser, while the latter one by Lexbor? This=20
> way we could have a dedicated
> object interface for both standards (e.g. the RFC 3986 related one=20
> could have a getUserInfo() method,
> while the WHATWG related one could have both getUser() and=20
> getPassword() methods). But then
> the question is how interchangeable these classes should be? I.e.=20
> should we be able to convert them
> back and forth, or should there be an interface that is implemented by=20
> the two classes?
>
> I'd appreciate any suggestions regarding these questions.
>
> P.S. due to its bad receptance, I got rid of the UrlParser class as=20
> well as the UrlComponent enum from my
> implementation in the meantime.
>
> Regards,
> M=C3=A1t=C3=A9

I apologize if I missed this up-thread somewhere, but what precisely are=
 the differences between URI and URL?  My understanding was that URL is =
a subset of URI (all URLs are URIs, but not all URIs are URLs).  You're =
saying they're slightly disjoint sets?  Can you give some concrete examp=
les of where the parsing rules would produce different results?  That ma=
y give us a better sense of what the logic should be.

--Larry Garfield