{"id":16,"date":"2008-04-05T16:36:33","date_gmt":"2008-04-05T21:36:33","guid":{"rendered":"http:\/\/blog.monnet-usa.com\/?p=16"},"modified":"2008-04-05T16:49:56","modified_gmt":"2008-04-05T21:49:56","slug":"riding-out-of-the-rail-yard","status":"publish","type":"post","link":"https:\/\/blog.monnet-usa.com\/?p=16","title":{"rendered":"Riding out of the rail yard"},"content":{"rendered":"

For the last several months, I have been feeling the pain of shared hosting. My initial Ruby on Rails installation was stuck in the rail yard! Although I had cross-referenced my setup against many rails sites and blogs, I could not seem to get a ruby train out of my rail yard!!! Executing Ruby and CGI-based Ruby programs was fine. But no Rails! You see, my host – even with a business plan – does not let you touch your Apache httpd.conf<\/strong>. My only option is to perform limited configuration using .htaccess<\/strong> files. Moreover, the shared host settings are tucked away from view. Today, after weeks of various research and experiments, I discovered that handlers for CGI and FastCGI seemed to be defined at a high-level in the shared hosting setup. So overriding them seem to wreak havoc and interfere with Rails.<\/p>\n

Here is what I had to do:<\/p>\n

1. Typically a Rails rake-generated .htaccess sets the CGI and FastCGI handlers like so:<\/p>\n

[code]AddHandler fastcgi-script .fcgi
\nAddHandler cgi-script .cgi[\/code]
\nHowever I discovered that for my shared host setup, if I comment the handlers out (or remove them altogether), then the dispatch.fcgi<\/strong> script acting as a front-controller for Rails starts working correctly, i.e. all Apache HTTP variables get passed correctly.<\/p>\n

2. The .htaccess also includes Apache “voodoo” to rewrite your urls and specify that you want urls for your Rails app to be processed by the Ruby on Rails Fast CGI dispatcher. Like so:<\/p>\n

[code]RewriteCond %{REQUEST_FILENAME} !-F
\nRewriteRule ^(.*)$ \/dispatch.fcgi [QSA,L][\/Code]
\nIn plain English, this means: “If a url represents a resource which does not exist as a physical file, then have my Fast CGI dispatcher process the request”.<\/p>\n

Unlike ASP.NET, JSP, PHP or other dynamic web page based apps, a Rails application exposes its features through a multi-level URL domain. Example:<\/p>\n

[html]http:\/\/myapp.myhost.com\/account\/register
\nhttp:\/\/myapp.myhost.com\/account\/updateprofile
\nhttp:\/\/myapp.myhost.com\/blog\/post[\/html]<\/p>\n

In the classic ASP.NET world, specific .aspx pages are created to expose this functionality. Btw Microsoft is now providing a similar approach with the new MVC framework (see http:\/\/www.asp.net\/mvc\/<\/a>).
\nThe shared hosting twist was that a very precise location must be provided for the Fast CGI, i.e. for a subdomain mapped to the public folder in Rails, the root (slash<\/strong>) must be included in front of the name!!! Obvious once you discover that, but oblivious when all examples anywhere never show that!<\/p>\n

[code]RewriteRule ^(.*)$ \/dispatch.fcgi [QSA,L][\/code]<\/p>\n

3. The final step was to remove the dispatch.cgi<\/strong> also generated by rake since I am only using Fast CGI. It seems that keeping it was also interfering.
\nPhew!!! Now navigating to any Rails url works!!!<\/p>\n

Here are a couple useful links worth adding to your del.icio.us collection:<\/p>\n