We have been going back and forth a lot on PSR-7 Compliance and some issues that are related to our current implementation of PSR-7.

I believe that we should decorate an existing implementation of PSR-7 instead of implementing our own. I would like all contributors to vote on this so we can move forward with some of the current issues.

This repo will essentially become a decorated implementation of an existing PSR-7 implementation.

There are 2 implementations that come to mind:

• Nyholm/psr7 - This is the fastest, strictest and most lightweight implementation at the moment
• Guzzle/psr7 - This is the implementation used by the Guzzle Client. It is not as strict but adds some nice functionality for Streams and file handling. It is the second fastest implementation but is a bit bulkier
• zend-diactoros - This is the Zend implementation. It is the slowest implementation of the 3.

I'm in favor of dropping our PSR-7 Implementation altogether and creating a PSR-7 Decorator repo which will work with any PSR-7 implementation (Nyholm, Guzzle, Diactoros).

Vote Count

• Nyholm/psr7 - 1 in favor
• Guzzle/psr7 - 2 in favor
• Zend Diactoros - 0 in favor
• Keep current implementation - 1 in favor
• Transform this into a PSR-7 Decorator Repo - 5 in favor

Edit The more we talk about this, the more this thread is heading towards not including any PSR-7 implementation with Slim/Slim and have the user pass in PSR-7 objects of their choice into App::run($req, $res). Slim-Http could be transformed into a Slim-Psr7-Decorator which will work with any PSR-7 implementation. Objects passed into App::run() will be decorated by default with our decorators, an option which could be turned off in App settings.

I just tried to implement the PSR-17 interfaces for Slim-Http addressing #1. I copied some of the existing static methods, such as Request::createFromGlobals(). Maybe we could even call them inside the factories - else not we should remove them. This is still not done as the classes needs some tests and there still is a todo in the ServerRequestFactory. I just wanted to leave this here to get a review before I waste additional hours, and to start a discussion wheter we should implement them here or in an additional package.

• [x] Write some tests
• [x] call static methods or remove them
• [x] fix the todo in ServerRequestFactory
• [x] ...

In https://github.com/slimphp/Slim-Http/blob/master/src/ServerRequest.php#L165

        $parsedBody = $this->serverRequest->getParsedBody();
        if ($parsedBody !== null) {
            return $parsedBody;
        }

The $parsedBody is checked against null. When a POST request is received with Content-Type: application/json the php server will set $_POST to an empty array.

In https://github.com/Nyholm/psr7-server/blob/master/src/ServerRequestCreator.php#L54 https://github.com/Nyholm/psr7-server/blob/master/src/ServerRequestCreator.php#L75

The serverRequest $parsedBody is initialized to the empty array and fails the check above so no parsed body data is returned from $request->getParsedBody();.

This PR addresses the issue https://github.com/slimphp/Slim-Http/issues/82.

Question: What is the best way for a user to change the file name of the download (Content-Disposition)?

1. Pass the file name as optional param.
2. Let the user overwrite the Content-Disposition header after calling this method.
3. Pass an optional config param (of class FileResponseConfig) to the method which would contain the file name. This allows other configs as well - for example the desired Content-Type, or whether the disposition is attachment or inline.

So far I think the following configs should be possible:

• Content type(s) If null, the method should try to guess the mime-type from the file name. Fallback is application/octet-stream.
• Content Disposition Either inline or attachment. Defaults to attachment.
• Auto ETag If true, the method would set an HTTP ETag header automatically.
• Auto Last Modified If true, the method would set the Last-Modified header based on the filemtime.
• File Name If not null, this should be used as file name in the Content-Disposition header. Defaults to the file name of the file given to the method.

Not sure about this config (found in Silex code mentioned in the original issue https://github.com/slimphp/Slim/issues/2536):

• Fallback File Name A fallback file name, containing only ASCII characters. Defaults to an automatically encoded file name.

Note
Currently there are no unit tests for this method.

• Ensure that our headers implementation is completely compliant with PSR-7
• Ensure that getHeader() and getHeaders() are consistent. See https://github.com/slimphp/Slim/issues/2400

Resuming to adopt the proposed direction in #88

New Response Methods:

• Response::withFile($file, $contentType)
• Response::withFileDownload($file, $name, $contentType)

Behavior The $file parameter can be a string which points to a file, an existing resource handle or a StreamInterface as proposed by @roxblnfk

The $name parameter overrides the default attachment value for the Content-Disposition header. The given $name is filtered through urlencode() to ensure it is a valid header value.

The $contentType parameter accepts a string to override the Content-Type header to a user defined value. Defaults to true which attempts to detect the mime type via mime_content_type() and falls back to application/octet-stream otherwise. If set to false the Content-Type header is not appended at all.

Closes #82

Should these be moved to a static registry inside the Request class? This would make it easier to inject custom parsers... e.g., \Slim\Http\Request::addParser('text/csv', function ($input) { ... });

Hello Slim maintainer team!

We're making use of the new Slim Framework 4.x alongside Slim-Http, and in particular we've needed to take advantage of a few of the changes that have been made in the last few months since the last tagged release back in May.

I was curious if there is a roadmap for the next tagged release, or if another one can be dropped in by the team, just so we're not sitting on dev-master, which always gives me a sketchy feeling deep inside.

If there's anything we outsider folks can do to help contribute toward that end, let me know as well. Happy to help. :)

Fixes #58

Updates the minimum version requirement to PHP >= 7.0.0.

Also fixes some of the broken unit tests in PHP 7.1 and higher. These were due to two problems:

1. The way the temp files were created to test uploaded files used tmpfile() which creates a resource, instead of a file name. fopen() no longer allows resources to be passed in. An alternative way to handle this would be to check for a resource and to use it directly, instead of calling fopen(), however we wouldn't be able to guarantee that the w flag was used. Opted to just fix how tests were written to use file names instead.
2. In URL creation empty checks were using falsy checks, which matched "0" as well. Updated to use exact !== '' checks instead.

Requesting the addition of a charset with the withJson response. This PR sets it to uff-8; maybe a parameter with a default value would be preferable.

Added php-http/psr7-integration-tests for testing our implementation. Fixed the only failing part right now - Host in Uri must be lowercase as of

The value returned MUST be normalized to lowercase, per RFC 3986

closes #31

Hi,

I have a middleware which parses the lang query parameter and set's the language in the container. Afterwards it removes the lang parameter from the query array and gives this new request to the next handler. This works aslong as you have at least another query parameter.

if you don't have a query parameter this psr-7 implementation automatically parses Uri directly.

    public function __invoke(Request $request, RequestHandler $handler): Response
    {
        $query = $request->getQueryParams();

        // do somthing with the $query['lang] entry

        // cleanup Parameters
        unset($query['lang']);
        $request = $request->withQueryParams($query);

        return $handler->handle($request);
    }

When I later validate the request for "unwanted" parameters with something like:

public function __invoke(Request $request, Response $response)
{
  $params = $request->getQueryParams();
  if (isset($params['lang'])) {
    // throw exception or what ever.
  }
}

The $params has the lang parameter set again because of this line https://github.com/slimphp/Slim-Http/blob/master/src/ServerRequest.php#L220

Not sure why slim/http does it this way but I think it's wrong, because then Request::withQueryParams([]) is pretty useless and doesn't work.

Not sure if there is a workaround...

thanks

Hello, Is it possible to disable automatic request parsing?

At least in version 3 it parses like this:

JSON requests are converted into associative arrays with json_decode($input, true). XML requests are converted into a SimpleXMLElement with simplexml_load_string($input). URL-encoded requests are converted into a PHP array with parse_str($input).

But I don't have installed the xml extension or have the functions disabled for security reasons. When an attacker sends a xml requests it wants to parse and I get an error like:

Call to undefined function Slim\Http\simplexml_load_string() on /var/www/website/vendor/slim/slim/Slim/Http/Request.php at 230

I would like to choose what parsing is done from these 3 options.

I've noticed that in the decorated ServerRequest, when calling getParsedBody, the original body is pulled via (string)$request->getBody(), but the StreamInterface is not rewind-ed after the fact.

In my tests, this means that any call to $request->getBody()->getContents() that takes place after that call happens have the internal stream pointer moved to the end of the input stream, and thus pulls basically always nothing.

I'm not sure if this is just a natural and intended byproduct of how PSR-7's StreamInterface works, or if this is something that could be worked around at this level.

Unfortunately I have not found a documentation nor any best-practices on how to use this library with slim 4. The README explains the instantiation process only.

In a test installation I used it in the route callable (an invokable class) the following way - is that correct?

// .... strict types and namespace

use Slim\Http\Response;
use Slim\Http\ServerRequest;

class HomeController
{
    public function __invoke(ServerRequest $request, Response $response, array $args = []): Response
    {
        return $response->withJson(['foo' => 'bar']);
    }
}

Am I loosing anything by directly typehinting Slim\Http\ServerRequest and Slim\Http\Response for the first two params?

The documentarion should mention that after installation (which works out-of-the-box), the first two arguments of the route callables would be decorated. I assume the same holds for the middleware $request param and for $response in the middleware code $response = $handler->handle($request);.