The plain HTTP request was sent to HTTPS port

I was receiving the error “The plain HTTP request was sent to HTTPS port” error”, Nginx error 400.  The problem was a an Nginx configuration error.  I found the solution in this StackOverflow question.  In the config file with your server info (mine was in /etc/nginx/sites-enabled/default):

make these changes:

listen 80;
  listen 443 default ssl;

  # ssl on   - remember to comment this out


Infinite Loop with Force_SSL

I ran into an issue where I keep getting infinite loops on views with force_ssl.  I’m using Nginx and found that I needed to adjust the config.

For me the settings were in /etc/nginx/sites-enabled/default.

I needed to add this in the @location part:

proxy_set_header X_FORWARDED_PROTO $scheme;

Here's how my file ended up looking:

server {
    listen   443;
    ssl on;
    ssl_certificate     /etc/ssl/xyz.crt;
    listen   80;
    root /home/rails/public;
    server_name _;
    index index.htm index.html;

    location / {
            try_files $uri/index.html $uri.html $uri @app;

#       location ~* ^.+\.     (jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rt    f|js|mp3|flv|mpeg|avi)$ {
location ~* ^.+\.    (jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|mp    3|flv|mpeg|avi)$ {
                    try_files $uri @app;

     location @app {
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header Host $http_host;
            proxy_redirect off;
            proxy_pass http://app_server;
            proxy_set_header X_FORWARDED_PROTO $scheme;

Expiring Specific Cache Keys from Rails Console

I wanted to learn how to delete only certain keys from the Rails cache from the console.  Previously when I wanted to do this, I was having to delete my entire cache.

The answer I found was simple – just enter this command into the Rails console, replacing key with your key name:


Expiring Cache on Rails Using Jobs

I needed to expire caches using jobs.  If I used an observer or a sweeper the updates would happen to often.  I was displaying the info of a bunch of records (foobars) on a single view and I didn’t want it to update every time a Foobar was created – that would be too often and reduce the benefits of caching.

Instead I wanted a job that ran every hour to expire the cache.

  1. First, I installed the Whenever gem which updates the cron file and helping you schedule server jobs.
  2. use the command `wheneverize .` to generate the schedule.rb file for Whenever
  3. I created a new rake file, “expire_cache.rake” in lib/tasks
  4. In the file, I put this:task :expire_cache_1_hour => :environment do
    puts “———————expiring 1 hour cache————-”“foobar”)  #I already had <% cache(‘foobar’) do %> in my view
  5. In the schedule.rb file used by Whenever, I added:every 1.hour do
    rake “expire_cache_1_hour”

Silencing Asset Pipeline Details in Rails Logs

The asset pipeline details can get quite extensive in Rails logging and since the details you are analyzing typically are not related to the loading of assets, you may want to silence them, or prevent them from logging – especially since you can always turn logging back on if you run into asset troubles.

I’ve found three ways to do so:

  1. you can use the Quiet Assets gem

These other two were mentioned on Stack Overflow, but I was not able to get them to work:

  1. you can add this as an initializer in config/initializers/quiet_assets.rb:
if Rails.env.development?
  Rails.application.assets.logger ='/dev/null')
  Rails::Rack::Logger.class_eval do
    def call_with_quiet_assets(env)
      previous_level = Rails.logger.level
      Rails.logger.level = Logger::ERROR if env['PATH_INFO'] =~ %r{^/assets/}
      Rails.logger.level = previous_level
    alias_method_chain :call, :quiet_assets

3.  if you are using Rails 3.2 or above, you can include this setting in config/environments/development.rb:

config.assets.logger = false

Load Testing

I started load testing my app using pretty awesome, as you can volume test for free in minutes, at any time.

Unfortunately for me, the app’s default for it’s blitz expects a response in 1 second, but many of my views aren’t there yet.

so I have to use the

-T 10000 command (before the url) a lot more than I like.  It extends the default response time to expect.

Getting Thin Gem to Work on Heroku When you Develop in Windows

Upgrading to Heroku’s Cedar stack, I had to install the Thin gem to prevent my app from running on Web Brick.  On the Bamboo stack this is injected so I need not worry, but with Cedar you need to install all the gems you need.

The problem is that I work on Windows in development and that one of the dependencies for the Thin gem is the Eventmachine gem.  However, Eventmachine isn’t really geared towards Windows environments (except gem install eventmachine –pre), so everytime went to run bundle install the install would fail because the dependency, eventmachine 0.12.10 could not install.

However, Heroku helped me find a solution.

Add this to the gemfile

group :production do
gem ‘thin’

and instead of ‘bundle install’, run ‘bundle install –without production’

Caching Rails 3 on Heroku

To learn about caching, I used a few different resources.

The three basic types of caching are:

  • page caching – mainly for static pages, it will not work if any filters are applied to the controller of the page (ie authorizations)
  • action caching – typically what you’d used to cache a page if they have filters
  • fragment caching – allows for caching of blocks of html on a page (if you can’t cache the whole page) or for partials

Since I’m on Heroku, the first place to learn was Heroku’s documentation.  It’s important to read the Heroku docs first because some standard Rails functions work differently on Heroku’ platform.  Mainly, for page caching (uses different syntax than standard rails) and action caching (mostly dependent on memcache, so you need to set your app up accordingly).

Overview of caching on Heroku

There’s also a Rails Guide on Caching (just remember to ignore page caching part):

However, the most extensive (and useful) one for me was from Adam Hawkins at (especially for fragment caching):

I also needed to learn about sweepers, in order to observe for changes that would impact another controller’s pages.  This Stack Overflow post helped me learn to put the sweeper in with the models and to ensure that I updated the correct controller: