URI normalization for Uri\Rfc3986\Uri

[nyamsprod]

Description

The following code:

<?php
use Uri\Rfc3986\Uri;

$a = new Uri('http://www.example.com/');
$b = new Uri('http://www.example.com');

Resulted in this output:

$a->toString(); // returns 'http://www.example.com/'
$b->toString(); // returns 'http://www.example.com'

But I expected this output instead:

$a->toString(); // returns 'http://www.example.com/'
$b->toString(); // returns 'http://www.example.com/'

Following the RFC3986 specification

PHP Version

PHP 8.5.0beta1 (cli) (built: Aug 18 2025 13:04:01) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.5.0-dev, Copyright (c) Zend Technologies
    with Zend OPcache v8.5.0beta1, Copyright (c), by Zend Technologies

Operating System

MacOS

[TimWolla]

That one is interesting. It's within the scheme-based normalization section, but specifies:

In general, a URI that uses the generic syntax for authority with an empty path should be normalized to a path of "/".

(highlighting mine)

In any case, normalization is not done by PHP itself, but by the uriparser upstream library. I'll forward the issue there, if you don't beat me to it.

[TimWolla]

Reported upstream at uriparser/uriparser#260. I'm closing here, since this is not really actionable by PHP itself. Please subscribe to the upstream issue if you want to get updated.

[hartwork]

Reported upstream at uriparser/uriparser#260.

@TimWolla thank you! 👍

I'm closing here, since this is not really actionable by PHP itself.

For the record, I don't see how it would not be actionable by PHP if not addressed within uriparser.

[TimWolla]

I don't see how it would not be actionable by PHP if not addressed within uriparser.

Yes, it would technically be actionable. But I do not consider it a good idea to diverge from uriparser does, the API provided by PHP is a relatively thin wrapper around uriparser and thus it would be equally actionable by the user of PHP as:

use Uri\Rfc3986\Uri;

$b = new Uri('http://www.example.com');

if ($b->getHost() !== null && $b->getPath() === '') {
    $b = $b->withPath('/');
}

var_dump($b->toString());

[nyamsprod]

@TimWolla as long as the behaviour is documented I'm fine with it. if not documented I presume other will report it.

[hartwork]

@TimWolla good point and clarification 👍

I'm with @nyamsprod in that it could be worth stating in PHP that URI normalization is syntax-based normalization a la section 6.2.2 of RFC 3986 in particular and nothing more (implying not 6.2.3 and not 6.2.4). Whether it will help our very case here, I am not sure.

[kocsismate]

FWIW the RFC briefly mentions that the implementation follows the generic syntax without scheme-specific behavior around the end of the wall of text:

Note: It should also be taken into account that Uri\Rfc3986\Uri implements the generic URI syntax upon which scheme-specific syntax can be built (probably one of the most well-known examples is LDAP URIs). When designing an implementation for a scheme-specific URI syntax, it would seem very straightforward to extend Uri\Rfc3986\Uri, and adapt it to the specific purpose. But this is a wrong choice based on the Liskov-Substitution Principle, which states that a child class should be able to substitute its parent without breaking the program.