Sounds like outside of rails is the way to go. I shall take the advice and start cooking up some rewrite recipes..
You definitely want to move legacy URLs into mod_rewrite. Two compelling reasons to do so.
(1) mod_rewrite has better URL mangling and filtering capabilities. You can make the final target use a different host name, port, or URL prefix. You could even get fancy and do some proxying or tunnelling if you had to.
(2) It keeps your Rails App clean. That means you can more easily redeploy the Rails App on other servers (IIS, Apache, Lighttpd, etc) or Ruby containers (Ruby, Jruby, IronRuby). If you put the legacy routes into routes.rb, you'll have a lot more to regression-test if you decide to switch servers or containers.
url rewriting (in apache in your case) is the better option IMHO. It would be much faster than the rails routes counterpart.
Yeha I'd have to agree. I think I heard that routing in Rails was always the weakest performance link. I have legacy routes handled by nginx at it seems to work just dandy. And I feel comfortable in the fact that my app doesn't have to deal with the added traffic.
I have a rather large web app to deploy that was originally 3 websites with lots of random php scripts. In order to keep the current urls working, I'm going to end up with a lot of routes or a lot of apache rewrites. Which is faster? (I remember hearing at one point about a lot of entries in routes.rb slowing things down but that being fixed in the current edge rails, but can't seem to find any text about that)
routes.rb would be things like:
map.resouces :events map.connect 'event.php?id=:id', :controller => 'events', :action => 'show'
and so on.. and on..
Would all those map.connects do better in mod_rewrite even though the request is still going to hit the rails app?