RequestInterface

[Anton Fedonjuk]

$uri = new Uri('http://www.site.com/where?q=now');
$request = $request->withRequestTarget('http://www.example.org/pub/page.html')->withUri($uri);

withUri must change request-target?

[Anton Fedonjuk]

If no URI is available, and no request-target has been specifically provided, this method MUST return the string "/".

how uri can be not available?

[Anton Fedonjuk]

$request->withRequestTarget('http://www.example.org/pub/page.html');

method must change "Host" header and/or URI?

 

I ask because all the PSR-7-compatible packages that I saw don't do this. I think it's happened because note added only for withUri.

[Matthew Weier O'Phinney]

I think you're not understanding the purpose of the request-target within a request.

Section 1.4 of the PSR-7 spec details the purpose, and how different values are interpreted. The point to understand, however, is that these serve a different purpose than the composed UriInterface. The UriInterface is used by a client in order to determine the protocol, port, and hostname so that the client can connect to the server in question. The request-target is the value used as the second segment of the request line when transmitting the request.

In PSR-7, if no request-target is provided, then the string form of the URI fills in as an absolute-form request-target.

Because the request-target can take a variety of forms that are not compliant with a UriInterface implementation (e.g., asterix-form, for OPTIONS requests; authority-form, for CONNECT requests; origin-form, which is typically only the pat; etc.), we allow setting it _separately_ from the URI. This means that setting it MUST NOT change the URI, as the point is that this is to customize the request line, and otherwise not affect how a client connects to the server.

You ask "how URI can be not available?" When using PSR-17, it MUST be present. However, if you are using a specific implementation, it's entirely possible to construct a fully empty request. This is why we indicate the default behavior when that happens.

--

Matthew Weier O'Phinney
mweiero...@gmail.com
https://mwop.net/

he/him

[Anton Fedonjuk]

 When retrieving the request-target with getRequestTarget(), by default this method will use the URI object and extract all the necessary components to construct the origin-form.

Please don't copy-paste PSR-7 - it's not answer. In given situation we sent wrong request because absolute-form in $requst->getRequestTarget() != (string) $requst->getUri().

RequestInterface::getUri() return UriInterface instance or you talk about strval(new Uri('')) MUST return '/'?

воскресенье, 19 января 2020 г., 0:51:54 UTC+3 пользователь Matthew Weier O'Phinney написал:

[Matthew Weier O'Phinney]

On Sat, Jan 18, 2020 at 4:30 PM Anton Fedonjuk <antonf...@gmail.com> wrote:

 When retrieving the request-target with getRequestTarget(), by default this method will use the URI object and extract all the necessary components to construct the origin-form.

Please don't copy-paste PSR-7 - it's not answer. In given situation we sent wrong request because absolute-form in $requst->getRequestTarget() != (string) $requst->getUri().

RequestInterface::getUri() return UriInterface instance or you talk about strval(new Uri('')) MUST return '/'?

I wasn't copy-pasting. I was describing the purpose behind the `withRequestTarget()` method, and how it differs from the composed URI.

The request-target is used _only for creating the string version of the HTTP message_. It CAN differ from the URI. The URI should be used by clients to determine where to connect.

It is up the user to ensure that the request-target does not specify a different scheme + authority when using the absolute-form or authority-form. We did not include checks for variances in these, because technically the HTTP spec (RFC 7230, https://tools.ietf.org/html/rfc7230) allows this (primarily for use with proxies).

As you note, `$request->getRequestTarget() !== (string) $uri`. This is correct. The DEFAULT for `getRequestTarget()` is to return an origin-form, which is the path and query string only. The origin-form does not allow for an empty string; a single slash ("/") is the minimum allowed; from section 5.3.1 of RFC 7230: "

   If the target URI's path component is
   empty, the client MUST send "/" as the path within the origin-form of
   request-target.

(Of note: origin-form is the most common, and the recommended form in RFC 7230.)

If you want the absolute-form, you must set it explicitly: $request = $request->withRequestTarget((string) $request->getUri())

 

воскресенье, 19 января 2020 г., 0:51:54 UTC+3 пользователь Matthew Weier O'Phinney написал:

I think you're not understanding the purpose of the request-target within a request.

Section 1.4 of the PSR-7 spec details the purpose, and how different values are interpreted. The point to understand, however, is that these serve a different purpose than the composed UriInterface. The UriInterface is used by a client in order to determine the protocol, port, and hostname so that the client can connect to the server in question. The request-target is the value used as the second segment of the request line when transmitting the request.

In PSR-7, if no request-target is provided, then the string form of the URI fills in as an absolute-form request-target.

Because the request-target can take a variety of forms that are not compliant with a UriInterface implementation (e.g., asterix-form, for OPTIONS requests; authority-form, for CONNECT requests; origin-form, which is typically only the pat; etc.), we allow setting it _separately_ from the URI. This means that setting it MUST NOT change the URI, as the point is that this is to customize the request line, and otherwise not affect how a client connects to the server.

You ask "how URI can be not available?" When using PSR-17, it MUST be present. However, if you are using a specific implementation, it's entirely possible to construct a fully empty request. This is why we indicate the default behavior when that happens.

--

Matthew Weier O'Phinney
mweiero...@gmail.com
https://mwop.net/

he/him

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/1e548e05-1232-45d2-b17c-9db03e6fa5a5%40googlegroups.com.