I am utilizing adminer within a docker container.
When testing services, I utilize the URL mydomain.tld. In order to interact with this container directly, one option is to expose and map a port, such as mapping port 8081 to the adminer port 8080.
Accessing this container directly via http://mydomain.tld:8081 functions smoothly without any issues, everything appears to be in order and the Login dialog displays as follows:
https://i.sstatic.net/WmLHm.png
Although, this method exposes user credentials, thus it is not recommended.
However, when trying to access the same docker container via https, I encounter a faulty page. The container is accessed through the address https://mydomain.tld/adm, which is then redirected by the web server from mydomain.tld at port 443 to the adminer container to handle the request. The process seems straightforward. The result mirrors that of the previous approach. So why doesn't it work?
Initially, I used nginx as a proxy and connectivity to the adminer container was successful. Now, I have switched to using yaws and intercepted the call to the adminer container.
https://i.sstatic.net/xpk46.png
Evidently, the js and css files are not being applied by browsers like Opera, Chrome, UR, Vivaldi, Edge, or Firefox, despite the fact that the source code is correct and valid. No browser shows errors in the console except for Firefox (error messages translated by Bing, emphasis added), however, these errors seem to be misattributed:
The Stylesheet did not load due to an incorrect MIME type, text/html instead of text/css.
The script file loaded even though its MIME type (text/html) does not align with accepted types for JavaScript.
These error messages do not accurately reflect reality, as detailed in the source code: The MIME type is clearly text/css, the relation is stylesheet, and the script should be identified as Javascript.
<link rel="stylesheet" type="text/css" href="?file=default.css&version=4.8.1">
<script src='?file=functions.js&version=4.8.1' nonce="ZDA0ODE4Y2ZhZWY1NzkyZTUxNzg3MGZlNTdlNTcxM2M="></script>
Why is Firefox interpreting them as text/html (and presumably other browsers are doing the same)?
It is evident that the URLs utilizing GET variables may not appear conventional, but they should still function properly, as evidenced by various methods:
As stated earlier, the identical code works seamlessly when the container is accessed via
httpon port 8081.Clicking on these links within the HTML source in the
httpsversion successfully loads the files across all browsers.Even network analysis via developer tools confirms HTTP status code 200 for all resources, including in Firefox.
This demonstrates that the code delivered to the browser is indeed correct, indicating no issues here. Regardless, the source codes remain indistinguishable, save for the path.
I also tried manipulating the output stream of the adminer container to include the full path, but as predicted, this alteration had no effect, as demonstrated in the following scenario:
Insert the source code of either output in a local document. Since the browser cannot adjust the references, we manually input the full path. By toggling the path FULL_PATH between the http and https versions, I replicated the behavior locally:
<link rel="stylesheet" type="text/css" href="FULL_PATH?file=default.css&version=4.8.1">
<!-- http://mydomain.tld:8081/ works; https://mydomain.tld/adm/ works per click, but not in browser-->
This file isn't even linked via https, since it originates from a local file; only one link is.
Why aren't the browsers rendering these files in the https instance as one would expect, despite developer tools signifying all is well? What could be causing this issue? Is there perhaps a hidden setting inhibiting the rendering of these files over https?
What steps can I take to perform more insightful debugging to identify the cause and solution? At present, I'm running low on ideas.
Refer to yaws crashes with httpc:request for URL served by docker container for details on how the html content is generated.