From https://github.com/guzzle/psr7/pull/158#issuecomment-376237838

I'm pretty confident that I will propose making all message classes in this project final if we ever hit a 2.0 version.

Reason: HTTP messages are represented as value objects, implementing an interface. From this point I don't see any valid use cases for extending the message classes.

FYI @sagikazarmark

Im not sure what to do here. Is this a good solution?

The logic is copied from StreamFactory. The alternative would be to create a new public method on Stream and move the code from StreamFactory.

I have an HTML form with an optional <input type="file"> field.

There is no problem with PHP 7.1-7.4, but with PHP 8.0 I get the following error.

Uncaught ValueError: Path cannot be empty in /Users/gr4376/Projects/webtrees/vendor/nyholm/psr7/src/Factory/Psr17Factory.php:40
Stack trace:
#0 .../vendor/nyholm/psr7/src/Factory/Psr17Factory.php(40): fopen('', 'r')
#1 .../vendor/nyholm/psr7-server/src/ServerRequestCreator.php(216): Nyholm\Psr7\Factory\Psr17Factory->createStreamFromFile('')
#2 .../vendor/nyholm/psr7-server/src/ServerRequestCreator.php(188): Nyholm\Psr7Server\ServerRequestCreator->createUploadedFileFromSpec(Array)
#3 .../vendor/nyholm/psr7-server/src/ServerRequestCreator.php(98): Nyholm\Psr7Server\ServerRequestCreator->normalizeFiles(Array)
#4 .../vendor/nyholm/psr7-server/src/ServerRequestCreator.php(71): Nyholm\Psr7Server\ServerRequestCreator->fromArrays(Array, Array, Array, Array, Array, Array, Resource id #7)
#5 .../index.php(55): Nyholm\Psr7Server\ServerRequestCreator->fromGlobals()

This is because fopen('') gives a warning in PHP <=7.4, but a fatal error in PHP 8.0.

See https://3v4l.org/cgYav

This patch replaces using strtolower() on hostnames as this cant handle utf-8 characters, I have opted to do this with a regex to prevent adding mbstring as a dependancy

https://github.com/Nyholm/psr7/blob/d38874cbc289d25a309cefd04379e24352ced608/src/Stream.php#L98-L109

I found this because of https://github.com/php-http/client-common/issues/186 In my application, I had a 200 with an empty body :exploding_head:

IMHO, doing this is wrong as it hides the root cause.

More over, in PHP 7.4 it's allowed to throw exception. And for PHP 7.3-, it prefer a fatal error than something wrong.

WDYT?

If I request a file from AWS I get an empty header:

x-amz-id-2: mhBUIOWKJ*()Z=*U?IPZJ))(J=OetWk=
x-amz-meta-orientation:
x-amz-request-id: 1ZUWIODKLD

which leads to an exception:

throw new \InvalidArgumentException('Header values must be non-empty strings');

in the MessageTrait. So I have no chance to use this library with servers who may return an empty header in their response.

Why is this psr7 implementation so strict with this? Can we change the behavior? Like for example just ignore empty headers and not throw an exception?

In PHP8, https://github.com/Nyholm/psr7/blob/master/src/Stream.php#L128 causes an issue with mockery:

Fatal error: Declaration of Mockery_0_Nyholm_Psr7_Stream_Nyholm_Psr7_Stream_Psr_Http_Message_StreamInterface::close() must be compatible with Nyholm\Psr7\Stream::close(): void

Hi,

Shouldn't we cast the header value as string in the trimHeaderValues() function ?

A few http headers represent a number of seconds or bytes, and the user could easily does something like this : new Response(200, ['Age' => 60]);

instead of using a string for the value. In this case the trimHeaderValues() will crash trying to da a trim on a non string.

It seems more logical to cast the value as string before trying to do the trim, no ? or perhaps doesn't apply the trim if the value is not a string ? or just let it crash ?

what is you opinion ?

WORK IN PROGRESS, DO NOT MERGE.

First and foremost: this changes the public API for ServerRequest, BC breaks need to be documented. (Or not, seeing how we are at a version below 1.0.0.)

This implements the changes from https://github.com/Nyholm/psr7/issues/3#issuecomment-292812159 but should be discussed further before merge.

1. getUriFromGlobals has been renamed createUriFromArray and has been moved from ServerRequest to UriFactory.

   The signature has been changed to accept a single $_SERVER-structure as argument, instead of the method depending directly on the global $_SERVER variable.

2. fromGlobals has been renamed createServerRequestFromGlobals and has been moved from ServerRequest to ServerRequestFactory.

   The signature has been changed to accept 5 separate array structures matching the different global variables.

3. normalizeFiles, createUploadedFileFromSpec, and normalizeNestedFileSpec have been moved from ServerRequest to ServerRequestFactory. This is probably not the perfect place for them either, but gets them out of ServerRequest.

4. Return type hinting has been added to the factories.

createUriFromArray sets no default scheme value, but http-interop/http-factory-tests expects ServerRequests to default to http through the factory. I made createServerRequestFromGlobals follow the factory expectation and added the default scheme there as well. This is a change from the old fromGlobals. But I am not sure if it is a good idea or not. Is there a use-case for creating a ServerRequest without a scheme?

The factory interface’s createServerRequestFromArray and our createServerRequestFromGlobals differ also on their requirement for a method. PSR-17 has us throw an InvalidArgumentException when the method can’t be found in the array, while createServerRequestFromGlobals defaults to GET. Should we follow the factory expectation here as well?

If we are following the factory expectation on both counts, it might be best to have createServerRequestFromGlobals go through createServerRequestFromArray first. Then adding the other globals to the created ServerRequest.

What would people expect to happen?

Finally: why is normalizeFiles public? Do we mean to support its API during future updates? If not, it should really be marked private.

Just added return types to ServerRequest class where they were not specified. The goal is to fixes deprecation messages on PHP8.1 as the ones below:

 1x: Method "Psr\Http\Message\ServerRequestInterface::withUploadedFiles()" might add "static" as a native return type declaration in the future. Do the same in implementation "Nyholm\Psr7\ServerRequest" now to avoid errors or add an explicit @return annotation to suppress this message.
    1x in OAuth2GenerateTokenActionTest::testItCallsSuccessfullyOauth2GenerateTokenEndpointTest from App\Tests\Functional\Action

  1x: Method "Psr\Http\Message\ServerRequestInterface::withCookieParams()" might add "static" as a native return type declaration in the future. Do the same in implementation "Nyholm\Psr7\ServerRequest" now to avoid errors or add an explicit @return annotation to suppress this message.
    1x in OAuth2GenerateTokenActionTest::testItCallsSuccessfullyOauth2GenerateTokenEndpointTest from App\Tests\Functional\Action

  1x: Method "Psr\Http\Message\ServerRequestInterface::withQueryParams()" might add "static" as a native return type declaration in the future. Do the same in implementation "Nyholm\Psr7\ServerRequest" now to avoid errors or add an explicit @return annotation to suppress this message.
    1x in OAuth2GenerateTokenActionTest::testItCallsSuccessfullyOauth2GenerateTokenEndpointTest from App\Tests\Functional\Action

  1x: Method "Psr\Http\Message\ServerRequestInterface::getParsedBody()" might add "array|object|null" as a native return type declaration in the future. Do the same in implementation "Nyholm\Psr7\ServerRequest" now to avoid errors or add an explicit @return annotation to suppress this message.
    1x in OAuth2GenerateTokenActionTest::testItCallsSuccessfullyOauth2GenerateTokenEndpointTest from App\Tests\Functional\Action

  1x: Method "Psr\Http\Message\ServerRequestInterface::withParsedBody()" might add "static" as a native return type declaration in the future. Do the same in implementation "Nyholm\Psr7\ServerRequest" now to avoid errors or add an explicit @return annotation to suppress this message.
    1x in OAuth2GenerateTokenActionTest::testItCallsSuccessfullyOauth2GenerateTokenEndpointTest from App\Tests\Functional\Action

Please let me know if adjustments are needed

This will fix #195

This will revert #177 so we don't introduce new behaviour. This will fix #180.

FYI @Zegnat @dbu. The discussion in #180 stalled a bit. By reverting this we are predictable (but maybe wrong), we are also consistent between creating a stream from string compared to from resource.

I have a login, which contains @ in username and password. User info with this character is currently not encoded. I think there should be a filterUserInfo() method to correctly encode input as other with* methods do.

I checked other popular implementations and all of them do that:

• https://github.com/guzzle/psr7/blob/67c26b443f348a51926030c83481b85718457d3d/src/Uri.php#L436-L439
• https://github.com/slimphp/Slim-Psr7/blob/7e7e63e3b624ed07bde14fbd9f91ab8904402375/src/Uri.php#L174-L177
• https://github.com/laminas/laminas-diactoros/blob/6028af6c3b5ced4d063a680d2483cce67578b902/src/Uri.php#L275-L278

Most accurate seem to be guzzle and laminas implementations which do this:

    private function filterUserInfo($userInfo): string
    {
        if (!is_string($userInfo)) {
            throw new \InvalidArgumentException('User info must be a string');
        }

        return preg_replace_callback(
            '/(?:[^%' . self::CHAR_UNRESERVED . self::CHAR_SUB_DELIMS . ']+|%(?![A-Fa-f0-9]{2}))/',
            [$this, 'rawurlencodeMatchZero'],
            $userInfo
        );
    }

Only difference is in laminas/laminas-diactoros which also checks for invalid UTF-8 characters

Closes #204 As a fix, when we have created the stream, we can set the seek again to start of the file so that when we invoke $req->getBody()->getContents(); we get the actual body and not empty string.

Using the psr17factory for creating a request object using this syntax, when we try to get the contents of the body, we get empty string.

$factory = new Psr17Factory();
$req = $factory->createRequest('POST', 'https://nyholm.tech');
$body = $factory->createStream('Foo');
$req = $req->withBody($body);
var_dump($req->getBody()->getContents()); // prints empty string.

The problem is in the createStream method, while creating the stream the file seek goes to the end of the temp file created and when we try to get the contents it starts reading from end, hence the empty string.

I'm working on a situation where I'd like to have control over the signature of the constructor of PSR-7 implementations. I managed to use inheritance for all implementations but nyholm/psr7 That's why I'm proposing this change. It improves extensibility without hurting maintainability IMHO.

When you specify a username and password using Uri::withUserInfo() these are not encoded for URL (see here). For instance, if the username is foo@ and the password is bar the userInfo results in foo@:bar that is not a valid URL encoded string.

Other PSR-7 implementations use rawurlencode() for encoding the characters in the URL (e.g. Guzzle, Laminas-diactoros).