2010-01-18 6 views
0

je suis tombé sur un problème frustrant avec FastCGI et Rails où lighttpd est le traitement routé fichiers statiques d'URL (par exemple ne pas les envoyer aux rails car il croit qu'ils sont statiques)Lighttpd/FastCGI traitement routes comme contenu statique

Si j'atteins le chemin racine, j'obtiens l'application rails, mais dès que j'atteins quelque chose avec une structure URL, même un chemin qui correspond à la route par défaut: controller /: j'obtiens un 404 de lighttpd et l'application rails isn même pas consulté.

Voici mon lighttpd.conf:

server.modules = ("mod_rewrite", "mod_redirect", "mod_access", "mod_status", "mod_fastcgi", "mod_accesslog") 

server.document-root = "/myapp/application/public" 
index-file.names = ("index.html", "dispatch.fcgi") 
server.error-handler-404 = "/myapp/application/public/404.html" 

url.access-deny = ("~", ".inc") 
server.pid-file = "/var/run/lighttpd.pid" 
server.username = "lighttpd" 
server.groupname = "lighttpd" 

server.errorlog = "/var/log/lighttpd/error.log" 
accesslog.filename = "/var/log/lighttpd/access.log" 

#### fastcgi module 
fastcgi.server = (
    ".fcgi" => (
     "myapp" => (
      "socket" => "/tmp/myapp.socket", 
      "bin-path" => "/myapp/application/public/dispatch.fcgi", 
      "check-local" => "disable", 
      "fix-root-scriptname" => "true", 
      "docroot"=>"/" 
     ) 
    ) 
) 

# mimetype mapping 
mimetype.assign = (...) 

En ce qui concerne les erreurs, je ne reçois pas du tout. Bien que, si je tourne le débogage dans Lighttpd, je ne vois des événements comme ceux-ci:

2010-01-18 23:11:18: (response.c.261) URI-path  : /tracking/index 
2010-01-18 23:11:18: (response.c.375) -- before doc_root 
2010-01-18 23:11:18: (response.c.376) Doc-Root  : /myapp/application/tracking/public 
2010-01-18 23:11:18: (response.c.377) Rel-Path  : /tracking/index 
2010-01-18 23:11:18: (response.c.378) Path   : 
2010-01-18 23:11:18: (response.c.426) -- after doc_root 
2010-01-18 23:11:18: (response.c.427) Doc-Root  : /myapp/application/tracking/public 
2010-01-18 23:11:18: (response.c.428) Rel-Path  : /tracking/index 
2010-01-18 23:11:18: (response.c.429) Path   : /myapp/application/tracking/public/tracking/index 
2010-01-18 23:11:18: (response.c.446) -- logical -> physical 
2010-01-18 23:11:18: (response.c.447) Doc-Root  : /myapp/application/tracking/public 
2010-01-18 23:11:18: (response.c.448) Rel-Path  : /tracking/index 
2010-01-18 23:11:18: (response.c.449) Path   : /myapp/application/tracking/public/tracking/index 
2010-01-18 23:11:18: (response.c.466) -- handling physical path 
2010-01-18 23:11:18: (response.c.467) Path   : /myapp/application/tracking/public/tracking/index 
2010-01-18 23:11:18: (response.c.523) -- file not found 
2010-01-18 23:11:18: (response.c.524) Path   : /myapp/application/tracking/public/tracking/index 
2010-01-18 23:11:18: (response.c.205) -- splitting Request-URI 
2010-01-18 23:11:18: (response.c.206) Request-URI : /myapp/application/tracking/public/404.html 

Toutes les idées ce qui pourrait aller mal?

Répondre

0

Bit d'un moment facepalm là bien que la documentation n'explique pas vraiment l'importance du paramètre server.error-handler. Lorsque vous utilisez fcgi, vous devez vous assurer que votre gestionnaire d'erreurs est configuré pour rediriger vers la répartition fcgi, sinon, il affichera simplement une page 404.

server.error-handler-404 = "/dispatch.fcgi" 

Tout est maintenant corrigé.

+0

Notez que lorsque vous utilisez "server.error-handler-N", vous traitez les pages d'erreur comme des requêtes entièrement qualifiées. Ils retournent le code "200" à toutes les demandes. Pour être en mesure de renvoyer des pages avec des codes d'erreur par valeur correcte, vous devez utiliser "server.errorfile-prefix", où vous déclarez un dossier avec des fichiers html avec les numéros d'erreur comme noms de fichiers ("404.html"). – user1254893

Questions connexes