New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CSS and JS files are interpreted as MIME type text/html #2224

Closed
ywiyogo opened this Issue Oct 15, 2018 · 11 comments

Comments

Projects
None yet
3 participants
@ywiyogo
Copy link

ywiyogo commented Oct 15, 2018

Hello,

I tried to start my Grav Project in my new Fedora 28 environment. Note, the project itself has been run in Linux Mint with Apache and in Digital Ocean Ubuntu 16.04 with Nginx.

Now, I installed NGINX and PHP7 as the backend in Fedora 28. After several days playing around with the configuration of Nginx, PHP, Linux user management and SELinux in Fedora 28. I can start my Grav project on my browser locally, without any permission denied anymore. However, now I can only see the HTML text without the CSS themes and the JS functionality.

The Crome browser console prints these errors:

Refused to apply style from '<URL>' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled.

Refused to execute script from 'http://testsite/system/assets/jquery/jquery-2.x.min.js' because its MIME type ('text/html') is not executable, and strict MIME type checking is enabled.

My Nginx configuration nginx.conf consists the configuration from the Grav Documentation https://learn.getgrav.org/webservers-hosting/servers/nginx. I replace the mime.types also from https://github.com/h5bp/server-configs-nginx as recommended.

The sites-enabled Nginx configuration in /etc/nginx/sites-enabled/testsite.conf is like this:

server {
    #listen 80;
    index index.html index.php;

    ## Begin - Server Info
    root /var/www/testsite;
    server_name testsite;
    access_log /var/log/nginx/testsite/access.log;
    error_log /var/log/nginx/testsite/error.log;

    ## End - Server Info

    ## Begin - Index
    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
    ## End - Index

    ## Begin - Security
    # deny all direct access for these folders
    location ~* /(\.git|cache|bin|logs|backup|tests)/.*$ { return 403; }
    # deny running scripts inside core system folders
    location ~* /(system|vendor)/.*\.(txt|xml|md|html|yaml|yml|php|pl|py|cgi|twig|sh|bat)$ { return 403; }
    # deny running scripts inside user folder
    location ~* /user/.*\.(txt|md|yaml|yml|php|pl|py|cgi|twig|sh|bat)$ { return 403; }
    # deny access to specific files in the root folder
    location ~ /(LICENSE\.txt|composer\.lock|composer\.json|nginx\.conf|web\.config|htaccess\.txt|\.htaccess) { return 403; }
    ## End - Security

    ## Begin - PHP
    location ~ \.php$ {
        # Choose either a socket or TCP/IP address
        fastcgi_pass unix:/run/php-fpm/php-fpm-grav.sock;
        # fastcgi_pass 127.0.0.1:9000;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root/$fastcgi_script_name;
    }
    ## End - PHP

}

I've tried several possible solutions from stackoverflow like from https://stackoverflow.com/questions/10075304/nginx-fails-to-load-css-files/23282158. But, no fix for me.
I did include the mime.types in the nginx.conf jsut like in the Grav documentation.
Someone wrote that it happens due to the comment at the beginning of the CSS files.

Any hints to fix this issue?

Thanks in advanced

@ElectronicWar

This comment has been minimized.

Copy link

ElectronicWar commented Oct 15, 2018

Check with developer tools of Chrome or Firefox if your web server really returns text/css for your .css files and application/javascript for your .js files. Otherwise check if mine.types get loaded properly (check nginx logs) or if you get configuration errors (nginx -t).

@ywiyogo

This comment has been minimized.

Copy link
Author

ywiyogo commented Oct 15, 2018

How can I check in the developer tools exactly?
If I call http://testsite/user/themes/antimatter/css-compiled/nucleus.css on Chrome, I can see the same error above in the console field. I searched in other tabs and field, I cannot find how to check the return value forthe css file.

After running nginx -t it gave me a warning nginx: [warn] duplicate MIME type "text/html" in /etc/nginx/nginx.conf:71. It points to the line text/html after the gzip_types section. I removed the line and did a restart. But the error is still there. But, thanks for the hint.

In the nginx error.log I see Permission denied outputs, no mime.types issues found:

2018/10/15 19:15:10 [crit] 31049#0: *1 stat() "/var/www/testsite/user/themes/antimatter/css/slidebars.min.css" failed (13: Permission denied), client: 127.0.0.1, server: testsite, request: "GET /user/themes/antimatter/css/slidebars.min.css HTTP/1.1", host: "testsite", referrer: "http://testsite/"

2018/10/15 19:15:10 [crit] 31049#0: *2 stat() "/var/www/testsite/system/assets/jquery/jquery-2.x.min.js" failed (13: Permission denied), client: 127.0.0.1, server: testsite, request: "GET /system/assets/jquery/jquery-2.x.min.js HTTP/1.1", host: "testsite", referrer: "http://testsite/"

There is no issue with the Linux permission because I set chmod 777:

-rwxrwxr-x. 1 www-data www-data 85578 15. Okt 16:01 /var/www/testsite/system/assets/jquery/jquery-2.x.min.js
@ElectronicWar

This comment has been minimized.

Copy link

ElectronicWar commented Oct 15, 2018

nginx.conf should only have the line include /etc/nginx/mime.types; in it and no further manually defined mime types. mime.types can be used from the repo you linked in your first post, it contains the nice complete version of it. Make sure to overwrite the default file.

The permission errors might be from earlier. Feel free to delete the logs and restart nginx to get a blank slate.

For checking the mimetype, open your CSS file in the browser, open dev tools, go to network tab and reload the file. Click on the file request in the network tab that now occurred and it will show you the http headers.

@rhukster rhukster added the question label Oct 15, 2018

@ywiyogo

This comment has been minimized.

Copy link
Author

ywiyogo commented Oct 16, 2018

Thanks for the hints @ElectronicWar !
The css and js files return text/html as the content type. Here are the outputs:

Content-Encoding | gzip
Content-Type | text/html;charset=UTF-8

In https://learn.getgrav.org/webservers-hosting/servers/nginx, we see several types for gzip:

gzip_types
        application/atom+xml
        application/javascript
        ...
        text/css
        ....
        text/x-cross-domain-policy;

Do you mean that those lines will conflict with the include /etc/nginx/mime.types;? I did remove the text/css in this gzip_types line, but there is also no fix.

My nginx.conf contains include mime.types; instead of include /etc/nginx/mime.types;. But there is no effect since Nginx can deal with the relative path.

After deleting the error.log and restarting Nginx, I still see the permission denied for the css and js files which are listed in the network tab of the dev tool:

2018/10/16 19:34:42 [crit] 13689#0: *1 stat() "/var/www/testsite/user/themes/antimatter/css-compiled/nucleus.css" failed (13: Permission denied), client: 127.0.0.1, server: testsite, request: "GET /user/themes/antimatter/css-compiled/nucleus.css HTTP/1.1", host: "testsite"

Somehow it is strange with my Nginx configuration.

@ywiyogo

This comment has been minimized.

Copy link
Author

ywiyogo commented Oct 16, 2018

I've just tested another root folder which contains only a hello world index.html and style.css. the index.html includes the style.css.
Using this sites-enabled config file with TCP connection (not with the socket), it can response the css file without any problem:

server {
    server_name varwww.local;   
    
    root /var/www/html;

    location / {
        index index.html index.php;
    }

    location ~ \.php$ {
        include /etc/nginx/fastcgi_params;
        fastcgi_pass  127.0.0.1:9000;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

I then changed my testsite.conf to the TCP connection. However, it still cannot response the css and the js file correctly. I still don't have a clue which configuration in my testsite.conf is wrong.

@ywiyogo

This comment has been minimized.

Copy link
Author

ywiyogo commented Oct 16, 2018

Meanwhile, I found out the cause. What I did that caused the issue was that I created a symlink to a directory. I cloned my project from my Git repository to my home folder (e.g. /home/user/projects/testsite), and then created a symlink to /var/www/testsite. I did this to prevent a double copy that unsynchronized in my computer. However, it seems that somehow Nginx cannot deal with a directory symlink.
After I copy the entire folder to /var/www/testsite it works. But, I cannot use this solution since all the files are created as a new file and I lost the history date.
Does anybody know a workaround to work with a symlink in this case?
Using the original folder (e.g. /home/user/projects/testsite) as the root folder in my testsite.conf doesn't work either.

@ElectronicWar

This comment has been minimized.

Copy link

ElectronicWar commented Oct 17, 2018

My whole www folder is a symlink back to a brtfs partition. But you must make sure that the files/folders in it have the correct permissions so that the www-data user/group can read them. This includes +x to allow for directory file listings.

@ywiyogo

This comment has been minimized.

Copy link
Author

ywiyogo commented Oct 17, 2018

It is weird. The permissions are correct. I even change to chmod 777 -R. In the network tab of the Firefox browser dev tool I can see the HTTP status 200 for all the css and the js files. However, Chrome shows (canceled) in the status column. The Nginx's error.log reports as access failed (13: permission denied).
If you also did a symlink, somehow I don't understand anymore what could be the root cause.

The ls -lZ which also show the SELinux states, shows everything is accessible:

-rwxrwxrwx. 1 www-data www-data unconfined_u:object_r:httpd_sys_content_t:s0 802 24. Sep 22:12 /home/y2/ydata/yweb/yinvesto/user/themes/antimatter/js/antimatter.js

SELinux is also deactivated. I think, I shall change my OS.

@ywiyogo ywiyogo closed this Nov 7, 2018

@ywiyogo

This comment has been minimized.

Copy link
Author

ywiyogo commented Nov 25, 2018

@ElectronicWar, I found the solution of this issue from https://serverfault.com/questions/170192/nginx-php-fpm-permission-denied-error-13-in-nginx-log-configuration-mista/170263.

Since I made a symbolic link from my home folder /home/user/project, the /home and /home/user has to be accessible by the user of the nginx worker process.

@ElectronicWar

This comment has been minimized.

Copy link

ElectronicWar commented Nov 25, 2018

Well, that's what I already wrote back on Oct 17th, the folder must be accessible by the www-data user. But glad that you were able to fix it 👍

@ywiyogo

This comment has been minimized.

Copy link
Author

ywiyogo commented Nov 29, 2018

I understand your message on Oct 17th to check the folder and the files inside the project root folder. The permission was good. However, I did know that I have to check the permission of the parent folders of the project folder also.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment