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.

  • Quote of the Week: Benjamin Franklin

    ·

    “Democracy is two wolves and a lamb voting on what to have for lunch. Liberty is a well-armed lamb contesting the outcome of the vote.” –Benjamin Franklin

  • Quote of the Week: Sherlock Holmes

    ·

    “What object is served by this circle of misery and violence and fear? It must tend to some end, or else our universe is ruled by chance, which is unthinkable.” –Sherlock Holmes, The Cardboard Box

  • Quote of the Week: John Locke

    ·

    “The end of law is not to abolish or restrain, but to preserve and enlarge freedom. For in all the states of created beings capable of law, where there is no law, there is no freedom.” —John Locke

  • Excluding iPads from the mobile-fu Rails plugin

    ·

    mobile-fu is a handy little Rails plugin that automatically detects when mobile devices are accessing your web application and adjusts the request format accordingly. For example:

    Mime::Type.register_alias "text/html", :mobile

class ApplicationController < ActionController::Base
  has_mobile_fu

  def index
    if is_mobile_device?
      render :text => "You're using a mobile device!"
    else
      render :text => "You're not using a mobile device."
    end
  end
end

    mobile-fu even loads any mobile stylesheets you’ve created, including device-specific stylesheets for iPhone, Android, Blackberry, etc. There is also a way to set the mobile flag manually. This comes in handy when you want to test your mobile layouts without actually picking up a device.

    I did find one problem, though: by default, mobile-fu sets the mobile request format for iPads. This probably isn’t the desired behavior for most sites. Mobile Safari does an acceptable job of rendering without the need for specific enhancements on the server side.

    I want my HTML pages to continue rendering on the iPad the same way they do in a desktop browser (at least until I have time to customize a layout specifically for the iPad).

    It’s easy enough to get mobile-fu to do the right thing, though. Simply override the #set_mobile_format method thusly:

    class ApplicationController < ActionController::Base
  has_mobile_fu
  
  # Continue rendering HTML for the iPad (no mobile views yet)
  def set_mobile_format
    is_device?("ipad") ? request.format = :html : super
  end
end

    I also recommend adding the following to your CSS:

    -webkit-appearance: none;

    This prevents the iPad from rendering form controls natively. Native controls tend to break the layout of pages designed for desktop browsers. I’ve found it best to reserve native controls for when I actually build a dedicated iPad-only layout for the site.