Uri\Rfc3986\Uri path normalization during parsing

[nyamsprod]

Description

The following code:

<?php
use Uri\Rfc3986\Uri;

echo (new Uri('foo/bar'))->withPath('//foo')->toString();

Resulted in this output:

//foo

But I expected this output instead:

Uri\InvalidUriException should be thrown because if there is no authority the path `//foo` cannot start with a `//`.

PHP Version

Runtime:       PHP 8.5.0-dev

Operating System

No response

[TimWolla]

The output is incorrect indeed. This is an issue with the normalization. When you use toRawString() you'll see that the withPath() method behaved correctly by prefixing /..

[nyamsprod]

I did this

var_dump(
    new Uri('')->withPath(':/'),
    new Uri('foo/bar')->withPath('//foo')
    new Uri('foo/bar')->withHost('host')
);

And I see that:

• in the case of the first URI, the raw path is converted to "./:/", a ./ segment is prepended;
• in the case of the second URI, the raw path is converted to "/.//foo" a /. segment is prepended;
• in the third case, the raw path is converted to "/foo/bar" a "/" is prepended

In all cases the prepended segment is different, and the outcome is different from what I expected. I fail to see where in RFC3986 this additions are explained or mandatory, hence why I was expecting an exception to be thrown.

From what I understand this is to avoid Exception to be thrown on parsing when the submitted path is incorrect but RFC3986 states that if a rule can not be applied on parsing an Exception should be thrown and parsing should fail/stop. There is no fallback mechanism, hence my surprise.

[TimWolla]

The output is incorrect indeed. This is an issue with the normalization.

Reported upstream at uriparser/uriparser#262.

[TimWolla]

in the case of the first URI, the raw path is converted to "./:/", a ./ segment is prepended;

I explained that in: #19896 (comment)

in the case of the second URI, the raw path is converted to "/.//foo" a /. segment is prepended;

Please see the discussion at: uriparser/uriparser#249 (comment)

in the third case, the raw path is converted to "/foo/bar" a "/" is prepended

I find it reasonable to interpret this as resolving a relative path reference against the given authority.

---

From what I understand this is to avoid Exception to be thrown on parsing when the submitted path is incorrect but RFC3986 states that if a rule can not be applied on parsing an Exception should be thrown and parsing should fail/stop. There is no fallback mechanism, hence my surprise.

For the setters we are not really parsing a URI. We already have a parsed URI with well-specified structured components and are replacing individual components. As far as I can tell, RFC 3986 does not specify an algorithm for replacing individual components in an URI and there is no mechanism to validate individual components in a vacuum. I'd say that applying these “lossless” transformations match the users expectations of not making the setters conditionally fail on specific inputs.

Pinging @hartwork as the author of the upstream library.

[nyamsprod]

@TimWolla and @hartwork I tried to fix my polyfill by integrating your resolution. But It was still failing for the normalization:

scheme:/.//foo -> being normalized to scheme://foo which is wrong according to the spec.

My proposal would be to perform the following normalization

scheme:/.//foo to be normalized into scheme:////foo why 4 slashes ?

The first two // represents an empty authority which IMHO would solve the issue and avoid security errors ?

Of note using an empty authority MAY result on some URI to be rejected by scheme base URI that do not support them like the http(s) schemes.

[TimWolla]

My proposal would be to perform the following normalization

Please see uriparser/uriparser#263 for my proposed upstream fix of that case.

[nyamsprod]

@TimWolla I have match your proposal and added more tests. to make sure dot-segment removal still happens in other part of the path.