Uri does not support relative paths about psr7 HOT 7 CLOSED

Actually, UriInterface recommends to convert paths to absolute in __toString() method. I assume adjusting path in mutator will not be an issue in most cases, but there are some edge cases, for example:

• ->withHost(...)->withPath(...) and ->withPath(...)->withHost(...) will produce different URIs in the current implementation, if the host "changes its emptyness". (new \GuzzleHttp\Psr7\Uri())->withPath('foo')->withHost('bar')->withScheme('http')->__toString() produces http://barfoo.
• $uri->withPath($newPath)->getPath() may return the path different from what was set

from psr7.

Ah I see. I think you're right about the first one, but the second case you presented is intentional.

If you have a URI of http://foo.com/bar, then it is impossible for the path to be foo since there is a host or scheme. Is there any wording in PSR-7 specifically forbidding that?

from psr7.

https://github.com/php-fig/http-message/blob/master/src/UriInterface.php#L116 makes me think the opposite

Normally, the empty path "" and absolute path "/" are considered equal as
defined in RFC 7230 Section 2.7.3. But this method MUST NOT automatically
do this normalization because in contexts with a trimmed base path, e.g.
the front controller, this difference becomes significant. It's the task
of the user to handle both "" and "/".

I don't really understand, but It sounds like it suggests to use the URI object in a way (similar to Apache's per-directory mod_rewrite), where the common leading part of the path is cut and the significant part is saved back without slash, while host is untouched. I can't really say if it's what was intended or if it's a good idea at all.

from psr7.

Edit: I really don't like a lot of the wording used in the URI interface for PSR-7. I think it could have been much clearer regarding relative paths. While I think my approach is better (because the string representation of the URI should match the parts at any given point in time), I'll revert this change and just do the normalization in the toString method. 😿

from psr7.

I totally like the change, as now it's again possible to set a base_uri and use a relative path in the UriInterface. The only thing is now, that for this use case the change is breaking.

e.g.:
base_uri http://example/project/
Uri: whatever

With the guzzle/psr7 1.0.0 i had to create an absolute uri /project/whatever.

$options['base_uri' => 'http://example/project/'];
$client = new Client($options);

$httpRequest = new Request('GET', 'whatever');
$uri = $httpRequest->getUri()->withPath($this->getProject() . $httpRequest->getUri()->getPath());
$httpRequest = $httpRequest->withUri($uri)

$client->send($httpRequest);

This doesn't work anymore with 1.1.0 but now the transformation is no more needed. So maybe add a note about the breaking change somewhere? Or also a test would be nice :)

from psr7.

@ct-jensschulze I think your transformation would still work if an absolute path would be passed to withPath(). It's not clear from the snippet, but it looks like $this->getProject() does not start with slash, but withPath() incorrectly added it according to this issue. Now that it's fixed, missing starting slash becomes significant. If there was starting slash, the snippet should have worked with both 1.0.0 and 1.1.0 without changes.
Actually, it's the same case that lead me to this bug report, as I've found impossible to pass the base_uri to the Client and a relative path to the Request and make Client merge them.

from psr7.

You are right. The project didn't had a starting slash. But as i do like the relative path Uri and that the base_uri is now correctly working, i justed raised the minimum version to 1.1 and fixed the issue on my side.

So it would be good to add a test that base_uri in client and relative path in UriInterface sets the correct path.

from psr7.