Re: [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/rfc/rfc3513 which > has been > replaced by https://www.rfc-editor.org/rfc/rfc4291 which is > updated by > https://www.rfc-editor.org/rfc/rfc5952#section-4.3 which > recommends > lowecasing the letters. (yeah that was quite a digging I know 🙂 ) > That's quite a long chain of RFC updates.... But yes, RFC 3986 explicitly mentions this here: Although host is case-insensitive, producers and normalizers should use > lowercase for registered names and hexadecimal addresses for the sake of > uniformity, while only using uppercase letters for percent-encodings. And that's what the current implementation does. :) > - Since the withers expect well encoded components does it means that it > is the same for the constructor. What is > > the expected result for the following code ? > > ```php > > $uri = new > Uri\Rfc3986\Uri("https://example,com/?foo[]=1&foo[]=2" > <https://example,com/?foo[]=1&foo[]=2>); > ``` > > Should the above trigger an exception because the query component contain invalid characters or > is it acceptable ? Asking because currently our dear old parse_url does not fail on this and > probably most PHP developers expect this not to fail. > > IMHO I am in favor of it failing to get a consistent experience when using the class because > otherwse you introduce an inconsistency between the constructor behaviour and the rest of the > class > API. > > Yes, generally, creation or any mutation of Uri\Rfc3986\Uri fails when the URI is invalid, exactly in order to offer a consistent experience. Regards, Máté >