Possible bug in UriResolver::resovle

[Ahummeling]

Note: I am writing in the context of the UriResolver

PHP version:7.3.20
guzzlehttp/psr7 version:1.8.2

Description
Given a $base with path: "/api/v1" (I.e. a base path with > 1 segments and no trailing slash). And a $rel with path: "screening-profile", this function (UriResolver::resolve) ends up with a $targetPath of /api/screening-profile. (So the /v1 segment is lost). If this is expected behavior, sorry for bothering, perhaps you can point me to where I could have found this out myself, or somewhere I can contribute to documentation.

How to reproduce
Instantiate a guzzle client with a base_uri that doesn't end in a '/' and make a request to some path that does not start with a '/'.

Possible Solution
storing $base->getPath() in a local variable, appending a '/' to this if it not already there, seems to create the expected behavior. I'm happy to submit a pull request if desired.

Additional context
If a pull request is desired, perhaps I could be pointed to any relevant code / tests / documentation that should be updated as well.
A "workaround" is very simple. Simply make sure to end the base_uri in a trailing '/'

PR Adding Testcase
#439

[Nyholm]

Thank you for a great issue.

I am pretty sure this is the intended behavior. See base_uri in the quickstart guide. There is a table explaining how how different inputs are handled.

Is there a test case for your exact scenario?

[GrahamCampbell]

Having just read-read this I think @Nyholm is right that this is intended.

[Ahummeling]

Thanks for pointing me to the documentation.
I've gone over the existing test cases and I believe that my exact scenario was not yet tested directly, so I've added the relevant testcase and submitted a pull request.