Re: [RFC] [Discussion] Add WHATWG compliant URL parsing API
| From: | Máté Kocsis | Date: | Mon, 17 Mar 2025 19:58:27 +0000 |
| Subject: | Re: [RFC] [Discussion] Add WHATWG compliant URL parsing API | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-126813@lists.php.net to get a copy of this message | ||
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 follow the same path for consistency ? Instead
> of throwing an exception it should throw an Error on uninitialized issue
> at least.
>
Yes, you are right! Uri\UninitializedUriException should extend an Error
indeed,
since people shouldn't try to catch it either.
>
> 2) around Normalization. In case of query normalization, sorting the
> query string is not mention does it means that with the current feature
>
> http://example.com?foo=bar&foo=rab`
> <http://example.com?foo=bar&foo=rab>
> is different from
> http://example.com?foo=rab&foo=bar`
> <http://example.com?foo=rab&foo=bar>
>
>
Yes, that's the case, this feature is not implemented. As far as I see
though, it's better
not to change the order of query parameters, especially the order of
duplicated
parameters in order not to accidentally change the intended meaning of the
query string.
What's your stance here?
Máté