HTML is not applying the CSS when viewed in browser - css

Question

I use adminer in a docker container.
For testing services, I use the URL mydomain.tld. To address this container directly, I could expose a port and map, for example, port 8081 to the adminer port 8080.
Addressing this container directly via http://mydomain.tld:8081 works without problem, everything is as it should and the Login dialog looks like that:
However, this approach exposes user and password, so it should not be used.
Using the same docker container via https, however, I get a faulty page. In this case the container is called via the address https://mydomain.tld/adm which is forwarded by the web server addressing mydomain.tld at port 443 to the adminer container to serve the request. The approach is straightforward. The result is identical to the former. Why does this not work?
I used nginx as a proxy and connecting to the adminer container was fine. Now I use yaws and pass through the call to the adminer container.
Obviously the js and css files are not applied by the browser, be it Opera, Chrome, UR, Vivaldi, Edge or Firefox, although the source code is correct and fine. No browser shows errors in the console except Firefox (error messages translated by Bing, emphasis by me), but these errors are obviously attributed erroneously:
Stylesheet https://mydomain.tld/adm?file=default.css&version=4.8.1 was not loaded because its MIME type, text/html, is not text/css.
The script of https://mydomain.tld/adm?file=functions.js&version=4.8.1 was loaded even though its MIME type (text/html) is not a MIME type valid for JavaScript.
These error messages are not correct, as can be seen in the source code: The MIME type definitely is text/css, rel is stylesheet and script should be Javascript anyway.
<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 does Firefox interpret them as text/html (as do probably the other browsers, too)?
Granted, the respective URLs using GET variables do not look like standard files, but they should work nevertheless and they actually do work either way as can be shown by several methods:
As mentioned, the same source code works well when the container is called via html and port 8081.
A click on these links in the HTML source of the https version loads the files without problem in any browser, as it should.
Likewise the developer tools network analysis shows HTTP code 200 for all of them, even in Firefox.
This proves in my eyes that the code received by the browser is OK, no problem here. Either way the source code is identical, except for the path.
I even manipulated the output of the adminer container to provide for the full path, but, as was to be expected, this didn't change a thing, as also proven by the following scenario:
Use the source code of either output in a local file. Here the references cannot be augmented by the browser, so we have to add the full path manually. By switching the path FULL_PATH between the http and https version I can reproduce the behavior from a local file:
<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 is not even https, as it is called from a local file, only one link is.
Why don't the browsers open these files in the https case as would be natural despite developer tools telling all is OK? What is the problem here? Is there a hidden switch preventing to render these files with https?
How can I debug this more intelligently in order to find the reason and a remedy? I ran out of ideas by now.
See also yaws crashes with httpc:request for URL served by docker container for how the html content is produced.

Answer 1

Why does Firefox interpret them as text/html (as do probably the other browsers, too)?
If you look in the "Network" tab of the developer tools, I'm pretty sure that you're going to see that these files are served with a Content-type: text/html HTTP response header, so the browser treats them as HTML instead of CSS and Javascript.
Looking at the Yaws documentation, it seems like your out_adm function needs to return {content, "text/css", Content} or {content, "text/javascript", Content} [{header, {content_type, "text/javascript"}}, {html, Html}] (as per Steve Vinoski's comment) instead of {http, Content} in order to respond with the correct header.

Answer 2

In the end, the workaround was superfluous and the solution was easy: use Yaws with revproxy = / http://adm:8080 in yaws.conf using a new server instruction abc.mydomain.tld.
Nevertheless, there was a lot to learn. Thank you both for your efforts.