Rails 3 mostra erro 404 em vez de index.html (nginx + unicornio)

1

Eu tenho um index.html em public / que deve ser carregado por padrão, mas eu recebo um erro 404 quando tento acessar link

The page you were looking for doesn't exist.

You may have mistyped the address or the page may have moved.

Isso tem algo a ver com nginx e unicórnio que estou usando para ativar Rails 3

Quando retirar o unicórnio do arquivo de configuração nginx, o problema desaparece e index.html carrega muito bem.

Aqui está o meu arquivo de configuração nginx :

upstream unicorn {
    server unix:/tmp/.sock fail_timeout=0;
}

server {
    server_name example.com;
    root /www/example.com/current/public;
    index index.html;

    keepalive_timeout 5;

    location / {
        try_files $uri @unicorn;
    }

    location @unicorn {
        proxy_pass http://unicorn;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $host;
        proxy_redirect off;
    }
}

Meu config / routes.rb está praticamente vazio:

Advertise::Application.routes.draw do |map|
  resources :users
end

O arquivo index.html está localizado em public / index.html e carrega bem se eu solicitar diretamente: link

Para reiterar, quando removo todas as referências a unicorn do nginx conf, index.html carrega sem nenhum problema, é difícil entender por que isso ocorre porque o nginx deve estar tentando carregar o arquivo por conta própria por padrão.

-

Aqui está a pilha de erros de production.log:

Started GET "/" for 68.107.80.21 at 2010-08-08 12:06:29 -0700
  Processing by HomeController#index as HTML
Completed   in 1ms

ActionView::MissingTemplate (Missing template home/index with {:handlers=>[:erb, :rjs, :builder, :rhtml, :rxml, :haml], :formats=>[:html], :locale=>[:en, :en]} in view paths
"/www/example.com/releases/20100808170224/app/views", 
"/www/example.com/releases/20100808170224/vendor/plugins/paperclip/app/views", 
"/www/example.com/releases/20100808170224/vendor/plugins/haml/app/views"):
/usr/local/rvm/gems/ruby-1.9.2-rc2/gems/actionpack-3.0.0.beta4/lib/action_view/paths.rb:14:in 'find'
  /usr/local/rvm/gems/ruby-1.9.2-rc2/gems/actionpack-3.0.0.beta4/lib/action_view/lookup_context.rb:79:in 'find'
  /usr/local/rvm/gems/ruby-1.9.2-rc2/gems/actionpack-3.0.0.beta4/lib/action_view/base.rb:186:in 'find_template'
  /usr/local/rvm/gems/ruby-1.9.2-rc2/gems/actionpack-3.0.0.beta4/lib/action_view/render/rendering.rb:45:in '_determine_template'
  /usr/local/rvm/gems/ruby-1.9.2-rc2/gems/actionpack-3.0.0.beta4/lib/action_view/render/rendering.rb:23:in 'render'
  /usr/local/rvm/gems/ruby-1.9.2-rc2/gems/haml-3.0.15/lib/haml/helpers/action_view_mods.rb:13:in 'render_with_haml'
  etc...

-

O log de erros do nginx para este virtualhost aparece vazio:

2010/08/08 12:40:22 [info] 3118#0: *1 client 68.107.80.21 closed keepalive connection

Meu palpite é que unicorn está interceptando o pedido para index.html antes que o nginx consiga processá-lo.

    
por Miko 08.08.2010 / 21:04

3 respostas

1

O Rails 3 não oferece recursos estáticos por padrão. Você tem que configurar seu servidor web para servir o servidor público ou adicionar

config.serve_static_assets = true

para o seu ambiente de produção link

    
por 12.01.2011 / 16:17
1

Isso parece funcionar. Eu tive que editar o arquivo de configuração do nginx: /etc/nginx/servers/appname.conf

location / {
  ...stuff...

  # check for index.html for directory index
  # if its there on the filesystem then rewite 
  # the url to add /index.html to the end of it
  # and then break to send it to the next config rules.
  if (-f $request_filename/index.html) {
    rewrite (.*) $1/index.html break;
  }

  ...other stuff..

}

Usar config.serve_static_assets = true só resultou em cerca de metade das solicitações por segundo, conforme eu obtenho depois de adicionar isso e ter config.serve_static_assets = false

    
por 16.04.2011 / 08:06
1

O problema está aqui:

    try_files $uri @unicorn;

Isso deve ser:

    try_files $uri $uri/ @unicorn;

O que também elimina a necessidade de usar um if maligno e não requer que você tenha o Rails para servir arquivos estáticos (o que é lento).

    
por 26.11.2012 / 23:27