This changeset makes sure we use the same DI container instance to also load global middleware classes. This allows us to take advantage of autowiring for global middleware classes the same way it can be done for route request handlers as implemented in #92. This does not otherwise break existing APIs, so this is a pure feature addition.

Builds on top of #92 and #89

Let's say, this is your code:

$app->get('/foo', function () {
    return new \React\Http\Message\Response(202, [
        'Location' => '/bar',
    ]);
});

• When you use ReactPHP as webserver, the status code will be 202 (as expected).
• When you use PHP's built-in webserver, the status code will be 302 (unexpected).

So, why does this happen?

When you use header(...) to set the Location header, PHP will update the status code to 302. This behavior is even mentioned in the official documentation: PHP: header - Manual

The second special case is the "Location:" header. Not only does it send this header back to the browser, but it also returns a REDIRECT (302) status code to the browser unless the 201 or a 3xx status code has already been set.

Here is the corresponding code in php/php-src: https://github.com/php/php-src/blob/php-8.1.11/main/SAPI.c#L806-L821

Should this happen?

I think, this behavior is more confusing than it is helpful. It should not be the decision of PHP to override my status code. According to RFC 9110, the Location header has a defined behavior for the status codes 201 and 3xx.

But that is not an exclusive definition. Any HTTP response may contain a Location header, but the expected behavior is not defined by this RFC. That means, it can be used by a proprietary API definition for other status codes.

What does this change do?

The status code is now set after setting all other headers. This will override any status code that has priorly been set by PHP. So now my choice of status code is respected.

If the running container is not mapped to any port, then not all requests would be able to pass through, unless the server is setup to expose the mentioned port (8080, in this case).

• Display UTF-8 characters correctly in the browser, also shows how to add headers to responses
• Add command to create empty composer.json before running require (stops potential prompts about the file being missing)

This is just a request for comments PR.

This implementation is a discussion starter for DI in fx, it replaces the $loop constructor variable with the ContainerInterface. I know this is a breaking change but keeping several legacy layers before a public release doesn't makes much sense and increases the maintenance effort.

I implemented also 2-3 example usages for the container.

1. loop
2. logger
3. socketServerContext

The loop entry is just a simple replacement for the existing $loop parameter.

The logger entry is a LoggerInterface defined by PSR-3 standard. It's used in the log function. Additional to this the request Logger supports now a logger attribute from the request. This can be used for context logging.

The socketServerContext is an array for the socketServer with on addition, it can hold a key named uri which is used for the socketServer uri parameter. This allows us to define a custom IP and port. Also we can use TLS and set custom parameters for the socketServer.

It adds 2 dependencies

1. php-di PSR-11
2. psr/log PSR-3

php-di brings a complete dependency injection package but required for other packages is only the ContainerInterface psr/log brings only the PSR-3 LoggerInterface

Both dependencies are optional for applications based on fx.

Missing

• [X] Tested in a 3rd party application
• [ ] Documentation
• [ ] Tests
• [ ] Think about it

Just as remark this is just a discussion PR and should be a proof of concept.

Caddy has a bunch of ease of use and convenience benefits over both Nginx and Apache, and supports both the php-fpm and proxy workflows well. It can proxy websocket traffic without any additional config as well (on the same port as regular HTTP traffic).

What's awkward is the docs for Nginx and Caddy both end up extremely similar, because they have a lot of similarities from a usage standpoint for PHP apps. Not sure if you'd want to reconcile/merge their docs somehow to deal with that.

The following tests are failing if you run phpunit on windows

1. FrameworkX\Tests\AppTest::testLogRequestResponsePrintsRequestLogWithCurrentDateAndTime Failed asserting that '2021-07-02 11:29:09.446 127.0.0.1 "GET /users HTTP/1.1" 200 6\r\n ' matches PCRE pattern "/^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}.\d{3} 127.0.0.1 "GET /users HTTP/1.1" 200 6 $/".

2. FrameworkX\Tests\AppTest::testLogRequestResponseWithoutRemoteAddressPrintsRequestLogWithDashAsPlaceholder Failed asserting that '2021-07-02 11:29:09.447 - "GET /users HTTP/1.1" 200 6\r\n ' matches PCRE pattern "/^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}.\d{3} - "GET /users HTTP/1.1" 200 6 $/".

3. FrameworkX\Tests\AppTest::testLogPrintsMessageWithCurrentDateAndTime Failed asserting that '2021-07-02 11:29:09.448 Hello\r\n ' matches PCRE pattern "/^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}.\d{3} Hello $/".

The reason for this is that PHP_EOL uses "\r\n" on windows and not "\n" as expected by the test.

I'm not sure if logging output should have system specific line endings. As alternativ PHP_EOL can be replaced by "\n" in App:log()

If you're currently using this project and there are any issues or if there's anything you'd like to discuss, head over to the public https://github.com/clue/framework-x repository :tada:

• Issues: https://github.com/clue/framework-x/issues
• Discussions: https://github.com/clue/framework-x/discussions

This way, more people (including those without early access) get a chance to follow the project development and take part in discussions.

Head over to https://github.com/clue/framework-x and rock on 🤘

Over time we recognized failing tests because of an incorrect time measurement in our tests which mostly occurred when running our test suite under windows. Last seen here: https://github.com/clue/framework-x/actions/runs/3741602828/jobs/6351445435

I raised the sleep-time inside the responsible test to avoid any future tests failing because of inaccurate clocks.

Builds on top of https://github.com/reactphp/http/pull/460 and https://github.com/reactphp/promise/pull/138 (and countless upstream tickets referenced in https://github.com/reactphp/http/pull/460)

Discussed in https://github.com/clue/framework-x/discussions/164

$app->setBasePath('/test');

acme/
├── public/
│   ├── .htaccess
│   └── index.php
├── vendor/
├── composer.json
└── composer.lock

RewriteEngine on
RewriteRule ^$ public/ [L]
RewriteRule (.*) public/$1 [L]

RewriteEngine On

RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule .* index.php

# This adds support for authorization header
SetEnvIf Authorization .+ HTTP_AUTHORIZATION=$0

Hey there 👋,

first and foremost: thanks for Framework X! I'm currently developing a website from scratch and it's like a fresh breeze compared to the "heavy" frameworks I'm used to, and I'm having fun using and exploring it - a feeling I haven't had for a long time.

While following the docs to let Caddy (also a new experience for me) serve the static assets on my local machine, the home page (/) didn't work for me until I excluded / in addition to *.php in the @static directive.

I'm proposing the change in a PR instead of starting a discussion because I'm hopeful this change was the correct choice (and although it's just one added char) 😅.

If the change tackles the problem from the wrong end, I'd be grateful for a hint in the right direction!

:octocat:

Currently, if using nginx as a reverse proxy with the described configuration, PHP files in the public folder are served as-it (unparsed) to the client, because the try_files instruction in the nginx configuration finds the file (e.g. index.php). To avoid this behavior we must instruct nginx to pass any file ending with .php as a route to X. That does not mean that X will parse this file, and as long as not appropriate route is defined (e.g. $app->get('/index.php', ...) X will just respond with a 404 error page, but at least no PHP code is leaked.

in respect to the underlying http-server component which will not allow to define the own middleware streaming handler. this code will give the opportunity to handle the 64KB request body problem. just assign your own 'StreamingRequestMiddleware' with custom allowed body size.

I have tried to build a setup with two services: one framework-x service and a nginx as reverse proxy. If I am using the nginx configuration that you are suggesting (https://framework-x.org/docs/best-practices/deployment/#nginx-reverse-proxy), all php files in the public folder are served "as-it" (unparsed) to the client (at least if nginx and framework-x are sharing the same public folder - but that is how I read your examples). Seems to me that using a different path for the the framework-x start script than /public/index.php is highly recommended. Or am I missing something?

I have created an example in a branch of my test project: https://github.com/virtuelle-maschine/framework-x-test/tree/example-with-index An example that works as expected can be found in the main branch of that project.

BTW, regarding Dockerfile: I am surprised you are using the ENTRYPOINT instruction to start the app - doesn't the CMD instruction makes more sense as you can run the container with a different command (e.g. composer) much easier?

Imagine you wanted to have a service with a constructor parameter of a string like this:

class UserController
{
    public function __construct(string $hostname)
    {
        // ...
    }
}

Prior to this change, you would have to do this.

$container = new FrameworkX\Container([
    UserController::class => function (string $hostname): UserController {
        return new UserController($hostname);
    },
    'hostname' => 'Some string value',
]);

After this change, you can do this:

$container = new FrameworkX\Container([
    'hostname' => 'Some string value',
]);

I am still relatively new to this framework, so I don't know whether this will break some anything.