• 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.


  • BarCampRDU 2009 registration now open

    The date and venue for BarCamp RDU 2009 have been decided upon and registration is now open. Register early to ensure you have a seat. This is the fourth year of BarCamp and it just keeps getting better every year. The variety and quality of presentations last year was incredible. The price of admission (free) is certainly nothing to balk at. I’ve really enjoyed attending in past years. This is a great learning and networking opportunity so be sure to mark your calendars for August 8th. See you there!

  • rspec’s route_for breaks when upgrading Rails

    Came across this interesting test failure after upgrading a project to Rails 2.2.2 earlier today:

    should route users's 'destroy' action correctly
    
    The recognized options <{"action"=>"show", "id"=>"1",
    "controller"=>"users"}> did not match <{"action"=>"destroy", "id"=>"1",
    "controller"=>"users"}>, difference: <{"action"=>"destroy"}>
    

    Turns out that rspec’s route_for method behaves differently when run against Rails 2.2+ due to the routing changes. The controller in question is setup as a resource, so the “destroy” action must be called via an HTTP DELETE, not a GET.

    The failing line in the test looked like this:

    route_for(:controller => 'users', :action => 'destroy', :id => 1).should == '/users/1'
    

    The fix was simple enough:

    route_for(:controller => 'users', :action => 'destroy', :id => 1).should == {:path => '/users/1', :method => :delete}
    

    Hope this helps anyone who is experiencing the same problem.

  • Looking for a good developer?

    I’m in between projects right now and looking for some work to get me through the next month or so. Are you looking for a top-notch Ruby, Rails, or Java developer for your project? Drop me an email and let’s talk.

  • An average day

    The hard drive died in the MythTV at my parents’ house today. Bad.

    The 4GB memory upgrade from Crucial for my MacBook arrived today. Good.

    These two things average out. Meh.