When mezzio-swoole will be integrated with package ext-openswoole rather than ext-swoole?

Switch from Travis-CI to GHA CI workflow, as documented at https://gist.github.com/weierophinney/b003e50c3c2667d08076caf31ebd36a4

Feature Request

Summary

At the momen mezzio/swoole supports some swoole events - however not all.
Specifically workerstop is supported, but not workerexit for example.

Per docs - workerstop is not triggering for task processes: https://github.com/deminy/swoole-by-examples/blob/master/examples/servers/server-events.php.

Event "onWorkerStop" happens in worker processes only. It won't happen in task worker processes.
Event "onWorkerExit" happens only when option \Swoole\Constant::OPTION_RELOAD_ASYNC is turned on.

this could be problematic if one needs to do some work on task worker exit - like shutdown connection pool for example.

Could probably be easily addressed in Mezzio\Swoole\SwooleRequestHandlerRunner:

    public function run(): void
    {
        if ($this->httpServer->mode === SWOOLE_PROCESS) {
            $this->httpServer->on('start', [$this, 'onStart']);
            $this->httpServer->on('shutdown', [$this, 'onShutdown']);
        }

        $this->httpServer->on('managerstart', [$this, 'onManagerStart']);
        $this->httpServer->on('managerstop', [$this, 'onManagerStop']);
        $this->httpServer->on('workerstart', [$this, 'onWorkerStart']);
        $this->httpServer->on('workerstop', [$this, 'onWorkerStop']);

       //lets add this!
        $this->httpServer->on('workerexit', [$this, 'onWorkerExit']);

        $this->httpServer->on('workererror', [$this, 'onWorkerError']);
        $this->httpServer->on('request', [$this, 'onRequest']);
        $this->httpServer->on('beforereload', [$this, 'onBeforeReload']);
        $this->httpServer->on('afterreload', [$this, 'onAfterReload']);
        $this->httpServer->on('task', [$this, 'onTask']);
        $this->httpServer->on('finish', [$this, 'onTaskFinish']);

        $this->httpServer->start();
    }

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Repository problems

These problems occurred while renovating this repository. View logs.

• WARN: Use matchDepNames instead of matchPackageNames

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update dependency psalm/plugin-phpunit to ^0.19.0
• Update dependency laminas/laminas-servicemanager to v4
• Update dependency phpunit/phpunit to v11
• Update dependency symfony/console to v7
• Lock file maintenance
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Not really a bug, but I noticed that the ConfigProvider has the key static-files which inside of it has the key enable - but that one is not used anywhere.

I checked the history of this package and noticed that at some point there was such a parameter, but it was removed as part of the "feat: event-driven handler runner" commit, check the references:

• 9d05452#diff-ed3c456b054020246a5f40d326c3f57f6ac996ff6784937638ac9014982d0384L54-L58
• 9d05452#diff-ed3c456b054020246a5f40d326c3f57f6ac996ff6784937638ac9014982d0384L66-L70

As a matter of fact, I think the lines from the documentation for disabling static resources are not relevant at all:

• https://github.com/mezzio/mezzio-swoole/blame/8058289fd519e35c233502a72361b0dbab02ba39/docs/book/v3/static-resources.md#L25-L73

But the cookbook seems to be up to date with the correct information, though:

• https://github.com/mezzio/mezzio-swoole/blob/8058289fd519e35c233502a72361b0dbab02ba39/docs/book/v3/cookbook/static-resource-listener-removal.md

Bug Report

Summary

Upgrading to 4.7.0 with psr/http-message:^2.0 gives compatibility errors in Mezzio\Swoole\SwooleStream.

Fatal error: Declaration of Mezzio\Swoole\SwooleStream::close() must be compatible with Psr\Http\Message\StreamInterface::close(): void in /app/vendor/mezzio/mezzio-swoole/src/SwooleStream.php on line 242

Current behavior

How to reproduce

Expected behavior

Feature Request

Summary

For version 3.0, since it targets PHP 7.4+, we should update all properties to use typehints.

Feature Request

Summary

laminas/laminas-httphandlerrunner v2 was released earlier this year. The base mezzio/mezzio package can already utiliize it, and it is the version installed by default with a new Mezzio installation. This package should provide compatibility with it.

However, the new version makes a few changes that may make this difficult:

• It adds a RequestHandlerRunnerInterface.
• It marks the base RequestHandlerRunner implementation as final.

The problems are thus:

• In v1, there was no interface, so applications would pull the Laminas\HttpHandlerRunner\RequestHandlerRunner service from the container and use that. This package essentially overwrote that definition in order to provide an implementation.
• Also, because in v1 there was no interface, inheritance was the only way to provide a compatible implementation. Since v2 marks the default implementation as final, we cannot inherit in a version that supports v2.

I propose a minor + major release strategy:

• In the minor release, we provide multiple implementations:
  • A trait will define the full internals of each.
  • One implementation will target laminas-httphandlerrunner v1, extending the v1 version and using the trait; it will have the trait methods take precedence over inherited methods.
  • Another implementation will target laminas-httphandlerrunner v2, implementing the v2 interface and using the trait.
  • An autoloader will determine which one to use, and alias Mezzio\Swoole\SwooleRequestHandlerRunner to the implementation.
  • The ConfigProvider aliases the interface to the implementation.
• In the major release, one implementation:
  • The v2 implementation becomes the only implementation.

One other idea I've considered: vary what the ConfigProvider maps based on the laminas-httphandlerrunner version. Since we know the RequestHandlerRunnerInterface only exists in v2, we could simply define an additional v2-compatible implementation, and have the ConfigProvider map to its factory when detected, instead of the existing implementation. The main downside to this is if anybody was previously extending our implementation (which shouldn't be necessary anymore, due to the changes made to have it trigger events). We would still likely need a trait with the common functionality (required due to inheritance in v1), but it wouldn't require usage of class_alias().

Bug Report

Summary

vendor/mezzio/mezzio-swoole/src/ConfigProvider.php has delegator defined as

Mezzio\WhoopsPageHandler' => [
                    WhoopsPrettyPageHandlerDelegator::class,
],

Current behavior

This leads to
Notice: Undefined index: Mezzio\WhoopsPageHandler in vendor/elie29/zend-phpdi-config/src/Config.php on line 137

How to reproduce

Expected behaviour

Whoops should not be tied to the application

Hi,
emitCookies() in SwooleEmitter.php is missing the SameSite attribute, $cookie->getSameSite(). Chrome 80 which will be released on the 4th of february won't send cookies to a thirdparty without SameSite=None anymore. Also $cookie->getSameSite() returns a string like "SameSite= $value" which is also a problem. It should only return the value.

Feature Request

Summary

With swoole certain operations could only happen before the server start. (one example is - one can only add swoole processes to swoole server before server starts.)
For this reason I think it would be worthwhile to add BeforeServerStartEvent.

Could probably be easily addressed in Mezzio\Swoole\SwooleRequestHandlerRunner:

    public function run(): void
    {
        if ($this->httpServer->mode === SWOOLE_PROCESS) {
            $this->httpServer->on('start', [$this, 'onStart']);
            $this->httpServer->on('shutdown', [$this, 'onShutdown']);
        }

        $this->httpServer->on('managerstart', [$this, 'onManagerStart']);
        $this->httpServer->on('managerstop', [$this, 'onManagerStop']);
        $this->httpServer->on('workerstart', [$this, 'onWorkerStart']);
        $this->httpServer->on('workerstop', [$this, 'onWorkerStop']);
        $this->httpServer->on('workererror', [$this, 'onWorkerError']);
        $this->httpServer->on('request', [$this, 'onRequest']);
        $this->httpServer->on('beforereload', [$this, 'onBeforeReload']);
        $this->httpServer->on('afterreload', [$this, 'onAfterReload']);
        $this->httpServer->on('task', [$this, 'onTask']);
        $this->httpServer->on('finish', [$this, 'onTaskFinish']);

       //lets add this!
        $this->dispatcher->dispatch(new Event\BeforeServerStartEvent($server));

        $this->httpServer->start();
    }

Feature Request

Summary

Please add 'swoole/ide-helper' component to Composer's 'dev' dependencies in order to help IDEs resolving Swoole engine entities (classes, functions, constants, etc...).

Bug Report

Summary

Executing Reload command from CLI throw errors.

Current behavior

Reloading server ...
PHP Notice:  Undefined index: stop in /usr/src/project/vendor/laminas/laminas-cli/src/AbstractContainerCommandLoader.php on line 64
Notice: Undefined index: stop in /usr/src/project/vendor/laminas/laminas-cli/src/AbstractContainerCommandLoader.php on line 64

Command "stop" is not defined.

Did you mean this?
      mezzio:swoole:stop

How to reproduce

./vendor/bin/laminas mezzio:swoole:start -d
./vendor/bin/laminas mezzio:swoole:reload

Expected behavior

Callling Reload command from CLI should reload Swoole server.

Fix

I think Symfony Console (method find() of Application class) can not find command when using short name (stop vs. mezzio:swoole:stop)?

This line from ReloadCommand
https://github.com/mezzio/mezzio-swoole/blob/3.1.0/src/Command/ReloadCommand.php#L78
should be replaced with:

$stop   = $application->find('mezzio:swoole:stop');

and this line:
https://github.com/mezzio/mezzio-swoole/blob/3.1.0/src/Command/ReloadCommand.php#L95
should be replaced with:

$stop   = $application->find('mezzio:swoole:start');

Feature Request

Summary

A new major version of dflydev/fig-cookies has been released, which adds support for PHP 8 (among other things).

Would you be open to update on this project? If so I can take care of it, I just need to know if you want to support both v2 and v3 at the same time.

Feature Request

Summary

I have tried a project where I use this library with openswoole, and using openswoole 22.0.0, there seems to be calls to now removed functions (So far I have identified Fatal error: Uncaught Error: Call to undefined function swoole_set_process_name() in mezzio/mezzio-swoole/src/Event/ProcessNameTrait.php:33).

I believe this is the first version that trully deviates from swoole and might require considering how hard would be to continue supporting both.

The changelog does not mention the removal of this particular function, so I wonder how many other undocumented changes there are.

Feature Request

Summary

To support Composer 2 for all of the laminas packages, we have to replace ocramius/package-versions with composers fork composer/package-versions-deprecated.
The fork removed the PHP 7.4 limitation and thus provides Composer 2 support for PHP <7.4.

composer/package-versions-deprecated is replacing ocramius/package-versions and thus can be used as a 1:1 replacement.

Feature Request

Summary

As decided during the Technical-Steering-Committee Meeting on August 3rd, 2020, Laminas wants to implement vimeo/psalm in all packages.

Implementing psalm is quite easy.

Required

• Create a psalm.xml in the project root
• Copy and paste the contents from this psalm.xml.dist
• Run $ composer require --dev vimeo/psalm
• Run $ vendor/bin/psalm --set-baseline=psalm-baseline.xml
• Add a composer script static-analysis with the command psalm --shepherd --stats
• Add a new line to script: in .travis.yml: - if [[ $TEST_COVERAGE == 'true' ]]; then composer static-analysis ; fi
• Remove phpstan from the project (phpstan.neon.dist, .travis.yml entry, composer.json require-dev and scripts)

Optional

• Fix as many psalm errors as possible.

Feature Request

Summary

Currently, the component provides its own binary for launching/controlling the Swoole web server, based on symfony console. This functionality should be migrated to laminas-cli.

When updating mezzio-swoole package with composer (composer update) there is notice in console:

Skipped installation of bin bin/mezzio-swoole for package mezzio/mezzio-swoole: file not found in package

mezzio-swoole command was replaced by laminas command so "bin" section should be removed from composer.json:

"bin": [
        "bin/mezzio-swoole"
    ],

Yesterday, one of the main Swoole devs blew the whistle on a gaping security flaw that was planned for Swoole v4.8.0. After his concerns were initially unaddressed, he forked the project (Openswoole). In response, the core Swoole team immediately removed the flaw and then booted the whistleblower from the project.

Given that Swoole is controlled by a team of devs based in the PRC, who are demonstrably operating either with at least bad judgement and poor accountability, or at most nefarious intent, I'm asking that you consider taking one of the following actions:

• Add a warning label to the documentation for mezzio/mezzio-swoole, with a link to swoole/swoole-src#4434, or
• Abandon and archive mezzio/mezzo-swoole.

Read the discussion above for yourself, and decide whether you are comfortable trusting upstream Swoole, or the Openswoole fork in the foreseeable future.

I would be happy to see protected const in that class as by extending the class with private const I am forced to define it in my own and they are not different to the default one.

I am extending it to perform some code before the swoole server starts

Bug Report

Summary

When starting, within a Docker container, a Mezzio based project according to the 'mezzio-swoole' documentation the Swoole server cannot start.

Current behavior

With a 'mezzio-swoole' configuration like the following:

<?php

declare(strict_types=1);

use Laminas\ServiceManager\Factory\InvokableFactory;
use Mezzio\Swoole\HotCodeReload\FileWatcher\InotifyFileWatcher;
use Psr\Log\LoggerInterface;
use \App\Swoole\Log\LoggerFactory;

return [
    'dependencies' => [
        'factories' => [
            LoggerInterface::class => LoggerFactory::class,
            //InotifyFileWatcher::class => InvokableFactory::class
        ],
        'delegators' => [
            \Swoole\Http\Server::class => [
                \App\Swoole\Task\TaskControllerDelegator::class
            ],
        ],
    ],
    'mezzio-swoole' => [
        'enable_coroutine' => true,
        'hot-code-reload' => [
            'enable' => true,
            'interval' => 500,
        ],
        'swoole-http-server' => [
            'host' => '*',
            'port' => 9501,
            'process-name' => 'mezzio',
            'mode' => SWOOLE_PROCESS,
            'options' => [
                'worker_num'      => 8,
                'task_worker_num' => 4,
                'task_enable_coroutine' => true
            ]
        ]
    ]
];

a ServiceManager related error is generated on server start:

In ServiceManager.php line 688:
                                                                               
  Unable to resolve service "Mezzio\Swoole\HotCodeReload\FileWatcher\InotifyF  
  ileWatcher" to a factory; are you certain you provided it during configurat  
  ion?  

How to reproduce

Follow 'mezzio-swoole' installation instruction, enable 'hot-code-reload'.

Reason for the issue

The module's 'ConfigProvider' specifies an 'alias' for related to the failing class (specified in above error) but the actual factory for that class is not defined in the dependencies manager.

Using the 'Laminas Service Manager' the solution is as easy as adding 'InotifyFileWatcher::class => InvokableFactory::class' in the 'factories' configuration.

Expected behavior

The Swoole server starts correctly as configured.

Feature Request

Summary

Once #28 is merged, there is no longer any reason that the start command cannot expose an option for specifying the number of task workers to spawn, as there is now always a task listener present. I suggest --task-workers|-t as the option name.

• I was not able to find an open or closed issue matching what I'm seeing.
• This is not a question. (Questions should be asked on chat (Signup here) or our forums.)

Currently it's impossible to define an own date format in the logger.
The problem goes down to the usage of strftime which uses % for formating times as well as the other non common date formats.

Code to reproduce the issue

To log times in ISO 8601 format, according to the documentation this would look like the following.
But as % is used already to parse the log format the formatter just generates useless output.

 'zend-expressive-swoole' => [
        'swoole-http-server' => [
            'logger' => [
                'format' => '%{%FT%T%z}t',
            ],
    ]
]

Suggestion 1

My recommended suggestion would to to use the more common date format instead of strftime because, yea it's more common in PHP as it's the same as in DateTime and it does not use % to it's much more readable and much simpler to parse.

Suggestion 2

Another suggestion would be to "fix" the log formatter and combine replaceConstantDirectives and replaceVariableDirectives on parsing to make sure %{format}t gets used by the variable directives no matter how the format looks like.

Originally posted by @marc-mabe at zendframework/zend-expressive-swoole#62

Feature Request

Summary

To be prepared for the december release of PHP 8.0, this repository has some additional TODOs to be tested against the new major version.

In order to make this repository compatible, one has to follow these steps:

• Modify composer.json to provide support for PHP 8.0 by adding the constraint ~8.0.0
• Modify composer.json to drop support for PHP less than 7.3
• Modify composer.json to implement phpunit 9.3 which supports PHP 7.3+
• Modify .travis.yml to ignore platform requirements when installing composer dependencies (simply add --ignore-platform-reqs to COMPOSER_ARGS env variable)
• Modify .travis.yml to add PHP 8.0 to the matrix (NOTE: Do not allow failures as PHP 8.0 has a feature freeze since 2020-08-04!)
• Modify source code in case there are incompatibilities with PHP 8.0

Feature Request

Summary

Debugging swoole applications is much harder as 1. XDebug step debugging does not work out-of-the box and 2. because printing debug messages get send into nirvana.

Both are not related a mezzio swoole but to the nature how the swoole webserver works.

I think I found a good way to support xdebug step debugging requests by manually reproducing what xdebug does normally to start a debug session on http request and would like to get your thoughts about this.

PS: Currently this is a prov-of-concept for step debugging only but it should also be possible for profiling and other debugging sessions.

Requirements to make it work:

• xdebug installed and debug mode enabled
• coroutines turned off (Actually didn't test with coroutines turned on yet)
• Add XDebugSessionRequestListener as first RequestEvent listener ín development.config.php

class XDebugSessionRequestListener
{
    private bool $isAvailable = false;

    private string $startWithRequest = 'trigger';

    private string $triggerValue = '';

    public function __construct()
    {
        if (!\extension_loaded('xdebug')) {
            return;
        }

        $mode = (string)(\getenv('XDEBUG_MODE') ?: \ini_get('xdebug.mode') ?? '');
        if (!\in_array('debug', \explode(',', $mode), true)) {
            return;
        }

        // env XDEBUG_CONFIG
        $envConfig        = [];
        $envConfigEntries = \explode(' ', (string)\getenv('XDEBUG_CONFIG'));
        foreach ($envConfigEntries as $envConfigEntry) {
            $envConfigSplit                = \explode('=', $envConfigEntry);
            $envConfig[$envConfigSplit[0]] = $envConfigSplit[1] ?? null;
        }

        $startWithRequest = $envConfig['start_with_request'] ?? (string)\ini_get('xdebug.start_with_request');
        if ($startWithRequest === 'no') {
            return;
        }

        // Normalize "xdebug.start_with_request" setting
        // as the value "default" depends on "xdebug.mode":
        //    debug: trigger
        //    gcstats: no
        //    profile: yes
        //    trace: trigger
        // -> We already expect "xdebug.mode" to include "debug"
        if ($startWithRequest === 'default') {
            $startWithRequest = 'trigger';
        }

        $this->startWithRequest = $startWithRequest;
        $this->triggerValue     = $envConfig['trigger_value'] ?? (string)\ini_get('xdebug.trigger_value');
        $this->isAvailable      = true;
    }

    public function __invoke(RequestEvent $event): void
    {
        if (!$this->isAvailable) {
            return;
        }

        // XDebug is configured to auto start on each request
        if ($this->startWithRequest === 'yes') {
            $this->start();
            return;
        }

        if ($this->startWithRequest !== 'trigger') {
            return;
        }

        $request = $event->getRequest();

        $requestValue = $request->cookie['XDEBUG_TRIGGER']
            ?? $request->get['XDEBUG_TRIGGER']
            ?? $request->post['XDEBUG_TRIGGER']
            ?? null;

        // legacy triggers
        $requestValue ??= $request->cookie['XDEBUG_SESSION']
            ?? $request->get['XDEBUG_SESSION']
            ?? $request->post['XDEBUG_SESSION']
            ?? null;

        if ($requestValue === $this->triggerValue || ($requestValue !== null && !$this->triggerValue)) {
            $this->start();
        }
    }

    private function start(): void
    {
        if (\function_exists('xdebug_connect_to_client')) {
            // XDebug >= 3.1
            \xdebug_connect_to_client();
        } else {
            // XDebug < 3.1 we have to set a breakpoint
            \xdebug_break();
        }
    }
}

Bug Report

SwooleStream is cutting down response when there is one character left in the stream.

Branch: master

Summary

// add this test case to the SwooleStreamTest

public function testCrossCase(): void
{
    $len = strlen(self::DEFAULT_CONTENT);

    $this->assertSame('This is a test', $this->stream->read($len - 1));
    $this->assertFalse($this->stream->eof()); // it fails here
}

Current behavior

Test fails

How to reproduce

Just run provided test case

Expected behavior

$this->stream->eof() shoud return false, because there is one character left in the stream

Feature Request

Summary

I'm creating this as I don't see a ticket to add support for php 8.2

I'm willing to contribute the change if needed.

• I was not able to find an open or closed issue matching what I'm seeing.
• This is not a question. (Questions should be asked on chat (Signup here) or our forums.)

Use swoole tick timer on the worker process to be able to use it as the event loop for guzzle.

PS: By default guzzle uses PHP shutdown handler but this does not work in a swoole environment. To be able to use async Guzzle callbacks within an swoole worker you have to run the task queue of Guzzle manually. This can simply be done using the SwooleServer::tick function of the worker process.

Code to reproduce the issue

// This does not work as "SwooleServer::on()" supports only one listener
// and there is already a listener in SwooleRequestHandlerRunner
$masterServer = $container->get(SwooleHttpServer::class);
$masterServer->on('workerstart', function (SwooleHttpServer $workerServer) {
    $queue = \GuzzleHttp\Promise\queue();
    $workerServer->tick(100, function () use ($queue) {
        $queue->run();
    });
});

// I had to extend SwooleRequestHandlerRunner
// and copy-past SwooleRequestHandlerRunnerFactory
// to use an own event manager to add application specific listeners to these events
$em = $container->get(EventManagerInterface::class);
$em->attach(WorkerStartEvent::class, function (WorkerStartEvent $event) {
    $queue = \GuzzleHttp\Promise\queue();
    $workerServer = $event->getServer();
    $workerServer->tick(1000, function () use ($queue) {
        $queue->run();
    });
});

Expected results

There should already be a way in zend-expressive-swoole to add application specific listeners to such events

Actual results

It's not possible without extending SwooleRequestHandlerRunner and copy-pasting SwooleRequestHandlerRunnerFactory.

Originally posted by @marc-mabe at zendframework/zend-expressive-swoole#69

Bug Report

Summary

If there's a cookie in the response and the Cookie is missing the 'SameSite' directive then a fatal error will be thrown.

PHP Fatal error: Uncaught TypeError: Swoole\Http\Response::cookie() expects parameter 8 to be string, null given in /var/www/mezzio-test/vendor/mezzio/mezzio-swoole/src/SwooleEmitter.php:106

Current behavior

If there's a response with a cookie and no SameSite directive then the swoole process will just die

How to reproduce

I installed a clean and fresh instance of mezzio, configured the project to use swoole with these instructions, modified the HomePageHandler.php like this:

$response = new HtmlResponse($this->template->render('app::home-page', $data));
$cookie = 'CookieName=CookieValue; Expires=Wed, 01-Jul-2020 13:43:42 GMT; Path=/; Secure; HttpOnly;';
$response = $response->withHeader('Set-Cookie', $cookie);

return $response;

and started it using php7.3
/usr/bin/php7.3 /mezzio-test/public/index.php

i've fixed it by setting sameSite to an empty string instead of null:
$sameSite = $cookie->getSameSite() ? substr($cookie->getSameSite()->asString(), 9) : '';

As for the SwooleEmitter.php tests: i don't know why phpunit doesn't have the same error. any hints for learning purposes would be nice.

Expected behavior

I'd expected to get a normal response with a Cookie

Bug Report

Summary

I want to stream a response with unknown size.

Current behavior

SwooleEmitter calls SteamInterface::getContents() when StreamInterface::getSize() returns null

How to reproduce

Adding a failing test and fix in #69

Expected behavior

SwooleEmitter calls StreamInterface::read() when StreamInterface::getSize() returns null

Bug Report

syntax highlighter doesnt work on website.

Summary

Code highlighting on website is illegible, its dark gray on slightly less darker gray - hard to read.

Current behavior

Hard to read code examples

How to reproduce

Visit this page https://docs.mezzio.dev/mezzio-swoole/v4/logging/ see this code block:

Expected behavior

we should be seeing nice and fancy syntax highlights in multiple colors that are other then gray

Bug Report

Summary

I have a mezzio app using mezzio-swoole, which is hosted behind a nginx configured as a reverse proxy.

I have configured the access logger like this:

return [
    
    'mezzio-swoole' => [
        'swoole-http-server' => [
            'logger' => [
                'format' => '%h %l %u "%r" %>s %b',
            ],
        ],
    ],

];

However, I have noticed that the %h part is being replaced by the proxy IP address, instead of the real client address.

I have digged in the code and it looks like it's always using the REMOTE_ADDR server param, when it should be first checking the HTTP_X_FORWARDED_FOR one, and if not found, then fall back to REMOTE_ADDR (I think).

It should potentially check HTTP_X_REAL_IP and HTTP_CLIENT_IP first too, as those are common ways to forward real IP addresses from reverse proxies.

Current behavior

When using the %h or %a modifiers for the access logging format, if the app is served behind a reverse proxy, the proxy IP address is logged.

How to reproduce

Set up a mezzio skeleton app, install swoole and mezzio-swoole and add the logger config provided above.

Then put a reverse proxy in front of the app and try accessing it.

Expected behavior

When using the %h or %a modifiers for the access logging format, if the app is served behind a reverse proxy, the real client IP address is logged.

I can provide a fix for this if you think that would be proper solution.

Bug Report

Summary

I have set up Swoole with Mezzio using the mezzio/mezzio-swoole package. I'm running the application with Docker, based on the phpswoole/swoole:4.6-php7.4-alpine image. I have set up 2 routes in the config/routes.php, one is /foo another is /bar. However, when I try to open /foo or /bar in the browser, it matches the / route instead, which is non-existent in my case and it falls back to the NotFoundHandler.

Current behavior

I tried to intercept the request by placing a middleware before the RouteMiddleware to see what does the request contain and I tried printing out the $request->getUri()->getPath(). Regardless of what URL I use to make the request to, the resulting URI path is always /.

How to reproduce

1. Setup a mezzio application
2. Add swoole
3. Configure this in a Docker environment with an entrypoint or cmd to run ./vendor/bin/laminas mezzio:swoole:start
4. Create a route which is not the root, e.g. /foo with a FooHandler
5. Try to visit the /foo URL

Expected behavior

The expected behavior would be for the application to match the request to the specified route. For some reason it seems that Swoole/Mezzio does not recognize the URI path and always shows and matches the root / instead.