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.
