Closed serhat-io closed 1 year ago
doesn't work for me.
What do you mean “doesn't work”? Did you check the browser's dev tools to verify where the CSS request is sent and what the response looks like?
Thank you for the hint. As it seems the NGINX container is looking for the file. However, the file is only accessible on the admin container.
nginx | 2023/03/13 17:02:16 [error] 29#29: *9 open() "/var/www/html/adminer.css" failed (2: No such file or directory),
client: 192.168.80.2, server: _, request: "GET /adminer.css?v=3651011416 HTTP/1.1", host: "example.de",
referrer: "https://example.de/adminer"
Do you maybe have a solution for this problem or do I have to bind the data from the admin container to the other nginx container?
The actual issue is that the file is queried without the /adminer/
path in front. The request is to /adminer.css
instead of /adminer/adminer.css
as it should be.
Testing this locally, it appears the issue is that the URL you used is /adminer
instead of /adminer/
. For this reason the web browser does not consider the path to be a directory and performs the wrong relative request.
You should be able to fix this in the nginx config using:
rewrite ^/adminer$ /adminer/ permanent;
nginx | 2023/03/14 10:29:09 [error] 28#28: *4 open() "/var/www/html/adminer/adminer.css" failed (2: No such file or directory),
client: 192.168.80.2, server: _, request: "GET /adminer/adminer.css?v=3651011416 HTTP/1.1", host: "example.de",
referrer: "https://example.de/adminer/"
The redirect you recommended redirects the request to the "adminer" subfolder. However, the adminer data is not in the Nginx subfolder, but in the adminer container under /var/www/html/. This might be a bit confusing in the example.
I would need something like that, that the Nginx is prevented from looking for the file locally at itself and forwards the request for "adminer.css" just like the index.php. The bottom line is that all requests that start with the URL path "/adminer/" should be forwarded to the adminer container.
It may be that this is a limitation of FPM. Unfortunately, I'm not so sure about that.
I found a solution. The problem was that I set some cookie headers for CSS before the location for adminer:
location ~* \.(jpg|jpeg|png|gif|ico|css|js|pdf)$ {
expires 30d;
add_header Cache-Control "public, no-transform";
}
location ~* \.(?:css|js)$ {
expires 30d;
access_log off;
add_header Cache-Control "public";
}
nginx was trying to add it for those files but couldn't find them.
so i just added on both:
try_files $uri $uri/;
Now the request get passed to the FPM container.
Just for the documentation for other people. This is my current adminer location setting:
location ~ ^/adminer(/.*$|$) {
resolver 127.0.0.11 valid=30s;
set $upstream_adminer adminer;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME /var/www/html/index.php;
fastcgi_pass $upstream_adminer:9000;
I have a second solution. So I had to move the location for adminer on top of those header settings. This works too. I just had a wrong order of my default.conf.
Glad you've been able to figure it out! Indeed, if there is another location
block matching the request with a higher priority, it will not work. If all adminer requests are correctly forwarded to the container it will do the right thing.
And just to have it noted: I've edited my example config to include the necessary redirect to add the missing slash.
I have the same issue as in: https://github.com/TimWolla/docker-adminer/issues/64
The solution in https://github.com/TimWolla/docker-adminer/issues/14#issuecomment-385508119 doesn't work for me.
My current setup is like this: