为什么在nginx下使用Passenger会导致Sinatra出现404错误? [英] Why am I getting 404 errors with Sinatra with Passenger under nginx?

问题描述

我有一个基于Sinatra的应用程序，可以在本地正常运行.

I have a Sinatra-based app that runs fine locally.

我将它移动到了带有Passenger的基于Nginx的服务器上，现在我到应用程序/public中文件的所有链接都返回404错误.主应用程序运行后，便可以访问/view中的HAML模板，它们可以正确呈现.文件存在且权限正确；我可以打开和编辑它们，以便知道它们在那里.

I moved it to a nginx-based server with Passenger and now all my links to files in my apps /public are returning 404 errors. The primary app runs, is able to access the HAML templates in /view, which render correctly. The files exist and permissions are correct; I can open and edit them so I know they're there.

在我的HAML模板中，我指的是这样无法访问的文件:

In my HAML templates I'm referring to the files that I can't access like this:

%script{ :src => 'js/jquery.js' }
%link{ "rel" => "stylesheet", "href" => "styles/input.css" }

我的config.ru在尝试查找问题时经历了很多突变.目前，我有:

My config.ru has gone through a lot mutations while I try to find the problem. Currently I have:

require 'sinatra'
require './peering_template.rb'

root_dir = File.dirname(__FILE__)

# disable :run
# set :root, root_dir
# set :views, File.join(File.dirname(__FILE__), 'views')
# set :environment, (ENV['RACK_ENV'] ? ENV['RACK_ENV'].to_sym : :development)

run Sinatra::Application 

该应用程序存在于/home/apps/peering_template中.

网站空间为/home/webapps.

/home/webapps中有一个软链接，如下所示:peering_template -> /home/apps/peering_template/public/.

There is a soft-link in /home/webapps like this: peering_template -> /home/apps/peering_template/public/.

/home/webapps/
`-- peering_template -> /home/apps/peering_template/public/

此配置的nginx.conf相关部分是:

The pertinent part of nginx.conf for this config is:

server {
    listen      3000;
    server_name my_servers_name;
    root        /home/webapps;

    passenger_enabled  on;
    passenger_base_uri /peering_template;
}

很明显，我的服务器名称不同.

Obviously, my server's name is different.

nginx的error.log相关部分如下:

The pertinent part from nginx' error.log is like this:

"/home/webapps/js/jquery.js" failed (2: No such file or directory), request: "GET /js/jquery.js HTTP/1.1"

据我所知，这完全符合"nginx和使用子URI的乘客配置".我想念什么?

As near as I can tell this fits the directions for an "nginx and passenger configuration using sub-URIs". What am I missing?

/home/apps/peering_template/
|-- config.ru
|-- lib
|   |-- bgp-config.rb
|   |-- ios-xr-config.rb
|   |-- ipv4_ipv6_grammar.rb
|   `-- ipv4_ipv6_grammar.treetop
|-- nginx.conf
|-- peering_template.rb
|-- public
|   |-- js
|   |   |-- jquery-1.6.min.js
|   |   |-- jquery-ui-1.8.12.custom.zip
|   |   |-- jquery.js -> jquery-1.6.min.js
|   |   `-- scripts.js
|   |-- peering_template_tool.htm
|   `-- styles
|       `-- input.css
|-- spreadsheets
|   |-- Peering Template-AMS-IX.xlsx
|   `-- Peering Template-IOS-XR-ASH1.xlsx
|-- tmp
|   `-- always_restart.txt
`-- views
    |-- index.haml
    `-- output.haml

我不确定这是否重要，但这是在运行nginx/1.0.0和passenger (3.0.7)的CentOS release 5.3 (Final)主机上.

I'm not sure if it matters but this is on a CentOS release 5.3 (Final) host, running nginx/1.0.0 and passenger (3.0.7).

推荐答案

在我最初写的问题中:

我将它移动到了带有Passenger的基于Nginx的服务器上，现在我所有指向应用程序/public中文件的链接都返回404错误.主应用程序运行，能够访问/view中的HAML模板，它们可以正确呈现.文件存在且权限正确；我可以打开和编辑它们，以便知道它们在那里.

I moved it to a nginx-based server with Passenger and now all my links to files in my apps /public are returning 404 errors. The primary app runs, is able to access the HAML templates in /view, which render correctly. The files exist and permissions are correct; I can open and edit them so I know they're there.

那是我的线索.在我第四次通过乘客文档时，我遇到了讨论/public资产错误的部分:

That was my clue. On my fourth pass or so through the Passenger docs I ran into a section that talked about errors with /public assets:

强烈推荐的第二种方法是始终使用Rails辅助方法来 静态资产的输出标签.这些辅助方法会自动处理 在您已将应用程序部署到的基本URI之前.对于图像 有image_tag，对于JavaScript，有javascript_include_tag，对于CSS 有stylesheet_link_tag.在上面的示例中，您只需删除 HTML标记，并用内联Ruby替换，如下所示:

The second and highly recommended way is to always use Rails helper methods to output tags for static assets. These helper methods automatically take care of prepending the base URI that you’ve deployed the application to. For images there is image_tag, for JavaScript there is javascript_include_tag and for CSS there is stylesheet_link_tag. In the above example you would simply remove the HTML tag and replace it with inline Ruby like this:

因此，这使我为Sinatra寻找类似的帮助程序.我在 Sinatra的扩展页面中找到:

So, that got me searching for similar helpers for Sinatra. I found in Sinatra's extensions page:

sinatra-url-for 构造绝对路径和操作中的完整URL Sinatra应用程序

sinatra-url-for construct absolute paths and full URLs to actions in a Sinatra application

sinatra-static-assets 实现了image_tag，stylesheet_link_tag，javascript_script_tag和link_tag帮助器.这些帮助程序为分派到子URI的应用程序构造正确的绝对路径.

sinatra-static-assets implements image_tag, stylesheet_link_tag, javascript_script_tag and link_tag helpers. These helpers construct correct absolute paths for applications dispatched to sub URI.

那让我搜索了Sinatra的文档，因为它引发了记忆，因此我重新认识了 Sinatra的构建-在网址" 方法中:

And that got me searching Sinatra's docs because it sparked a memory, and I relearned Sinatra's built-in "url" method:

生成URL

Generating URLs

要生成网址，您应该使用url helper方法，例如， 哈姆:

For generating URLs you should use the url helper method, for instance, in Haml:

％a {:href => url('/foo')} foo

%a{:href => url('/foo')} foo

它考虑了反向代理和Rack路由器(如果存在).

It takes reverse proxies and Rack routers into account, if present.

此方法也别名为(示例见下文).

This method is also aliased to to (see below for an example).

通过使用静态资产方法或Sinatra自己的url帮助程序，解决了该问题.

By using the static asset methods, or Sinatra's own url helper it fixed the problem.

这篇关于为什么在nginx下使用Passenger会导致Sinatra出现404错误?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！