Feeds:
Posts
Comments

Archive for November, 2010

In a previous post, I covered one situation in which Internet Explorer breaks the Rails respond_to method. But other situations, specifically respond_to blocks that differentiated between HTML and PDF, seemed safe. Now that appears to be broken, too.

A client of mine has a Ruby on Rails application (Rails 2.3.8) with just over 4,000 users. Up until last week, the following respond_to block worked fine:

    respond_to do |format|
      format.html { render(:show) }
      format.pdf do
        render(:pdf => @document.title,
                  :template => 'documents/show.html.haml',
                  :stylesheets => ['main', 'print', 'prince'])
      end
    end

On 21 October 2010, a new user joined the system and started receiving the PDF version instead of the HTML version even though the URL omitted an explicit format. That is, the user clicked a link to http://example.com/documents/1234, but was still delivered a PDF. The user was browsing with Internet Explorer. I can’t reproduce the problem, and no other IE users of our system have reported this problem, but I presume the user’s version of IE is explicitly listing “application/pdf” in its HTTP_ACCEPT header, which gives priority to PDF over HTML, which is not explicitly listed (“*/*” at the end of the list catches HTML).

If it takes 4,000+ users to discover that respond_to doesn’t work in a particular situation, it makes it very difficult to know when one can trust respond_to to work and when not. Will it start breaking for JSON next because somebody installs some clever plugin on IE that makes IE prefer JSON over HTML? I hope not.

In order to solve this for PDFs, it looks like I’m going to break out .pdf into its own case just as I did for .doc and .xls.

Read Full Post »