Last Friday, around quitting time, fellow Coupa developer Ted and I were pairing up on some tickets and decided to attack one last issue before calling it a night. The ticket we landed on was one I had banged my head against for a few hours and only found dead ends. Even worse, it was a total show-stopper. Anyone using only our new Expensing application who clicks on the homepage navigation link in IE7 (which the majority of our customers use) is not directed to our home page – surprise! Instead they are prompted with a “File Download – Security Warning” dialog box and some text about “Type: Unknown File Type”. How bizarre! Clearly IE7 had no idea what to do with the response it received from our server. I clicked save from the prompt and examined the file download. It was our homepage, in all of its HTMLy wonder, now sitting alone and unrendered on the desktop.
My first thought had been – mime type! Having no way to evaluate response headers in IE, I took a shot in the dark and opened up Firebug. Unfortunately nothing was out of the ordinary. This wasn’t terribly surprising given that it does work in Firefox, but I suppose it had been worth a shot. Next I googled around and found that a similar issue exists (websites showing a download prompt instead of rendering in IE7) as a result of having Google Desktop Search installed and active. We don’t have that app (or much at all) installed on our IE-testing box, but whatever interaction had caused that sounded quite frightening. My mind was racing – could an unrelated process on this box be causing this link to download as a file? I calmed down a little when I remembered our QA team had reproduced this first on a different box. On a whim I tried manually appending the “.html” in the URL and – viola – the homepage rendered like a champ. At least I had a way to hack in a solution if I had to, but it was far from ideal.
This time what made the difference was a casual suggestion from Ted to use DebugBar to analyze the request/response Headers. I hadn’t heard of this tool but installed it immediately. A browser restart later I had it open, had reloaded the page and opened up the request and response headers. It was crazy – IE7 was asking for a jpeg (what?!) and we were responding with HTML but saying it was javascript (why!?). With that clue google quickly yielded this post from Hemant Khemani’s blog which clearly describes the exact problem we were having as well as the solution. Essentially IE was requesting a Content-Type of “images/jpeg”, which was not defined in our respond_to do block, so Rails chose our default format – which happens to be the first one you specify.
So the fix was simply to replace:
| 3 | format.html {render :template => 'user/expense_only_home'} |
With:
| 2 | format.html {render :template => 'user/expense_only_home'} |
This ensures that your default response header will be HTML. And from now on I will be checking that all of our respond_to blocks for this specific kind of sanity. So in the end, in about 20 minutes we had solved a problem I had previously struggled with for hours and all but given up on. A definite win for pair programming, for DebugBar and for my weekend.
