Lighttpd / FastCGI рассматривает маршруты как статический контент - PullRequest
Новая
       7

Lighttpd / FastCGI рассматривает маршруты как статический контент

0 голосов
/ 18 января 2010

Я столкнулся с разочаровывающей проблемой с FastCGI и Rails, когда lighttpd рассматривает перенаправленные URL-адреса как статические файлы (то есть не отправляет их на rails, поскольку считает, что они статические)

Если я получаю корневой путь, я получаю приложение rails, но как только я сталкиваюсь с чем-то со структурой URL, даже с путем, который совпадает с маршрутом действия по умолчанию: controller /:, я получаю 404 от lighttpd и rails с приложением даже не консультируются.

Вот мой 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 = (...)

Что касается ошибок, то я их вообще не получаю. Хотя, если я включаю отладку в Lighttpd, я вижу такие события: 

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

Есть идеи, что может пойти не так?

1 Ответ

0 голосов
/ 18 января 2010

Немного о том, что есть лицевая сторона, хотя документация не объясняет важность настройки server.error-handler.

При использовании fcgi вы должны убедиться, что ваш обработчик ошибок настроен на перенаправлениев диспетчере fcgi, в противном случае он просто покажет страницу 404. 

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

Все исправлено.

...