[Bug]: Error in Checking JavaScript Support for .mjs Files in Nextcloud Behind Reverse Proxy

[pingou2712]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

I encountered an issue with Nextcloud running behind a HAProxy reverse proxy, where it displayed an error message: "Could not check for JavaScript support. Please check manually if your web server serves .mjs files using the JavaScript MIME type."

This problem was manifesting due to Nextcloud's internal mechanism for verifying JavaScript support for .mjs files. In my configuration, Nextcloud was served by an Apache server, which communicated internally using HTTP. Externally, HAProxy was configured to handle HTTPS connections and forward these requests to the Apache server.

The issue was particularly perplexing as direct HTTP access to the .mjs test file (using curl -I http://cloud.mydomain.com/apps/settings/js/esm-test.mjs) worked correctly, serving the file with the appropriate JavaScript MIME type. However, Nextcloud's internal check, seemingly performed over HTTPS, led to the test failure. It appeared that Nextcloud was not correctly interpreting the reverse proxy setup, especially with internal server communication over HTTP and external access over HTTPS.

A critical factor in this configuration was the hostname of the Apache server, initially set to cloud.mydomain.com. This hostname seemed to contribute to the issue, likely causing Nextcloud to attempt internal resolution, thereby bypassing the HAProxy layer responsible for HTTPS.

Resolution:

The issue was successfully resolved by changing the hostname of the Apache server from cloud.mydomain.com to internal-cloud.mydomain.com. This modification ensured that internal requests within the server did not mistakenly bypass HAProxy, allowing Nextcloud to correctly interpret the environment and eliminating the error related to .mjs file JavaScript support checks. With this change, all functions in Nextcloud, including the handling of .mjs files, are operating correctly as intended in the HAProxy reverse proxy setup.

Reason for Reporting the Bug:

Despite resolving the issue through a hostname change, I am reporting this bug because I believe Nextcloud should be able to handle such scenarios without requiring a server hostname change. In an ideal setup, Nextcloud should be capable of accurately recognizing and adapting to environments where it is deployed behind a reverse proxy, regardless of the server's internal hostname. This bug report is aimed at improving Nextcloud's functionality in similar configurations and ensuring smoother operation in diverse network setups.

Steps to reproduce

1.Set up Nextcloud on an Apache server with the internal hostname cloud.mydomain.com.
2.Configure HAProxy as a reverse proxy to handle HTTPS, forwarding requests to the Apache server, which communicates internally using HTTP.
3.Access the Nextcloud instance through the proxy (https://cloud.mydomain.com) and navigate to the settings or admin panel.
4.Observe the error message concerning JavaScript support for .mjs files.
5.Test direct HTTP access to the .mjs file via curl -I http://cloud.mydomain.com/apps/settings/js/esm-test.mjs and confirm it serves correctly with the appropriate MIME type.
6.Note that due to the internal server hostname being cloud.mydomain.com, Nextcloud attempts to verify the .mjs file using HTTPS within the local network, bypassing HAProxy, and leading to the test failure.

Expected behavior

In an ideal setup, Nextcloud should correctly recognize and handle JavaScript file checks for .mjs files behind a reverse proxy without errors. The system should accurately detect the MIME type regardless of the server's internal hostname configuration.

Installation method

Community Manual installation with Archive

Nextcloud Server version

28

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.2

Web server

Apache (supported)

Database engine version

MariaDB

Is this bug present after an update or on a fresh install?

None

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

No response

List of activated Apps

No response

Nextcloud Signing status

No response

Nextcloud Logs

{"reqId":"9FuMVR3kCmPxZWLCMyPz","level":0,"time":"2024-02-22T08:02:14+00:00","remoteAddr":"82.66.88.7","user":"root","app":"settings","method":"GET","url":"/index.php/settings/ajax/checksetup","message":"Can not connect to local server for checking JavaScript modules support","userAgent":"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36","version":"28.0.2.5","exception":{"Exception":"GuzzleHttp\\Exception\\ConnectException","Message":"cURL error 7: Failed to connect to cloud.mydomain.com port 443 after 3 ms: Couldn't connect to server (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://cloud.mydomain.com/apps/settings/js/esm-test.mjs","Code":0,"Trace":[{"file":"/var/www/nextcloud/3rdparty/guzzlehttp/guzzle/src/Handler/CurlFactory.php","line":158,"function":"createRejection","class":"GuzzleHttp\\Handler\\CurlFactory","type":"::","args":["*** sensitive parameters replaced ***"]},{"file":"/var/www/nextcloud/3rdparty/guzzlehttp/guzzle/src/Handler/CurlFactory.php","line":110,"function":"finishError","class":"GuzzleHttp\\Handler\\CurlFactory","type":"::"},{"file":"/var/www/nextcloud/3rdparty/guzzlehttp/guzzle/src/Handler/CurlHandler.php","line":47,"function":"finish","class":"GuzzleHttp\\Handler\\CurlFactory","type":"::"},{"file":"/var/www/nextcloud/3rdparty/guzzlehttp/guzzle/src/Middleware.php","line":137,"function":"__invoke","class":"GuzzleHttp\\Handler\\CurlHandler","type":"->"},{"file":"/var/www/nextcloud/lib/private/Http/Client/DnsPinMiddleware.php","line":121,"function":"GuzzleHttp\\{closure}","class":"GuzzleHttp\\Middleware","type":"::","args":["*** sensitive parameters replaced ***"]},{"file":"/var/www/nextcloud/3rdparty/guzzlehttp/guzzle/src/PrepareBodyMiddleware.php","line":35,"function":"OC\\Http\\Client\\{closure}","class":"OC\\Http\\Client\\DnsPinMiddleware","type":"->","args":["*** sensitive parameters replaced ***"]},{"file":"/var/www/nextcloud/3rdparty/guzzlehttp/guzzle/src/Middleware.php","line":31,"function":"__invoke","class":"GuzzleHttp\\PrepareBodyMiddleware","type":"->"},{"file":"/var/www/nextcloud/3rdparty/guzzlehttp/guzzle/src/RedirectMiddleware.php","line":71,"function":"GuzzleHttp\\{closure}","class":"GuzzleHttp\\Middleware","type":"::","args":["*** sensitive parameters replaced ***"]},{"file":"/var/www/nextcloud/3rdparty/guzzlehttp/guzzle/src/Middleware.php","line":63,"function":"__invoke","class":"GuzzleHttp\\RedirectMiddleware","type":"->"},{"file":"/var/www/nextcloud/3rdparty/guzzlehttp/guzzle/src/HandlerStack.php","line":75,"function":"GuzzleHttp\\{closure}","class":"GuzzleHttp\\Middleware","type":"::","args":["*** sensitive parameters replaced ***"]},{"file":"/var/www/nextcloud/3rdparty/guzzlehttp/guzzle/src/Client.php","line":331,"function":"__invoke","class":"GuzzleHttp\\HandlerStack","type":"->"},{"file":"/var/www/nextcloud/3rdparty/guzzlehttp/guzzle/src/Client.php","line":168,"function":"transfer","class":"GuzzleHttp\\Client","type":"->"},{"file":"/var/www/nextcloud/3rdparty/guzzlehttp/guzzle/src/Client.php","line":187,"function":"requestAsync","class":"GuzzleHttp\\Client","type":"->","args":["*** sensitive parameters replaced ***"]},{"file":"/var/www/nextcloud/lib/private/Http/Client/Client.php","line":261,"function":"request","class":"GuzzleHttp\\Client","type":"->"},{"file":"/var/www/nextcloud/apps/settings/lib/SetupChecks/JavaScriptModules.php","line":67,"function":"head","class":"OC\\Http\\Client\\Client","type":"->"},{"file":"/var/www/nextcloud/lib/private/SetupCheck/SetupCheckManager.php","line":49,"function":"run","class":"OCA\\Settings\\SetupChecks\\JavaScriptModules","type":"->"},{"file":"/var/www/nextcloud/apps/settings/lib/Controller/CheckSetupController.php","line":303,"function":"runAll","class":"OC\\SetupCheck\\SetupCheckManager","type":"->"},{"file":"/var/www/nextcloud/lib/private/AppFramework/Http/Dispatcher.php","line":230,"function":"check","class":"OCA\\Settings\\Controller\\CheckSetupController","type":"->"},{"file":"/var/www/nextcloud/lib/private/AppFramework/Http/Dispatcher.php","line":137,"function":"executeController","class":"OC\\AppFramework\\Http\\Dispatcher","type":"->"},{"file":"/var/www/nextcloud/lib/private/AppFramework/App.php","line":184,"function":"dispatch","class":"OC\\AppFramework\\Http\\Dispatcher","type":"->"},{"file":"/var/www/nextcloud/lib/private/Route/Router.php","line":315,"function":"main","class":"OC\\AppFramework\\App","type":"::"},{"file":"/var/www/nextcloud/lib/base.php","line":1069,"function":"match","class":"OC\\Route\\Router","type":"->"},{"file":"/var/www/nextcloud/index.php","line":39,"function":"handleRequest","class":"OC","type":"::"}],"File":"/var/www/nextcloud/3rdparty/guzzlehttp/guzzle/src/Handler/CurlFactory.php","Line":210,"message":"Can not connect to local server for checking JavaScript modules support","exception":[],"url":"https://cloud.mydomain.com/apps/settings/js/esm-test.mjs","CustomMessage":"Can not connect to local server for checking JavaScript modules support"},"id":"65d70b86c573e"}

Additional info

No response

[joshtrichards]

A critical factor in this configuration was the hostname of the Apache server, initially set to cloud.mydomain.com. This hostname seemed to contribute to the issue, likely causing Nextcloud to attempt internal resolution, thereby bypassing the HAProxy layer responsible for HTTPS.

You closed this so not sure if you were looking for something else here then figured it out or what, but for what it's worth:

• The setup you have is very very common and there's no reason the check shouldn't pass on it even prior to your changes (but...)
• This sounds like it was a DNS matter - as in there is something in your environment (e.g. internal DNS or an /etc/hosts entry) that is making your app server resolve cloud.mydomain.com to a different IP address than the one actually used (which hits/is that of your proxy)
• The Apache configuration isn't really a factor. The hostname used in VirtualHost is merely used to match to the Host: header sent by a browser/etc. It's not impacted by DNS nor does it cause connections from the running Nextcloud Server itself - such as for this test - to be intercepted. The only thing that can cause that is conflicting DNS resolution (from the app server).
• The main reason your approach worked is likely because it - in effect - bypassed the erroneous internal DNS entry.

I presume none of your other listed trusted_domains are/were accessible as well?

[pingou2712]

Yes, indeed, it was a DNS resolution issue that was causing the problem. I had named my backend machine as cloud.mydomain.com, but in reality, cloud.mydomain.com points to the HAProxy from the outside. As a result, tests targeting cloud.mydomain.com were not routed through HAProxy but were directly reaching the machine named cloud.mydomain.com. Changing the backend name to cloudbackend.mydomain.com, therefore, resolves the issue. When I wrote the initial message, I found it somewhat abnormal that Nextcloud wasn't performing the tests via HTTP, considering it should be aware of being behind a proxy. However, upon reflection, this behavior/bug now seems normal to me, which is why I closed the bug report. Hopefully, this information might help someone in the future...
Thank you for responding anyway ;)

[canoine]

I see this issue is closed for several months, so perhaps should I open a new one ?

As I meet the same problem (apache instance behind a nginx reverse proxy), I wonder if the way Nextcloud tests itself is pertinent : Nextcloud reports a warning because the test fails, but apache does support .mjs files well. For me, having to modify a working configuration only to suppress a warning message is abnormal.

[canoine]

No answer is an answer. Let's open a new issue.