Dealing with whitespaces in URI

[nyamsprod]

Description

According to RFC3986 an URI with spaces should not be parsable. It should throw so the following 3 URI should throw:

Example

• ' http://a.b/p?q#f' (space before the URI)
• 'http://a.b/p?q#f ' (space after the URI)
• 'http://a.b/ p?q#f' (space inside the URI)

Additional context

Because parse_url is not following RFC3986 all implementations that do rely on it will gladly let those URI pass when they should not see https://3v4l.org/iur9H

Maybe a test should be added to the test suite to fix this issue.

Of course the issue is not applicable for PSR-7 with* methods which MUST normalized the input and thus will convert any spaces into %20 character.

For reference when using URI implementing objects:

League\Uri\Http::new(' http://example.com/ foo?bar=baz#quz '); // will throw (on the master branch)
new \Laminas\Diactoros\Uri(' http://example.com/ foo?bar=baz#quz '); // will return a URI without a scheme and without an authority
new \GuzzleHttp\Psr7\Uri(' http://example.com/ foo?bar=baz#quz '); // will return an URI with a scheme and an authority

Of course the instantiation is not included in tests but I presume that the UriFactoryInterface::createUri will behave in the same manner in those packages.

I opened a similar issue on laminas-diactoros

[GrahamCampbell]

While the spec says this, in the real world, nobody follows the spec. This is unfortunate, in particularly because browsers very don't follow the specs. When faced with mimicking what browsers do, and strict spec compliance, we typically go with what browsers do. cURL takes the same approach. All that aside, I believe the very first space character before the scheme is an issue, and we are doing the wrong thing specially with that one.

[nyamsprod]

using turl from cURL: https://github.com/curl/trurl the submitted URI all fail. So I believe the cURL also will complain about those URL.

Having said that yes they do not fail on browsers but that's because browser follow WHATWG specs which are different from RFC3986.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 2 weeks if no further activity occurs. Thank you for your contributions.

[GrahamCampbell]

Not stale.