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.

  • Agile RTP meetup tonight

    ·

    Remember, this month’s Agile RTP meetup is tonight at 6 PM. I’ll be presenting my Chaotic Agility talk at Misys in North Raleigh. This is a new meeting location (we’re not meeting at Frankie’s anymore) so take note! Here are the directions from the mailing list:

    The address of the building is 8537 Six Fork Rd. Raleigh NC. The name of the building is Forum V. The conference room is #1500.

    This is the building directly beside the main Misys office building and it is located to the north of the water tower. The building is brand new, so it doesn’t show up on most mapping or satellite sites.

    There is plenty of parking in the parking garages surrounding the building.

  • Explore chaotic agility at next month’s Agile RTP meetup

    ,

    ·

    I’ll be speaking about chaotic agility at the Agile RTP meetup in August.

    Chaotic agility is a phrase describing why I believe agility works: the science behind it models an amazingly accurate picture of a typical development project. Most of us will agree that agile teams produce better software on time and for less money. But few of us question why agility works. By better understanding the science behind agility, we will stop trying to manufacture and control software and instead allow it to emerge on its own.

    Note that August’s meetup won’t be at Frankie’s. We’re trying out a new location at Misys Healthcare on Six Forks Road. Visit the meetup site for directions and a more detailed overview of the talk. See you there!

  • Registration for BarCampRDU 2007 is open

    ,

    ·

    Registration for this year’s BarCampRDU is now open. This is an event I unfortunately had to miss last year due to a prior commitment. I’m really looking forward to attending this year. It’s shaping up to be a fantastic experience.

  • No need to check response when testing redirects

    ·

    Early on in my exploration of Rails, I got into the habit of testing that the response code of an action indicated a redirect. It turns out that this check is entirely unnecessary since assert_redirected_to makes an identical check:

    def assert_redirected_to(options = {}, message=nil)
  clean_backtrace do
    assert_response(:redirect, message)
    ...
  end
end

    This is how one of my functional tests might have looked early on:

    def test_index
  get :index
  assert_response :redirect
  assert_redirected_to :action => "list"
end

    This is how the test should be written now:

    def test_index
  get :index
  assert_redirected_to :action => "list"
end

    I recall reading several examples that specifically checked for a :redirect response code before calling assert_redirected_to so it must have been necessary at some point. It’s certainly not necessary anymore. Keep this in mind and save yourself a line or two of code.