withRequestTarget() accepts string only

[BenMorel]

As far as I can see, withRequestTarget() only accepts a string.

[localheinz]

👍

[BenMorel]

Anyone..?

[weierophinney]

Requires an errata vote. One reason why it allows non-strings is to potentially allow passing a UriInterface, which can be cast to a string in order to obtain the request target.

As such, narrowing the scope has the potential to break existing implementations and/or consumers.

[sharifzadesina]

@weierophinney mixed means we can pass an array, a resource and etc... how people can know the mixed means string|UriInterface? as I have seen all psr-7 implementations are just support string.

[tehransenf]

perfect good post
thanks a lot

[AeonDigital]

I'm doing my own implementation of "RequestInterface" and am in doubt about how the "withRequestTarget" and "withUri" methods should work relative to their respective values ​​since:

If I use "withRequestTarget" passing as an argument a value that is totally different from the information that is contained in the respective "uri" object (especially with regards to the results of the "getPath" and "getQuery" methods) will result in a new "RequestInterface" instance where these values ​​do not match.

Is this supposed to be the case?

I know that the "requestTarget" is more complex than the simple join of "getPath" and "getQuery" but I would like to resolve this question in particular because I noticed that implementation made by the slim framework (https://github.com/slimphp/Slim-Http/blob/master/src/Request.php) uses the "getPath" and "getQuery" methods to form the "requestTarget" value, which seems to me to be a direct correlation between these values and I think that perhaps this correlation is at some level necessary for the purposes of the classes that implement the "RequestInterface"

[weierophinney]

@AeonDigital Please do not hijack an existing pull request to ask unrelated questions.

To answer you, however: if a request target is provided to the request instance, that value should be used instead of the composed UriInterface for purposes of generating the request target in the request line.

If no request target is set, then the default, per RFC 7230 section 2.7 is to use origin-form, which is the path + query parameters (if any exist).

[Art4]

This issue is resolved by #94.

[BenMorel]

@weierophinney Good!

I can see that it has finally been restricted to string though?

[weierophinney]

@BenMorel Correct. The spec uses RFC 7230 as a guide here, and the withRequestTarget() method is supposed to mirror getRequestTarget(), which specifies a string return value. The point of the method is to allow providing an replacement/alternative for what would normally be auto-discovered from the composed URI instance, and such values will always be strings.