Description
According to RFC3986 an URI with spaces should not be parsable. It should throw so the following 3 URI should throw:
Example
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.
Bottom line, if this is an bug should some kind of clarification be added to PSR-7 to fix the inconsistencies 🤔
Description
According to RFC3986 an URI with spaces should not be parsable. It should throw so the following 3 URI should throw:
Example
Additional context
Because
parse_urlis not following RFC3986 all implementations that do rely on it will gladly let those URI pass when they should not see https://3v4l.org/iur9HMaybe 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%20character.For reference when using URI implementing objects:
Of course the instantiation is not included in tests but I presume that the
UriFactoryInterface::createUriwill behave in the same manner in those packages.Bottom line, if this is an bug should some kind of clarification be added to PSR-7 to fix the inconsistencies 🤔