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 from user-supplied
content. I’m curious to hear from folks here hat fraction of the actual PHP
code deals with RFC3986 URLs, and of those, if the systems using them are
truly RFC3986 systems or if the common-enough URLs are valid in both specs.
I think Ignace's examples already highlighted that the two specifications
differ in nuances so much that even I had to admit after months of trying
to squeeze them into the same interface that doing so would be
irresponsible.
I think this is also a good argument in favor of finally making the classes final. Not making them final would allow for irresponsible sub-classes :-)
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 them.
I think the RFC is now mature enough to consider voting in the
foreseeable future, since most of the concerns which came up until now are
addressed some way or another. However, the only remaining question that I
still have is whether the Uri\Rfc3986\Uri and the Uri\WhatWg\Url classes
should be final? Personally, I don't see much problem with opening them for
Yes. Besides the remark above, my previous arguments still apply (e.g.
with()ers not being able to construct instances for subclasses, requiring to override all of them). I'm also noticing that serialization is unsafe with subclasses that add a
$__uri property (or perhaps any property at all?).
--------------------
We already had extensive off-list discussion about the RFC and I agree it's in a good shape now. I've given it another read and here's my remarks:
1.
The
toDisplayString() method that you mentioned above is not in the RFC. Did you mean
toHumanFriendlyString()? Which one is correct?
2.
The example output of the
$errors array does not match the stub. It contains a
failure property, should that be
softError instead?
3.
The RFC states "When trying to instantiate a WHATWG Url via its constructor, a Uri\InvalidUriException is thrown when parsing results in a failure."
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 WhatWgUrl, since
$errors is not applicable for 3986?
4.
The RFC does not specify when
UninitializedUriException is thrown.
5.
The RFC does not specify when
UriOperationException is thrown.
6.
Generally speaking I believe it would help understanding if you would add a
/** @throws InvalidUriException */ to each of the methods in the stub to make it clear which ones are able to throw (e.g. resolve(), or the withers). It's harder to find this out from “English” rather than “code” :-)
7.
In the “Component retrieval” section: Please add even more examples of what kind of percent-decoding will happen. For example, it's important to know if
%26 is decoded to
& in a query-string. Or if
%3D is decoded to
=. This really is the same case as with
%2F in a path. The explanation
"the URI is normalized (when applicable), and then the reserved characters in the context of the given component are percent-decoded. This means that only those reserved characters are percent-decoded that are not allowed in a component. This behavior is needed to be able to unambiguously retrieve components."
alone is not clear to me. “reserved characters that are not allowed in a component”. I assume this means that
%2F (/) in a path will not be decoded, but
%3F (?) will, because a bare
? can't appear in a path?
8.
In the “Component retrieval” section: You compare the behavior of WhatWgUrl and Rfc3986Uri. It would be useful to add something like:
$url->getRawScheme() // does not exist, because WhatWgUrl always normalizes the scheme
to better point out the differences between the two APIs with regard to normalization (it's mentioned, but having it in the code blocks would make it more visible).
9.
In the “Component Modification” section, the RFC states that WhatWgUrl will automatically encode
? and
# as necessary. Will the same happen for Rfc3986? Will the encoding of
# also happen for the query-string component? The RFC only mentions the path component.
I'm also wondering if there are cases where the withers would not round-trip, i.e. where
$url->withPath($url->getPath()) would not result in the original URL?
10.
Can you add examples where the authority / host contains IPv6 literals? It would be useful to specifically show whether or not the square brackets are returned when using the getters. It would also be interesting to see whether or not IPv6 addresses are normalized (e.g. shortening
2001:db8:0:0:0:0:0:1 to
2001:db8::1).
11.
In “Component Recomposition” the RFC states "The Uri\Rfc3986\Uri::toString() returns the unnormalized URI string".
Does this mean that toString() for Rfc3986 will always return the original input?
12.
It would be useful to know whether or not the classes implement
__debugInfo() / how they appear when
var_dump()ing them.
Best regards
Tim Düsterhus
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
0 - It is a unfortunate that there's no IDNA support for RFC3986, I understand the reasoning behind that decision but I was wondering if it was possible to optin its use when the ext-intl extension is present ?
1 - Does it means that if/when Rfc3986/Uri get Rfc3987 supports they will also get a