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?
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