Repository navigation
Uri\Rfc3986\Uri::toString() doesn't drop an empty port #23965
Description
Activity
/cc @kocsismate @TimWolla
FYI Reposted from thephpleague/uri-src#215 (comment)
I have opened several bug reports for polyfill, but you may want to check whether some of them aren't PHP bugs. https://github.com/thephpleague/uri-src/issues?q=is%3Aissue%20author%3Akamil-tekiela
The normalization in question is mentioned in RFC 3986 (with a
SHOULDthough):Likewise, an explicit ":port", for which the port is empty or the default for the scheme, is equivalent to one where the port and its ":" delimiter are elided and thus should be removed by scheme-based normalization.
Currently, uriparser doesn't implement this normalization yet:
php-src/ext/uri/uriparser/src/UriNormalize.c
Line 688 in bb73942
I'll try to implement it sometime soon (although uriparser reviews take a lot of time nowadays).
P.S. this normalization option is mentioned wrt scheme-based normalization (section 6.2.1 in the RFC) which - by itself - is out of scope for a library implementing the generic URI syntax (uriparser/uriparser#173).
However, I'd argue that normalizing "https://example.com:" to "https://example.com" falls in the scheme-based normalization category, so maybe it's still worth a try to implement in uriparser, especially because the RFC references this case in another section:
URI producers and normalizers should omit the ":" delimiter that separates host from port if the port component is empty. Some schemes do not allow the userinfo and/or port subcomponents.
3.2.3 states:
URI producers AND normalizers should omit the port component and its ":" delimiter if port is empty or if its value would be the same as that of THE scheme's default.
This I would expect normalization to happen in uriparser.
Reacted by Máté KocsisI proposed uriparser/uriparser#342
Reacted by Ilija Tovilo
Description
The following code:
Resulted in this output:
But I expected this output instead:
PHP Version
Operating System
No response