2015-09-19 1 views
0

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; 
} 

Répondre

1

Cela se produit parce que vous incluez le fichier h5bp/basic.conf qui comprend à son tour fichier h5bp/location/expires.conf. Jetez un oeil au contenu de ce dernier fichier:

# cache.appcache, your document html and data 
location ~* \.(?:manifest|appcache|html?|xml|json)$ { 
    expires -1; 
    access_log logs/static.log; 
} 

# Feed 
location ~* \.(?:rss|atom)$ { 
    expires 1h; 
    add_header Cache-Control "public"; 
} 

Voir? le premier location intercepte .json demandes, et le second - .rss demandes, de sorte que votre application ne répond jamais à ces demandes.

Si vous voulez que votre application gère ces demandes, vous devez soit refuser h5bp du tout, ou simplement commenter location s. Dans les deux cas, votre application devrait envoyer les en-têtes de cache elle-même, si vous le voulez bien sûr.

Edit:

Mais depuis votre json et rss contenus sont générés dynamiquement, je recommande de ne pas utiliser les en-têtes de cache.

+0

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

+0

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