Nginx ne parvient pas à charger les fichiers css

Question

J'ai récemment décidé de passer d'Apache2 à Nginx. J'ai installé Nginx sur mon serveur CentOS et j'ai mis en place une configuration de base. Lorsque j'ai essayé de charger mon site dans un navigateur (FF/Chrome), j'ai remarqué que le fichier css n'était pas chargé. J'ai vérifié la console d'erreur et j'ai vu ce message :

Error: The stylesheet http://example.com/style.css was not loaded because its MIME type, "text/html", is not "text/css".

J'ai vérifié la configuration de Nginx et tout semble aller bien :

http {
    include /etc/nginx/mime.types;
    ..........
}

Le type de mime pour les fichiers css est correctement défini dans /etc/nginx/mime.types.

text/css css;

Tout semble bien configuré mais mes fichiers css ne sont toujours pas chargés. Je n'ai pas d'explication.

Une autre chose mérite d'être mentionnée. Initialement, j'ai installé Nginx en utilisant les dépôts epel et j'ai obtenu une ancienne version : 0.8... Il m'a semblé que mon problème venait d'un bug dans cette version, j'ai donc désinstallé la version 0.8, ajouté le dépôt nginx à yum et installé la dernière version : 1.0.14. Je pensais que la nouvelle version résoudrait mon problème, mais malheureusement ce n'est pas le cas, je suis donc à court d'idées.

J'apprécie toute aide.

Fichiers de configuration :

/etc/nginx/nginx.conf

user  nginx;
worker_processes  1;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    #gzip  on;

    include /etc/nginx/conf.d/*.conf;
}

/etc/nginx/conf.d/default.conf

server {
    listen       80;
    server_name  localhost;

    #charset koi8-r;
    #access_log  /var/log/nginx/log/host.access.log  main;

    location / {
         root    /usr/share/nginx/html;
         index  index.html index.htm index.php;
         fastcgi_pass   127.0.0.1:9000;
         fastcgi_index  index.php;
         fastcgi_param  SCRIPT_FILENAME  /usr/share/nginx/html$fastcgi_script_name;
         include        fastcgi_params;
    }

    #error_page  404              /404.html;

    # redirect server error pages to the static page /50x.html
    #
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }

    # proxy the PHP scripts to Apache listening on 127.0.0.1:80
    #
    #location ~ \.php$ {
    #    proxy_pass   http://127.0.0.1;
    #}

    # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
    #
    #location ~ \.php$ {
    #    root           html;
    #    fastcgi_pass   127.0.0.1:9000;
    #    fastcgi_index  index.php;
    #    fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
    #    include        fastcgi_params;
    #}

    # deny access to .htaccess files, if Apache's document root
    # concurs with nginx's one
    #
    #location ~ /\.ht {
    #    deny  all;
    #}
}

/etc/nginx/mime.types

types {
    text/html                             html htm shtml;
    text/css                              css;
    text/xml                              xml;
    image/gif                             gif;
    image/jpeg                            jpeg jpg;
    application/x-javascript              js;
    application/atom+xml                  atom;
    application/rss+xml                   rss;
    ..........................................
    other types here
    ..........................................
}

Answer 1

La mise en place de la include /etc/nginx/mime.types; sous location / { au lieu de sous http { a résolu le problème pour moi.

Answer 2

J'ai trouvé une solution de contournement sur le web. J'ai ajouté à /etc/nginx/conf.d/default.conf ce qui suit :

location ~ \.css {
    add_header  Content-Type    text/css;
}
location ~ \.js {
    add_header  Content-Type    application/x-javascript;
}

Le problème est qu'une requête vers mon fichier css n'est pas bien redirigée, comme si Root n'était pas correctement configuré. Dans le fichier error.log, je vois

2012/04/11 14:01:23 [error] 7260#0 : *2 open() "/etc/nginx//html/style.css"

J'ai donc ajouté la racine à chaque emplacement défini. Cela fonctionne maintenant, mais semble un peu redondant. La racine n'est-elle pas héritée de / location ?

Answer 3

style.css est en fait traité via fastcgi en raison de votre directive "location /". C'est donc fastcgi qui sert le fichier ( nginx > fastcgi > filesystem ), et non le système de fichiers directement ( nginx > filesystem ).

Pour une raison qui m'échappe encore (je suis sûr qu'il y a une directive quelque part), NGINX applique le type mime text/html à tout ce qui est servi par fastcgi, à moins que l'application dorsale ne dise explicitement le contraire.

Le coupable est précisément ce bloc de configuration :

location / {
     root    /usr/share/nginx/html;
     index  index.html index.htm index.php;
     fastcgi_pass   127.0.0.1:9000;
     fastcgi_index  index.php;
     fastcgi_param  SCRIPT_FILENAME  /usr/share/nginx/html$fastcgi_script_name;
     include        fastcgi_params;
}

Il devrait l'être :

location ~ \.php$ { # this line
     root    /usr/share/nginx/html;
     index  index.html index.htm index.php;
     fastcgi_split_path_info ^(.+\.php)(/.+)$; #this line
     fastcgi_pass   127.0.0.1:9000;
     fastcgi_index  index.php;
     fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name; # update this too
     include        fastcgi_params;
}

Cette modification permet de s'assurer que seuls les *.php sont demandés à fastcgi. À ce stade, NGINX appliquera le type MIME correct. Si vous avez une réécriture d'URL, vous devez gérer ceci avant la directive sur l'emplacement ( location ~\.php$ ) afin que l'extension correcte soit dérivée et correctement acheminée vers fastcgi.

Ne manquez pas de consulter cet article concernant des considérations supplémentaires en matière de sécurité lors de l'utilisation de try_files . Compte tenu des implications en matière de sécurité, je considère qu'il s'agit d'une fonctionnalité et non d'un bogue.

Answer 4

J'ai également rencontré ce problème. Il m'a déconcerté jusqu'à ce que je comprenne ce qui n'allait pas :

Vous avez ceci :

include       /etc/nginx/mime.types;
default_type  application/octet-stream;

C'est ce que vous voulez :

default_type  application/octet-stream;
include       /etc/nginx/mime.types;

il semble qu'il y ait un bug dans nginx ou une lacune dans la documentation (cela pourrait être le comportement voulu, mais c'est étrange)

Answer 5

J'ai suivi les conseils donnés dans les autres réponses et j'ai découvert que ces actions bizarres m'ont aidé (du moins dans mon cas).

1) J'ai ajouté au bloc serveur ce qui suit :

location ~ \.css {
 add_header Content-Type text/css;
}

J'ai rechargé nginx et j'ai obtenu ceci dans le fichier error.log :

2015/06/18 11:32:29 [error] 3430#3430 : *169 open() "/etc/nginx/html/css/mysite.css" a échoué (2 : No such file or directory)

2) J'ai supprimé les lignes, rechargé nginx et j'ai obtenu des css qui fonctionnent. Je ne peux pas expliquer ce qui s'est passé car mon fichier conf est redevenu comme avant.

Mon cas était propre xubuntu 14.04 sur VirtualBox, nginx/1.9.2, une ligne 127.51.1.1 mysite dans /etc/hosts et un simple /etc/nginx/nginx.conf avec un bloc serveur :

user nginx;
worker_processes 1;

error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    include /etc/nginx/mime.types;

    server {
        listen 80;
        server_name mysite;

        location / {
            root /home/testuser/dev/mysite/;
        }
    }
}