Matthew Bass

  • CORS woes on Heroku

    ,

    After spending the past 4 hours attempting to solve what boiled down to a rather simple problem, I figure I’d better blog about it to save someone else the time and effort.

    If you’ve been leveraging Passenger’s new –nginx-config-template command line option to add CORS headers to static assets served from a Rails app hosted on Heroku, and the CORS headers recently disappeared under mysterious circumstances… read on.

    I’ve been using the method described here to add CORS headers to custom fonts served from a Heroku-hosted Rails app that’s proxied by Nginx which handles serving static files. I recently updated to Rails 4.2.2 and suddenly, my custom fonts (.woff and .woff2 files) no longer had CORS headers on them.

    After the aforementioned hours spent scratching my head, I discovered that the latest version of the sprockets gem is generating asset digests that are 64 chars in length, where previously they had been 32. Nginx’s default regexp for identifying requests for static assets assumes the digest will be 32 chars long, like so:

    # Rails asset pipeline support.
location ~ "^/assets/.+-[0-9a-f]{32}\..+" {
  error_page 490 = @static_asset;
  error_page 491 = @dynamic_request;
  recursive_error_pages on;</code>

  if (-f $request_filename) {
    return 490;
  }
  if (!-f $request_filename) {
    return 491;
  }
}

    Changing the regexp to recognize digests that are 64 chars in length immediately solved the problem:

    location ~ "^/assets/.+-[0-9a-f]{64}\..+" {
   ...
}

    I had to laugh after something so stupid and silly cost me a good chunk of my Saturday to debug. But at least it’s working now. My statically served custom fonts have the correct CORS headers and Chrome and Firefox are happy again.

Need help?

I’m an independent software developer available for consulting, contract work, or training. Contact me if you’re interested.

  • Thanks for reading!

    ·

    July 29th will mark the fifth anniversary of this blog. I realized today that I have never properly thanked you, my readers, for continuing to support this endeavor. There are so many other things you could be perusing, but you choose to patronize my humble programming blog. For that, I am grateful. Thanks for reading!

  • RubyConf in New Orleans

    ·

    This year’s RubyConf is being held in New Orleans on November 11th – 13th.

    Count me in.

    I’ve only driven through the area once so it’ll be interesting to make a longer visit. Although I’m ultimately keeping my fingers crossed for a Raleigh RubyConf one of these days. Hey, I can dream.

  • Rails 2.3.8 – an embarrassing trip

    ·

    November 30, 2009: Rails 2.3.5 has just been released. I upgrade my production Rails apps and rock on.

    February 17 of this year: RubyGems 1.3.6 is released and my apps begin suffering from deprecation warnings. They’re all over the place: when I run a test, when I launch script/console… when I sneeze.

    /Users/pelargir/Projects/teascript/config/../vendor/rails/railties/lib/rails/gem_dependency.rb:119:Warning: Gem::Dependency#version_requirements is deprecated and will be removed on or after August 2010.  Use #requirement

    Rumor has it the deprecation warning will go away with 2.3.6. And 2.3.6 is expected to drop any day. Yay! Problem will be solved soon… or so I thought. I begin waiting.

    May 23: 2.3.6 finally drops.
    May 24: 2.3.7 drops because of a bug in 2.3.6. What the heck?
    May 25: 2.3.8 drops because of a bug in 2.3.7. Okay, this is getting crazy.

    Was anyone else embarrassed about the 6-month delay for 2.3.6 followed by two more point releases over the span of three days? This is exactly the kind of anecdote an exec at a Fortune 500 would raise to prevent a move towards Rails and keep the company locked into Java or .NET for another decade. Ugh.

    We can do better than this.

  • Quick ‘n dirty Lindo step for Cucumber

    ,

    ·

    Lindo is great for verifying your Rails tests by opening the HTTP response body in a browser for inspection. It works with most popular testing frameworks including Test::Unit and RSpec. But what about Cucumber?

    It’s actually pretty easy to build a custom Cucumber step that triggers Lindo from your cukes. First, install the Lindo gem in your Rails app. Then create features/steps/lindo_steps.rb and insert this code:

    Then /^render the current page$/ do
  extend Lindo
  vr
end

    The step can be named whatever you like best, but “render the current page” works for me. To trigger Lindo from within your cukes, simply reference the step like so:

    Given I am logged in
When I follow "some link"
Then render the current page

    When Cucumber hits the last step, the default browser window will open and the contents of the page at that step in the scenario will be displayed. This is very handy when troubleshooting why a specific scenario is failing. It’s also useful for determining what you should be testing for on a given page.