Mon application rails fonctionne parfaitement bien dans la production en utilisant nginx et licorne sauf pour une chose: Demande /articles.rss
et /articles.json
conduit à une 404 avec une erreur dans les journaux nginx que le fichier demandé n'existe pas. Demander par ex. /articles?format=rss
fonctionne. Donc, il semble que le .rss conduit nginx à penser qu'il s'agit d'un fichier statique plutôt que d'un contenu généré dynamiquement. En développement (en utilisant le serveur intégré de rails) cela fonctionne bien.nginx essaie de servir .rss/.json lui-même plutôt que de laisser les rails/licorne servir
J'utilise le h5bp config files for nginx, voici ma configuration du site (nom de domaine remplacé):
# www to non-www redirect -- duplicate content is BAD:
# https://github.com/h5bp/html5-boilerplate/blob/5370479476dceae7cc3ea105946536d6bc0ee468/.htaccess#L362
# Choose between www and non-www, listen on the *wrong* one and redirect to
# the right one -- http://wiki.nginx.org/Pitfalls#Server_Name
upstream app {
server unix:/var/www/rails-cms/shared/tmp/sockets/rails-cms.unicorn.sock fail_timeout=0;
}
server {
# don't forget to tell on which port this server listens
listen [::]:80;
listen 80;
# listen on the www host
server_name www.<my domain>;
# and redirect to the non-www host (declared below)
return 301 $scheme://<my domain>$request_uri;
}
server {
# listen [::]:80 accept_filter=httpready; # for FreeBSD
# listen 80 accept_filter=httpready; # for FreeBSD
# listen [::]:80 deferred; # for Linux
# listen 80 deferred; # for Linux
listen [::]:80;
listen 80;
# The host name to respond to
server_name <my domain>;
# Path for static files
root /var/www/rails-cms/current/public;
try_files $uri/index.html $uri @app;
location @app {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_pass http://app;
}
#Specify a charset
charset utf-8;
# Custom 404 page
error_page 404 /404.html;
# Include the basic h5bp config set
include h5bp/basic.conf;
}
Merci pour votre réponse! Commentant ces sections sur travaillé! Je les avais déjà regardés auparavant, mais je pensais que définir un comportement de mise en cache n'aurait aucune incidence sur le fait que nginx ou licorne le servirait. – nsommer
Bienvenue! oui, c'est comme ça que fonctionne Nignx. si un certain 'location' attrape la demande, l'autre' location' ne peut pas le faire après cela (s'il n'est pas déclaré à l'intérieur du premier emplacement, c'est-à-dire "imbriqué") – Curious