Cross-laravel application HTTP request 504 Gateway Time-out

[garygreen]

Current Behavior

When trying make file_get_contents request to another Laravel application running locally with Flarum - it will timeout with 504 Gateway error.

Steps to Reproduce

extend.php (load Flarum forum for the file_get_contents() to trigger)

return [
    (new Extend\Frontend('forum'))
        ->content(function(Document $document, Request $request) {
             // this times out with 504
             dd(file_get_contents('http://another-local-laravel-app.local/api/some-request'));
        })
];

If I make the same request without Flarum and directly in a PHP file, it succeeds.

test.php (call with: php test.php)

// works, comes back with response
dd(file_get_contents('http://another-local-laravel-app.local/api/some-request'));

Expected Behavior

It should allow the file_get_contents request to succeed.

Screenshots

Environment

• Flarum version: 1.7
• Webserver: nginx (local on Windows) running php-cgi.exe
• PHP version: 8.2
• Browser: Chrome 110

Output of php flarum info

Flarum core: 1.7.1 PHP version: 8.2.2 MySQL version: 10.2.19-MariaDB Loaded extensions: Core, bcmath, calendar, ctype, date, filter, hash, iconv, json, SPL, pcre, random, readline, Reflection, session, standard, mysqlnd, tokenizer, zlib, libxml, dom, PDO, openssl, SimpleXML, xml, xmlreader, xmlwriter, curl, fileinfo, gd, gmp, intl, imap, mbstring, exif, mysqli, Phar, pdo_mysql, Zend OPcache +----------------------+---------+--------+ | Flarum Extensions | | | +----------------------+---------+--------+ | ID | Version | Commit | +----------------------+---------+--------+ | flarum-approval | v1.7.0 | | | flarum-bbcode | v1.7.0 | | | flarum-emoji | v1.7.0 | | | flarum-lang-english | v1.7.0 | | | flarum-flags | v1.7.0 | | | flarum-likes | v1.7.0 | | | flarum-lock | v1.7.0 | | | flarum-markdown | v1.7.0 | | | flarum-mentions | v1.7.0 | | | flarum-statistics | v1.7.0 | | | flarum-sticky | v1.7.0 | | | flarum-subscriptions | v1.7.0 | | | flarum-suspend | v1.7.0 | | | flarum-tags | v1.7.1 | | +----------------------+---------+--------+ Base URL: http://flarum.local Installation path: E:\Sites\app\public\~fla Queue driver: sync Session driver: file Mail driver: mail Debug mode: ON

Possible Solution

This maybe to do with a long-standing Laravel issue where doing cross-application requests without config caching can lead to strange environments being configured and requests failing.

Possibly related:

https://github.com/vlucas/phpdotenv/issues/219 https://github.com/laravel/framework/issues/19820

A solution could be to cache flarums config files - but it doesn't seem like there is an option to do that in flarum cli, like you can with Laravel php artisan config:cache. I tried caching the other Laravel apps config but it still didn't work. I could be barking up the wrong tree here, as it might be related to another issue though.

Additional Context

No response

[luceos]

I don't think Flarum has any relation to the file_get_contents in your snippet. Can you move that api call above the return [] array and see if the same timeout is generated or not?

[garygreen]

@luceos Even if I put it in a middleware it has the same problem. I've actually solved this by running fastCGI on a different port for Flarum and the other Laravel app. So it is as I suspected - something to do with conflicting env environments with Flarum and the other Laravel app. Maybe this isn't a problem specific to Flarum, though I think it may help if Flarum had a way of caching the config.

[garygreen]

See this comment recommending cached config, as that bypasses DotEnv loading during bootstrapping which could resolve this: https://github.com/vlucas/phpdotenv/issues/219#issuecomment-317444983

Is there any plans to add php flarum config:cache ?

[SychO9]

See this comment recommending cached config, as that bypasses DotEnv loading during bootstrapping which could resolve this: vlucas/phpdotenv#219 (comment)

Flarum doesn't use DotEnv, nor does it cache the config in that sense so a config:cache command does not make sense here, I believe you are dealing with a different issue on your server, as what you are referring to is a laravel-specific issue.

[luceos]

@garygreen

I really fail to understand how this can be a Flarum issue. Are you sure this isn't an opcache issue? Any changes to your files (with opcache enabled) requires an opcache flush.

[garygreen]

@luceos Your welcome to try it - try to file_get_contents of a local Laravel app running on same FastCGI host/port if you happen to have one available.

It isn't Opcache (not enabled at all for me on localhost) - it's most likely env problem. See links mentioned above - caching of configs seems to help. If Flarum doesn't use DotEnv I wonder how it sets up the environment? Is that possibly conflicting with the other Laravel apps environment variables? putenv $_ENV

I'll close this issue. At least there is some visibility for devs if they come across the problem and find the above links useful.

[luceos]

What is your environment like? I see you're on Windows, do you use virtualisation @garygreen ?

PS I just tested this on my macbook using a wildcard nginx install with pretty much exactly your code to another laravel app on the same machine and it works.

[garygreen]

I am indeed on Windows with nginx. Have php-cgi.exe -b 127.0.0.1:9000 running and use nginx config setup so that both Flarum and other Laravel app use same fastcgi_pass

location ~ \.php$ {
    fastcgi_pass   127.0.0.1:9000;
    fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include        fastcgi_params;
}

Btw thank you so much for taking a look at it. It might be a Windows specific problem. Changing FastCGI to run on different ports for Flarum and the other Laravel app fixes it (of course requires another php-cgi.exe to be listening)