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


  • Fix for fixture_replacement2 when using default methods

    I’ve been using the excellent fixture_replacement plugin for several months now and greatly prefer it over traditional fixtures (yes, even foxy fixtures). fixture_replacement2 adds even more goodness to the party. However, I ran into a problem today when trying to use default_xxx methods in my example_data.rb file:

    module FixtureReplacement
      attributes_for :course do |c|
        c.name = "Geometry"
        c.transcript = default_transcript
      end
      
      attributes_for :transcript do |e|
        e.name = "Joe's Transcript"
      end
    end
    

    In “fixture_replacement language” this says that new courses should receive a default name of “Geometry” and should also receive a new transcript with a default name of “Joe’s Transcript.” The example above follows the format given in the fixture_replacement README. When I attempt to use this config file in my Rails 2.0.2 project, though, I get this error:

    NameError: undefined local variable or method `default_transcript' for FixtureReplacement:Module
    at top level in example_data.rb at line 7
    ...
    

    Why can’t it find default_transcript? I have no idea. Digging into the source code reveals that default_transcript is added to the FixtureReplacement module at runtime, but for some reason it doesn’t ever show up as being available for calling. I don’t have the time or inclination to dig further, but I did find a workaround by changing:

    c.transcript = default_transcript
    

    to…

    c.transcript = c.default_transcript
    

    This makes fixture_replacement happy and all my tests pass. I submitted a patch so hopefully this wrinkle will be ironed out soon. But this should get you by until then.

  • Vacate room when CFL bulb breaks

    Anyone else think we’re shooting ourselves in the foot on this one? If the choice is between greater power consumption and mercury poisoning, I think I’ll opt for greater consumption, thanks. The more government tries to solve these problems for us, the worse things get. Here’s a novel idea: why don’t we all just start turning off the lights when we leave the room? I know, I know… shocking concept.

  • CSV transmogrifies into FasterCSV in Ruby 1.9

    Matz let Ruby 1.9 into the wild last month. One nice change (among many) is that Ruby’s painfully slow CSV library has been replaced with James Edward Gray II’s most excellent FasterCSV library. This will most likely break existing code that uses CSV.

    From James’ blog:

    The methods provided on the CSV object are similar, but the old CSV code used positional parameters where as the new library user a Hash argument syntax (e.g., :row_sep => "rn"). That’s going to trip up any non-trivial usage.

    He also gave an example of how to write CSV code that interoperates with 1.8 and 1.9:

    require "csv"
    if CSV.const_defined? :Reader
      # use old CSV code here…
    else
      # use FasterCSV style code, but with CSV class, here…
    end
    

    Yes, it’s kind of gross, so just make sure you never have to write it. If you’re going to move to 1.9, move everything and avoid the hassle.

    I’m pretty excited about the performance improvements and other enhancements that have been made in 1.9. This is the first major release of Ruby since I began hacking on it back in the day. It’s a thrill to be part of a community that avoids the “machine gun” approach to releases.

  • visual_effect bug fix in Rails 2.0

    I noticed something interesting while enhancing Teascript today. I recently upgraded the app to Rails 2.0 which ended up breaking several of the Scriptaculous visual effects that I had been using to highlight certain parts of the page when things changed. This is how I had called visual_effect in the past:

    page.visual_effect :highlight, "activities_list", :endcolor => "'#DDDDDD'"
    

    Notice the extra set of single quotes inside the endcolor value. I had to add these single quotes due to a small bug in the Scriptaculous helper. Apparently, the helper didn’t automatically place single quotes around the endcolor value when emitting JS for the page. Well, the good news is that this has been fixed in Rails 2.0, so I was able to update my visual_effect calls to:

    page.visual_effect :highlight, "activities_list", :endcolor => "#DDDDDD"
    

    The bad news is that this change broke Teascript for several days since I initially didn’t notice what was going on. But all is well now, and I’m happy that I don’t have to add those useless single quotes any more.