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. My
> understanding is also that it is primarily intended for interaction with
> web browsers or to embed these URLs into HTML. For access control, e.g.
> in your framework the RFC3986 URI should be used. It's what HTTP uses
> internally and it supports well-defined normalization.
>
> What do you think?
>
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.
Unintuive probably is not the best word. But I expect users to primarily
> interact with the path component of an URL (e.g. within their
> framework’s router). So I think it makes sense to be extra explicit with
> examples there. As an example, I recently learned that Symfony's router
> does not support (encoded) slashes within a component:
>
> #[Route('/test/{message}', name: 'test')]
>
> will work for http://localhost:8000/test/foo, but not for
> http://localhost:8000/test/foo%2fbar, resulting in:
>
> No route found for "GET http://localhost:8000/test/foo%2fbar";
>
> So if you would just extend the: “Let's have a look at some other tricky
> example with Uri\Rfc3986\Uri:” to my suggestion, I would be happy :-)
>
Alright, I'll add it. It won't hurt for sure!
Note: I believe there is a small mistake in the example when you last
> modified it. It says:
>
> echo $uri->getHost(); //
> [2001:0db8:0001:0000:0000:0ab9:C0a8:0102]
>
> Should the 'C' in 'C0a8' also be lowercased?
Yes, nice catch! I swear I double checked it multiple times if there was
any uppercase letters that should
be lowercased...
> So it indeed seems to be a limitation of the WHATWG specification and
> your PHP implementation is consistent with node.js. That is a good thing
> and when a user stumbles upon this, we can point them towards node.js /
> the spec. Not great, but this is workable!
>
Thank you for the test! To be honest, I pretty much don't like how WHATWG
setters are specified, they seem to behave very "ad hoc" based on what I
saw so far. :(
Regards,
Máté
