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.

  • WordPress upgrade was moderately easy

    ,

    ·

    I recently upgraded my blog to WordPress 2.9.1 and I’m very pleased with the results. The upgrade itself was very straightforward. It was just a matter of replacing the correct files in my project. I have my project checked into GitHub so I was able to immediately see what had changed. I also had a safety net in case I wanted to back out of the upgrade.

    One nice benefit to upgrading was that I’m now able to leverage the Syntax Highlighter plugin. It does nifty stuff like this:

    class HelloWorld
  def say_hello
    puts "Hello world!"
  end
end
HelloWorld.new.say_hello

    If you run a WordPress blog, I would definitely recommend checking it into some sort of source control. Also, being able to run the blog on my development system is very beneficial. I was able to verify that the upgrade hadn’t borked my layout before making everything live. I use Apache to serve it up locally.

    What platform do you use for blogging? What do you like about it?

  • Delete/backspace doesn’t work in nano

    ,

    ·

    If you’ve ever performed a fresh install of Ubuntu, you’ve probably noticed that the delete/backspace key doesn’t work correctly in nano. This is frustrating, but easy enough to fix.

    This problem also occurs quite frequently for me when logging into a remote server. For example, a default Slicehost instance usually suffers from this behavior.

    If you truly want to understand what causes the problem, check out this article.

  • Mass rename files in UNIX

    , ,

    ·

    Several of my Rails projects surface a RESTful API. I use integration tests to verify that the API calls work as expected. I also version my API calls so I can easily adapt the API to new circumstances while maintaining backwards compatibility.

    To move to a new API version, I copy all of the existing integration tests and rename their prefix to the new version. Instead of renaming the files by hand, there is a nifty UNIX command that handles it for me. For example, to rename all the “v2_*.rb” files to “v3_*.rb” I would type:

    for file in *; do mv "$file" "v3_${file#v2_}"; done

  • Radiant can’t load ActiveSupport caching?

    ·

    Are you getting this error message when attempting to deploy your Radiant application?

    no such file to load -- active_support/cache/memory_store

    The fix is simple. Assuming you’re using a vendored copy of Radiant or Rails, you probably have an entry for “cache” in your .gitignore file or your svn:ignore property. Remove it, commit the changes, and deploy again. Bingo!

    Don’t ask me how I know this.