Routing problem on apache

I’ve got an application that works fine when run on Brick, but which
throws a routing problem when deployed to apache/fastcgi.

Both servers are running rails 1.2.2

The problem happens with simple links. I’ve got a link_to tag like

<%= link_to "Categories", :controller => "/admin/factory/

category", :action => “list” %>

There is indeed a /admin/factory/category controller, and there is a
‘list’ action. The link works fine with Brick.

However, clicking on the link on the Apache production server gives
this error in the production.log

==> current/log/production.log <==

Processing ApplicationController#index (for at
2007-02-11 15:58:16) [GET]
Session ID: ec28effb4fea482174d1e3ccdb2bba08
Parameters: {}

ActionController::RoutingError (no route found to match “/admin/
factory/category/list” with {:method=>:get}):
action_controller/routing.rb:1292:in recognize_path' /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.13.2/lib/ action_controller/routing.rb:1282:inrecognize’
40:in dispatch' /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/fcgi_handler.rb: 168:inprocess_request’
143:in process_each_request!' /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/fcgi_handler.rb: 109:inwith_signal_handler’
142:in process_each_request!' /usr/local/lib/ruby/site_ruby/1.8/fcgi.rb:600:ineach_cgi’
/usr/local/lib/ruby/site_ruby/1.8/fcgi.rb:597:in each' /usr/local/lib/ruby/site_ruby/1.8/fcgi.rb:597:ineach_cgi’
141:in process_each_request!' /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/fcgi_handler.rb: 55:inprocess!’
25:in `process!’

However, when I try to exercise the same route using console, also on
the production server, there’s no problem:

root@secure [/home/mrs/current]# ruby script/console
Loading production environment.

rs = ActionController::Routing::Routes
=> #<ActionController::Routing::RouteSet:0xb7c22ad8

?> puts rs.routes
ANY /fckeditor/check_spelling/
{:action=>“check_spelling”, :controller=>“fckeditor”}
ANY /fckeditor/command/
{:action=>“command”, :controller=>“fckeditor”}
ANY /fckeditor/upload/
{:action=>“upload”, :controller=>“fckeditor”}
{:action=>“list”, :controller=>“admin/factory/item”}
ANY /:controller/service.wsdl/ {:action=>“wsdl”}
ANY /:controller/:action/:id/ {}
=> nil

rs.recognize_path “/admin/factory/category/list”
=> {:action=>“list”, :controller=>“admin/factory/category”}

I’ve been struggling with this for a couple days, but can’t figure it
out. Any suggestions greatly appreciated.

Thanks: John

I just got an email from someone else with this problem, asking if
I’ve solved it.

Unfortunately, I was not able to find an answer. I ‘solved’ it by
switching to Mongrel. Not a very satisfying solution, but I was
burning up too much time (i.e. money) trying to get Apache/FastCGI

A little more information on this issue…

I woke up thinking… surely this is an orthogonal system, so the
choice of webserver shouldn’t influence the routing.

I had been testing the sofware on two different machines: a test
machine running debian and Brick, and a production machine running RHL
and Apache/FastCGI. Both machines had the same Ruby & Rails versions.
However, I figured there must be some difference in the infrastructure
that causes the routing error on the production machine. And it must
be something lower down in the stack than the webserver, right?

To test this hypothosis, I fired up Brick on the production server. To
my surprise, the routing worked fine!

So it looks like Apache is handing the Rails router something it can’t
handle properly.

Another bit of light: After seeing the above, I switched the rails
version to 1.1.6 (from 1.2.2). This fixed the routing problem on
Apache. Curious, I installed Rails 1.2.1 and tried running the app
under that. 1.2.1 also had the routing problem.

So, it looks like there is an incompatibility between my install of
Apache/Fastcgi and the Rails router in 1.2.1 and above. The app works
fine with Brick on all versions.

Should I just fall back to 1.1.6? I’ve got another commercial
appliation running on the same webserver with 1.1.6 with no problems.
Is 1.2.x not ready for production?

Any ideas, much appreciated.

Thanks: John