Mongrel, rails and the theory of relativity

Summary (E = mc²)

When using mongrel for rails and you want to deploy an app under /other_url then use

    ActionController::AbstractRequest.relative_url_root = "/other_url"

in config/environments/production.rb instead of

    ENV['RAILS_RELATIVE_URL_ROOT'] = "/other_url"

Proof (From first principals)

At Vquence we have a pretty standard rails setup

  • Apache with mod_proxy
  • pen
  • mongrel

Silvia recently wrote an application to allow us to edit the news articles posted to our corporate website. I wanted to do something I thought would be pretty simple, have the application appear at /news on our admin web server.

Step one was the obvious change to mod_proxy

    ProxyPass /news http://localhost:8000
    ProxyPassReverse /news http://localhost:8000

Of course the problem is that the rails app still thinks it is living on / so it returns URLs like /stylesheets/moo.css instead of /news/stylesheets/moo.css.

A bit of googling found a few email threads with a common solution. In your environment.rb set

    ENV['RAILS_RELATIVE_URL_ROOT'] = "/other_url"

This is where things fell apart fairly quickly. I could not get this to work no matter what I tried. After a few hours of following a HTTP request through the whole Mongrel and rails stack I discovered the following.

Setting RAILS_RELATIVE_ROOT will work fine if you are running rails using CGI. For the simple reason, which should have been more obvious to me sooner, that CGIs use environment variables to access their parameters. This can be seen in the
ruby CGI class

/usr/lib/ruby/1.8/cgi.rb:


class CGI

def env_table
    ENV
end

However mongrel overloads env_table and does the following instead

/usr/lib/ruby/1.8/mongrel/cgi.rb:


class CGIWrapper < ::CGI

    # Used to wrap the normal env_table variable used inside CGI.
    def env_table
        @request.params
    end

This makes sense since the rails code is now running inside the web server so environment variables aren’t necessary. Upon investigation I found that the URL morphing magic is performed with rails as follows.

/usr/share/rails/actionpack/lib/action_controller/request.rb:


  class AbstractRequest
    cattr_accessor :relative_url_root
    
    # Returns the path minus the web server relative installation directory.
    # This can be set with the environment variable RAILS_RELATIVE_URL_ROOT.
    # It can be automatically extracted for Apache setups. If the server is not
    # Apache, this method returns an empty string.
    def relative_url_root
      @@relative_url_root ||= case
        when @env["RAILS_RELATIVE_URL_ROOT"]
          @env["RAILS_RELATIVE_URL_ROOT"]
        when server_software == 'apache'
          @env["SCRIPT_NAME"].to_s.sub(//dispatch.(fcgi|rb|cgi)$/, '')
        else
          ''
      end
    end

What this all means is that you can solve the whole problem by placing the following in your config/environments/production.rb

    ActionController::AbstractRequest.relative_url_root = "/other_url"

Now if only Einstein had put his theories to good use and invented a time machine then maybe I could get the last 4 hours of my life back 🙂

Update: Make sure /other_url isn’t the same name as one of your controllers or bad things happen.

5 Replies to “Mongrel, rails and the theory of relativity”

  1. Thanks. I read elsewhere to put this in environment.rb but I could not figure out how to not have to alter my development setup to accommodate this change. Seems pretty obvious now to put it in production.rb.

    But I do have another issue to point out. relative_url_root was not able to handle my CSS file’s use of an absolute path, like so:

    background-image: url(/images/bg_image.jpg);

    So, my background image no longer appears because it’s not able to actually find it in /other_url/images/bg_image.jpg.

    Were you able to find a workaround?

  2. To solve the problem with static resources I just made all the references relative. So background-image: url(/images/bg_image.jpg); becomes background-image url(../images/bg_image.jpg); assuming that the ‘images’ directory is at the same level as your ‘stylesheet’ directory.

  3. Hi!

    I do it and works perfect!
    But, I get some trouble with ImageMagick and Gruff.
    When I write a file, I get a error “Permission denied”.

    “Magick::ImageMagickError (unable to open image `classificacao.png’: Permission denied):”

    Apparently, this write in a different folder.

    Do you have some idea about this?

    tks!

    1. @marcelo: I’m not familiar with the gruff plugin but it sounds like it’s trying to write the image to disk before it sends it out. It sounds like you need to make the directory it’s writing the files to writable by the webserver.

Leave a Reply

Your email address will not be published. Required fields are marked *