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

Hi all, > On May 7, 2025, at 17:02, Gina P. Banyard wrote: > > On Wednesday, 7 May 2025 at 20:20, Paul M. Jones wrote: > >> I am on record as wanting very much to see some decent web-centric objects >> in core PHP (Request, Response, Uri/Url, etc). >> >> To my chagrin, despite the fact that

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

On Wednesday, 7 May 2025 at 20:20, Paul M. Jones wrote: > Hi Maté and all, > > > On May 5, 2025, at 16:36, Máté Kocsis kocsismat...@gmail.com wrote: > > > > Hello Internals, > > > > After more than a hundred emails refining even the tiniest details, we have > > reached a point where I'd like

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

Hi Maté and all, > On May 5, 2025, at 16:36, Máté Kocsis wrote: > > Hello Internals, > > After more than a hundred emails refining even the tiniest details, we have > reached a point where I'd like to call for a vote. > I know that the new API still doesn't support many use-cases, it still has

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

Hello Internals, After more than a hundred emails refining even the tiniest details, we have reached a point where I'd like to call for a vote. I know that the new API still doesn't support many use-cases, it still has missing pieces, but now it includes a cohesive set of functionality that could

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

Hi Paul, I would not presume that the dedicated value objects are what "makes the > [Rowbot] library much slower" than the RFC -- instead, my first intuition is that the *parsing* operations are slower in userland > than in C, and are primarily responsible for the comparative slowness. Speedwise

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

Hey Ignace, > I see you updated the RFC but I believe there's still some errors in the > example: > $url = Uri\WhatWg\Url::parse("/foo", ".com"); // Throws > Uri\WhatWg\InvalidUrlException because of $baseUri > After following the suggestion of Tim, I changed the type of the $baseUrl parameters

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

Hi Ignace, Why can't the Url::resolve method also expose the `$errors` parameter like > the constructor and the parse static method ? As far as I understand it > nothing prevents the API from exposing the errors during URI resolution > which is a proxy method for the constructor call just like the

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

Hi Ignace, I have just added the SensitiveParameter attribute to the Uri\Rfc3986\Uri::withUserInfo() and Uri\WhatWg\Url::withPassword() methods. > Reading the WHATWG URL specification and checking how > >- Chrome, >- Firefox >- and even https://github.com/TRowbotham/URL-Parser > > >

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

Hi Máté and Tim Why can't the Url::resolve method also expose the `$errors` parameter like the constructor and the parse static method ? As far as I understand it nothing prevents the API from exposing the errors during URI resolution which is a proxy method for the constructor call just like the

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

Hi Máté and Tim I read the following in the RFC >Withers of Uri\WhatWg\Url follow the relevant “setter steps” that are defined by WHATWG URL. Unfortunately, these algorithms sometimes have surprising behavior where modification fails silently, and t

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

Hi Paul, I will try to address your concerns. Keep in mind that I am not the author of the RFC but I do like how it is currently shaped with some caveats but those can be put under future improvements. > So, one value added by splitting the classes is to resolve that asymmetry. First, I agree wi

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

Hi On 4/29/25 10:54, ignace nyamagana butera wrote: I have one last question while reviewing my polyfill implementation. Is it worth it adding a SensitiveParameter attribute on the argument of the following methods ? - Uri\Rfc3986\Uri::withUserInfo - Uri\WhatWg\Url::withPassword I'm fine with

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

Hi Ignace & Maté and all, tl;dr: I argue against Ignace's objections to splitting the URI class into two classes (one that retains raw URI values and another that normalizes values as-it-goes). Jump to the very end for a discussion regarding the with() methods (search for the word "asymmetry" h

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

Hi Maté and Time, I have one last question while reviewing my polyfill implementation. Is it worth it adding a SensitiveParameter attribute on the argument of the following methods ? - Uri\Rfc3986\Uri::withUserInfo - Uri\WhatWg\Url::withPassword I'm fine with any answer ? Does it warrant a parag

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

Hi Maté, > I fiddled a little bit with the implementation, and I went with the Uri\UriComparisonMode enum name at last. I hope that it is OK on your side. If no one objects with your name choice I am fine with it, as long as it is not a boolean :) I will adapt my polyfill. I think I have no more

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

Hi Ignace, The $excludeFragment is `true` by default so in the example it should be > `false` instead. Perhaps using an Enum instead would make the > DX easier than using a boolean ? > I believe the same issue is in all examples regarding the use of that > parameter. > You are right, I completely

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

Hi Paul, > The Rfc3986\Uri `raw()` methods present a departure from existing userland expectations when working with URIs. No existing URI package that I'm aware of retains the normalized values as their "main" values; the values are generally retained-as-given (i.e. "raw"). Nor do they afford get

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

Hi Maté and all, > On Apr 27, 2025, at 16:47, Máté Kocsis wrote: > > Hi Tim, ... >> 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. > > We discussed this off the list, an

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

On Mon, Apr 28, 2025 at 9:05 AM ignace nyamagana butera wrote: > Hi Maté, > > I found another typo in the RFC examples due to the use of boolean as > parameters > > // The fragment component of Uri\WhatWg\Url can also be taken into > account$url = new Uri\WhatWg\Url("https://example.com#foo";);$

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

Hi Maté, I found another typo in the RFC examples due to the use of boolean as parameters // The fragment component of Uri\WhatWg\Url can also be taken into account$url = new Uri\WhatWg\Url("https://example.com#foo";);$url->equals(new Uri\WhatWg\Url("https://example.com";), true); // false The $

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

Hi On 4/27/25 23:47, Máté Kocsis wrote: […] Thank you. I have just given the RFC another full read (the 2025/04/27 21:44 version) and I do not have any further remarks. I'm happy with everything that is said in the RFC and I'm really looking forward to vote “Yes” :-) Best regards Tim Düst

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

Hi Tim, > 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`

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

Hi On 4/27/25 22:50, ignace nyamagana butera wrote: I understand that but then I fail to see the added value of the parse method vs the default constructor since from the RFC the only difference is that the parse named constructor should instead of throwing return null. If the parse method can s

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

Le dim. 27 avr. 2025, 22:32, Tim Düsterhus a écrit : > Hi > > On 4/27/25 22:30, ignace nyamagana butera wrote: > > $url = Uri\WhatWg\Url::parse("/foo", ".com"); // > > Throws Uri\WhatWg\InvalidUrlException because of $baseUri > > > > Since parse is used shouldn't it return null in

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

Hi On 4/27/25 22:30, ignace nyamagana butera wrote: $url = Uri\WhatWg\Url::parse("/foo", ".com"); // Throws Uri\WhatWg\InvalidUrlException because of $baseUri Since parse is used shouldn't it return null instead of throwing ? In this case the `$baseUri` is invalid. Since this

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

Hi Maté I see you updated the RFC but I believe there's still some errors in the example: $url = Uri\WhatWg\Url::parse("/foo", ".com"); // Throws Uri\WhatWg\InvalidUrlException because of $baseUri Since parse is used shouldn't it return null instead of throwing ? $uri = Uri\Rfc

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

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 adju

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

Hi Maté and all, A one-off comment about the exceptions: The RFC posits that _Uri\UriException_ extends _Exception_, and _Uri\InvalidUriException_ extends _UriException_. However, pre-existing userland solutions to the URI problem lean more heavily on the native PHP _InvalidArgumentException_,

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

Hi On 4/17/25 23:14, Paul M. Jones wrote: On 4/17/25 22:47, Paul M. Jones wrote: As such, the _InvalidUriException_ would better extend from _LogicException_. No. There is a de facto policy of “not using SPL exceptions in new code”. The replacement for LogicException is the Error hierarchy.

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

> On Apr 17, 2025, at 15:58, Tim Düsterhus wrote: > > Hi > > On 4/17/25 22:47, Paul M. Jones wrote: >> As such, the _InvalidUriException_ would better extend from _LogicException_. > > No. There is a de facto policy of “not using SPL exceptions in new code”. The > replacement for LogicExcep

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

Hi On 4/17/25 22:47, Paul M. Jones wrote: As such, the _InvalidUriException_ would better extend from _LogicException_. No. There is a de facto policy of “not using SPL exceptions in new code”. The replacement for LogicException is the Error hierarchy. Also, as you quoted yourself, LogicExc

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

Hi Ignace, > Currently the path is nullable but according to the RFC the path can not > be nullable > According to the RFC the path can have up to 5 ABNF representation > Uh, this is something that I also forgot to sync between the implementation and the RFC. I also recently found out that the g

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

Hi Ignace, > Uh, this is something that I also forgot to sync between the > implementation and the RFC. I also recently found out that > the get*Path() methods should be non-nullable for both classes, so I > recently fixed them. Sorry for the confusion! > Actually, I realized after checking the

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

I still have one last question regarding the RFC3986 URI path component. Currently the path is nullable but according to the RFC the path can not be nullable According to the RFC the path can have up to 5 ABNF representation > path = path-abempty ; begins with "/" or is empty

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

Hi, Tim Düsterhus ezt írta (időpont: 2025. ápr. 17., Cs, 9:22): > Hi > > Am 2025-04-15 23:55, schrieb Máté Kocsis: > > This was one of my (unspoken) ideas as well. I used to think there must > > have been a correct logic > > for percent-decoding of WHATWG components, but if none of us can come

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

Hi Am 2025-04-15 23:55, schrieb Máté Kocsis: This was one of my (unspoken) ideas as well. I used to think there must have been a correct logic for percent-decoding of WHATWG components, but if none of us can come up with a sensible idea, then it's best not to try it, I agree. Sweet. I believ

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

Hi Tim, > 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. M

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

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 understandin

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

Hi Am 2025-04-13 14:10, schrieb Máté Kocsis: namespace Uri { class InvalidUriException extends \Uri\UriException { } } namespace Uri\WhatWg { class InvalidUrlException extends \Uri\InvalidUriException { /** @var list */

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

Hi Tim, I think I would prefer: > > namespace Uri { > class InvalidUriException extends \Uri\UriException > { > } > } > > namespace Uri\WhatWg { > class InvalidUrlException extends \Uri\InvalidUriException { > /** @var list */ >

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

Hey Ignace, (let me answer in the original thread, as apparently the discussion continued in a separate thread from the main one) > - I believe during normalization of IPv6 host the letter a-f should be > lowercase in accordance with the RFC since > > RFC3986 follows https://www.rfc-editor.org/rf

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

Hi Ignace, it might be brought back for future improvements. > > Yes, surely! > I have one last question regarding the URI implementations which are raised > by my polyfill: > > Did you also took into account the delimiters when submitting data via the > withers ? In other words is > > ```php

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

Hi Ignace, > I spotted another inconsistency in the normalization under RFC3986 > Thanks for spotting this: apparently, it is due to a small bug in the uriparser library, which I managed to fix locally, PR is on its way to upstream. Máté

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

Hi Ignace & Maté & all, > On Mar 19, 2025, at 16:18, Ignace Nyamagana Butera > wrote: > > https://github.com/bakame-php/aide-uri/blob/main/src/Uri.php > While implementing the polyfill I am finding easier DX wise to make the > constructor private and use instead named constructors for instant

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

On 02/04/2025 19:59, Máté Kocsis wrote: Hi Ignace, I spotted another inconsistency in the normalization under RFC3986 Thanks for spotting this: apparently, it is due to a small bug in the uriparser library, which I managed to fix locally, PR is on its way to upstream. Máté Hi Máté

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

Hi Ignace, > upon further inspection and verification of RFC3986 I also see an issue > with the example used for normalization in the RFC. According to RFC3986 ( > https://www.rfc-editor.org/rfc/rfc3986.html#section-3.2.2) : > > The reg-name syntax allows percent-encoded octets in order to >

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

On 30/03/2025 22:53, Ignace Nyamagana Butera wrote: On 30/03/2025 14:42, Tim Düsterhus wrote: 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. Unfo

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

On 30/03/2025 14:42, Tim Düsterhus wrote: 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 ma

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

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

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

Hi Apologies for getting back to you just now. On 3/2/25 23:00, Máté Kocsis wrote: What happens for Rfc3986 when passing an invalid URI to the constructor? Will an exception be thrown? What will the error array contain? Is it perhaps necessary to subclass Uri\InvalidUriException for use with W

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

Hi On 3/12/25 23:00, Máté Kocsis wrote: I'm not sure if I'm entirely correct, but it's possible that a 3rd party URI implementation won't (or cannot) use PHP's memory manager, and it relies on the regular malloc: in this case, even memory errors could lead to failures. We already discussed thi

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

Hi On 3/22/25 15:01, Paul M. Jones wrote: However, WHATWG-URL consistently calls it `username`, putting the URL portion of the RFC at odds with the WHATWG-URL spec. Calling it `username` would be more in line with the spec. That would likely mean calling it `username` in the URI portion of th

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

Hi Larry and everyone who took part in the final vs non-final debate, Thought: make the class non-final, but all of the defined methods final, > and any internal data properties private. That way we know that a child > class cannot break any of the existing guarantees, but can still add > conveni

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

> On Mar 25, 2025, at 3:23 PM, Máté Kocsis wrote: > > > Hi Dennis, > > >> I am myself also a bit lost on the countless names that I tried out in the >> implementation, but I think I had toHumanFriendlyString() and >> toDisplayFriendlyString() methods at some point. These then ended up being

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

Hi Maté and all, > On Mar 25, 2025, at 03:45, Máté Kocsis wrote: Regarding Rowbot slowness compared to the RFC: > I can only assume that the excessive usage of objects makes the library much > slower than what's possible > even for a userland library (obviously, an internal C implementation w

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

On 27/03/2025 22:04, Máté Kocsis wrote: Hi Ignace, While implementing the polyfill I am finding easier DX wise to make the constructor private and use instead named constructors for instantiation. I would be in favor of `Uri::parse` and `Uri::tryParse` like it is done currently

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

Hi Ignace, While implementing the polyfill I am finding easier DX wise to make the > constructor private and use instead named constructors for instantiation. I > would be in favor of > > `Uri::parse` and `Uri::tryParse` like it is done currently with Enum and > the `from` and `tryfrom` named cons

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

> On Mar 25, 2025, at 4:06 PM, Dennis Snell wrote: > > >> On Mar 25, 2025, at 3:23 PM, Máté Kocsis wrote: >> >> >> Hi Dennis, >> >> >>> I am myself also a bit lost on the countless names that I tried out in the >>> implementation, but I think I had toHumanFriendlyString() and >>>

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

Hi Dennis, I am myself also a bit lost on the countless names that I tried out in the > implementation, but I think I had toHumanFriendlyString() and > toDisplayFriendlyString() methods at some point. These then ended up being > toString() and toDisplayString() after some iterations. I would be ok

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

Hi Paul, ## Rowbot > > (None of the classes are readonly or final; these look to hew closely to > the WHATWG-URL spec.) > > A BasicURLParser class: > > - affords relative parsing capability and an option parameter for the > target URLRecord > - returns a URLRecord > > A URLRecord class: > > - publ

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

On 17/03/2025 20:58, Máté Kocsis wrote: Hi Ignace, 1) around `Uri\UninitializedUriException` If I look at the behaviour of `DatetimeImmutable` in the same scenario or a Userland object instead of throwing an exception an error is thrown see: - https://3v4l.org/d4Vr

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

Hi Maté, > On Mar 18, 2025, at 15:15, Máté Kocsis wrote: > > There's no way I would have written an implementation from scratch. I'm using > the url module of the Lexbor C library (https://github.com/lexbor/lexbor/) > for handling WHATWG URLs. It's already bundled in core, and it's also batt

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

Hi Paul, > If we want a full-featured WHATWG-URL implementation in core, would it not > be preferable (with Trevor's permission) to convert rowbot/url from > userland to core instead? Surely conversion from an existing, well-tested, > widely-used implementation would be easier/better/faster than

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

Hi Maté and all, There is a pre-existing userland implementation of WHATWG-URL at . Packagist reports 600K+ downloads . It is from Trevor Rowbotham, who is acknowledged in the WHATWG-URL specification itself <

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

Hi Ignace, 1) around `Uri\UninitializedUriException` If I look at the behaviour of > `DatetimeImmutable` in the same scenario or a Userland object instead of > throwing an exception an error is thrown > > see: > > - https://3v4l.org/d4VrY > - https://3v4l.org/Wn7En > > Shouldn't the URI feature fo

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

Hi Dennis, > This is a late thought, and surely amenable to a later RFC, but I was > thinking about the get/set path methods and the issue of the / and %2F. > > - If we exposed `getPathIterator()` or `getPathSegments()` could we not > report these in their fully-decoded forms? That is, because t

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

Hi, Depends on there being the intention to have it as parameter type. If it's > designed to be passed around to functions I really don't want it to be an > array. I am maintaining a legacy codebase where arrays are being used as > hashmaps pretty much everywhere, and it's error prone. We lose all

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

Hi Nicolas, For now, let me just quickly respond to your question regarding __debugInfo(): The RFC is also missing whether __debugInfo returns raw or non-raw > components. Then, I'm wondering if we need this per-component break for > debugging at all? It might be less confusing (on this encoding

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

On 14/03/2025 20:45, Máté Kocsis wrote: Hi Ignace,  > All URI components - with the exception of the host - can be retrieved in two formats: I believe you mean - with the excepotion of the Port Even though I specifically meant WHATWG's host that is only available in only one for

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

Hi Ignace, > > All URI components - with the exception of the host - can be > retrieved in two formats: > > I believe you mean - with the excepotion of the Port > > Even though I specifically meant WHATWG's host that is only available in only one format, you are right, the port is never availabl

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

Hi Hammed, What's wrong with declaring all the methods as final eg. > https://github.com/lnear-dev/ada-url/blob/main/ada_url.stub.php I've just noticed your message, sorry. Coincidentally - as I wrote a few days ago -, I'm also experimenting with making methods final. Máté >

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

Hi Tim, > The same is true for `UriOperationException`. The RFC says that it can > happen for memory issues. Can this actually happen? My understanding is > that the engine bails out when an allocation fails. In any case if a > more graceful handling is desired it should be some generic > `OutOfM

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

On Mon, Mar 10, 2025, at 5:51 PM, Máté Kocsis wrote: > I'm sure that people will find their use-cases to subclass all these > new classes, including the WHATWG implementation. As Nicolas mentioned, > his main use-case is minly adding convenience and new factory methods > that don't specifically

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

Hi Juris and Tim, > Am 2025-02-23 18:47, schrieb Juris Evertovskis: > > As those are URI validation errors, maybe something like > > `Uri\WhatWg\ValidationError` would be both less clashy and less > > redundant? > > I like that suggestion. > > Best regards > Tim Düsterhus > I liked it as well, s

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

Hi Gina, 1. > The paragraph in at the beginning of the RFC in the > Relevant URI > specifications > WHATWG URL section seems to be incomplete. > Hopefully it's good now. Although I know this section doesn't include much information. 2. > I don't really understand how the UninitializedUriExceptio

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

> On Feb 16, 2025, at 3:01 PM, Máté Kocsis wrote: > > > Hi Dennis, >> >> I only harp on the WhatWG spec so much because for many people this will be >> the only one they are aware of, if they are aware of any spec at all, and >> this is a sizable vector of attack targeting servers from user-s

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

Hi Tim, Thank you again for the thorough review! > The naming of these methods seems to be a little inconsistent. It should > either be: > > ->getHostForDisplay() > ->toStringForDisplay() > > or > > ->getDisplayHost() > ->toDisplayString() > > but not a mix between both of t

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

On Fri, Feb 28, 2025, at 09:38, Lynn wrote: > > > On Fri, Feb 28, 2025 at 12:05 AM Rob Landers wrote: >> __ >> >> >> On Thu, Feb 27, 2025, at 22:01, Faizan Akram Dar wrote: >>> Hi, >>> >>> >>> On Thu, 27 Feb 2025, 20:55 Paul M. Jones, wrote: > On Feb 25, 2025, at 09:55, ignace

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

On Fri, Feb 28, 2025 at 12:05 AM Rob Landers wrote: > > > On Thu, Feb 27, 2025, at 22:01, Faizan Akram Dar wrote: > > Hi, > > > On Thu, 27 Feb 2025, 20:55 Paul M. Jones, wrote: > > > > On Feb 25, 2025, at 09:55, ignace nyamagana butera > wrote: > > > > The problem with your suggestion is that t

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

On Thu, Feb 27, 2025, at 22:01, Faizan Akram Dar wrote: > Hi, > > > On Thu, 27 Feb 2025, 20:55 Paul M. Jones, wrote: >> >> > On Feb 25, 2025, at 09:55, ignace nyamagana butera >> > wrote: >> > >> > The problem with your suggestion is that the specification from WHATWG and >> > RFC3986/398

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

Hi, On Thu, 27 Feb 2025, 20:55 Paul M. Jones, wrote: > > > On Feb 25, 2025, at 09:55, ignace nyamagana butera > wrote: > > > > The problem with your suggestion is that the specification from WHATWG > and RFC3986/3987 are so different and that the function you are proposing > won't be able to c

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

> On Feb 25, 2025, at 09:55, ignace nyamagana butera > wrote: > > The problem with your suggestion is that the specification from WHATWG and > RFC3986/3987 are so different and that the function you are proposing won't > be able to cover the outcome correctly (ie give the developper all the

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

On 24/02/2025 12:08, Nicolas Grekas wrote: Hi, Thanks for all the efforts making this RFC happen, it'll be a game changer in the domain! I'm seeing a push to make the classes final. Please don't! This would badly break the open/closed principle to me. When shipping a new class, one ships two

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API , "Gina P. Banyard"

On 25/02/2025 13:36, Paul M.Jones wrote: Hi there, On Feb 24, 2025, at 03:36, Tim Düsterhus wrote: ... but had a look at the “after-action summary” thread and specifically Côme’s response, which you apparently agreed with: My take on that is more that functionality in core needs to be «

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

Hi there, > On Feb 24, 2025, at 03:36, Tim Düsterhus wrote: > ... > > but had a look at the “after-action summary” thread and specifically Côme’s > response, which you apparently agreed with: > >> My take on that is more that functionality in core needs to be «perfect», or >> at least near u

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

Hi Am 2025-02-24 15:05, schrieb Hammed Ajao: What's wrong with declaring all the methods as final eg. https://github.com/lnear-dev/ada-url/blob/main/ada_url.stub.php It is not possible to construct a subclass in a generic fashion, because you don't know the constructor’s signature and you als

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

Le lun. 24 févr. 2025 à 14:57, Gina P. Banyard a écrit : > On Monday, 24 February 2025 at 11:08, Nicolas Grekas < > nicolas.grekas+...@gmail.com> wrote: > > I'm seeing a push to make the classes final. Please don't! > This would badly break the open/closed principle to me. > > When shipping a new

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

Am 24.02.2025 um 14:57 schrieb Marco Pivetta: The `DateTimeImmutable` type should've been `final` from the start: it is trivial to declare a userland interface, and then use the `DateTimeImmutable` type as an implementation detail of a userland- provided interface. +1

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

What's wrong with declaring all the methods as final eg. https://github.com/lnear-dev/ada-url/blob/main/ada_url.stub.php On Mon, Feb 24, 2025, 7:00 a.m. Gina P. Banyard wrote: > On Monday, 24 February 2025 at 11:08, Nicolas Grekas < > nicolas.grekas+...@gmail.com> wrote: > > I'm seeing a push to

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

On Monday, 24 February 2025 at 11:08, Nicolas Grekas wrote: > I'm seeing a push to make the classes final. Please don't! > This would badly break the open/closed principle to me. > > When shipping a new class, one ships two things: a behavior and a type. The > behavior is what some want to clos

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

On Mon, 24 Feb 2025 at 14:45, Nicolas Grekas wrote: > > > Am 2025-02-24 12:08, schrieb Nicolas Grekas: >> > The situation I'm telling about is when one will accept an argument >> > described as >> > function (\Uri\WhatWg\Url $url) >> > >> > If the Url class is final, this signature means only one

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

Am 2025-02-24 12:08, schrieb Nicolas Grekas: > > The situation I'm telling about is when one will accept an argument > > described as > > function (\Uri\WhatWg\Url $url) > > > > If the Url class is final, this signature means only one possible > > implementation can ever be passed: the native one.

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

Hi Am 2025-02-24 12:08, schrieb Nicolas Grekas: The situation I'm telling about is when one will accept an argument described as function (\Uri\WhatWg\Url $url) If the Url class is final, this signature means only one possible implementation can ever be passed: the native one. Composition canno

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

Hi, Thanks for all the efforts making this RFC happen, it'll be a game changer in the domain! I'm seeing a push to make the classes final. Please don't! This would badly break the open/closed principle to me. When shipping a new class, one ships two things: a behavior and a type. The behavior is

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

Hi Am 2025-02-24 10:18, schrieb Ignace Nyamagana Butera: 5 - Can the returned array from __debugInfo be used in a "normal" method like `toComponents` naming can be changed/improve to ease migration from parse_url or is this left for userland library ? I would prefer not expose this functional

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

Hi Am 2025-02-23 18:57, schrieb Paul M. Jones: In earlier discussions on the [Server-Side Request and Response objects](https://externals.io/message/108436) RFC and the [after-action sumamry](https://externals.io/message/109563), one of the common non-technical objections was that it would bet

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

On 21/02/2025 13:06, Tim Düsterhus wrote: Hi Am 2025-02-16 23:01, schrieb Máté Kocsis: I only harp on the WhatWG spec so much because for many people this will be the only one they are aware of, if they are aware of any spec at all, and this is a sizable vector of attack targeting servers fro

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

Hi Am 2025-02-23 18:47, schrieb Juris Evertovskis: As those are URI validation errors, maybe something like `Uri\WhatWg\ValidationError` would be both less clashy and less redundant? I like that suggestion. Best regards Tim Düsterhus

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

Hi Am 2025-02-23 18:30, schrieb Gina P. Banyard: 2. I don't really understand how the UninitializedUriException exception can be thrown? Is it somehow possible to create an instance of a URI without initializing it? It's mentioned in the RFC (it was not yet, when I read through the RFC): Th

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

On Sunday, 23 February 2025 at 17:57, Paul M. Jones wrote: > Hi all, > > In earlier discussions on the Server-Side Request and Response objects RFC > and the after-action sumamry, one of the common non-technical objections was > that it would better be handled in userland. > > Seeing as there

  1   2   >