a timocracy of one

Since HTTP redirects are required to be fully qualified absolute paths, rails prefixes the host and protocol. And if you are using named routes _path, which returns non qualified paths, so it just checks what that protocol of the request is, and uses that. This is fine, unless you are serving https:// and you are operating from behind a proxy, in which case rails can’t know the original request was ssl so it prefixes the redirects with http:// . As a fix for that the core team added a check for the “X_FORWARDED_PROTO” header which you can add in your proxy – if you are running Apache 2.

If you are on Apache 1.3 there is no way to do this (RequestHeader is an Apache 2 only feature), so you are kinda stuck. On top of this, if you try using the spiffy ssl_requirement plug-in to enforce ssl where you want, the request will get caught in a looping redirect, since it will never know that the page is already being served up on https.

Jamis Buck wrote a work-around for serving some actions as ssl, but I wanted a simple way to have my whole site work under ssl. After digging around through the rails code, I realized you could just override the ssl? check on the request and force it to true. Of course, the request has to exist already, so I did it in a before filter.

class ApplicationController < ActionController::Base
  before_filter :set_ssl

  private
  def set_ssl;
    def request.ssl?; true; end
  end
end

You still have to set-up Apache to not serve up non-ssl, since there is no way for rails to tell the difference, but this will cause all your redirect_tos to use https://, which is the tricky part, since it’s easy to make everything else use path_only links.

I’m going to see what the boards think about honoring default_url_option[:protocol] on redirect_to(string) to obselete this, but I’ll upate if that happens.

*Or any other non fully-qualified redirecting, such as redirecting back to an original requested page, after a login, based on request_uri)