Re: [RFC] [Discussion] Add WHATWG compliant URL parsing API

From: Date: Fri, 28 Jun 2024 21:35:36 +0000
Subject: Re: [RFC] [Discussion] Add WHATWG compliant URL parsing API
References: 1  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
On 28/06/2024 22:06, Máté Kocsis wrote:
> Hi Everyone,
> 
> I've been working on a new RFC for a while now, and time has come to present it to a wider
> audience.
> 
> Last year, I learnt that PHP doesn't have built-in support for parsing URLs according to
> any well established standards (RFC 1738 or the WHATWG URL living standard), since the parse_url()
> function is optimized for performance instead of correctness.
> 
> In order to improve compatibility with external tools consuming URLs (like browsers), my new
> RFC would add a WHATWG compliant URL parser functionality to the standard library. The API itself is
> not final by any means, the RFC only represents how I imagined it first.
> 
> You can find the RFC at the following link: https://wiki.php.net/rfc/url_parsing_api <https://wiki.php.net/rfc/url_parsing_api>
> 
> Regards,
> Máté
> 

Hi Máté

+1 from me, I'm all for modern web-related APIs as you know.

Some questions/remarks:
- Why did you choose UrlParser to be a "static" class? Right now it's just a fancy
namespace.
  I can see the point of having a UrlParser class where you can e.g. configure it with which URL
standard you want,
  but as it is now there is no such capability.
- It's a bit of a shame that the PSR interface treats queries as strings.
  In Javascript we have the URLSearchParams class that we can use as a key-value storage for query
parameters.
  This Javascript class also handles escaping them nicely.
- Why is UrlComponent a backed enum?
- A nit: We didn't bundle the entire Lexbor engine, only select parts of it. Just thought
I'd make it clear.
- About edge cases: e.g. what happens if I call the Url constructor and leave every string field
empty?

Overall seems good.

Kind regards
Niels


Thread (152 messages)

« previous php.internals (#124001) next »