The tale of E

The File won’t download in IE !!

The other day I faced a tricky issue , a tester for my application raised this bug , If he tried to download a file , It’ll download fine in Chrome and Firefox , but the file just opened up in Internet Explorer .

A little backstory . Our application was migrating our document store , the developers of the new document store had given us some restful APIs to integrate in our application ( We do some internal validations and then upload/download the file to/from the document store ). I was the guy entrusted with the task of consuming these APIs and so I did that.

Now during the testing phase everything was working fine until people decided to test the application on IE .They will put the download url in the address bar and hit enter and voila , the file just displays itself in the browser instead of showing a download dialog .

So here I was cursing Microsoft and IE for this issue I was facing . By evening I had tried numerous things ,checking where IE is storing temp file , staring at dev tools console for a clue , blaming the UI folks for doing some unnecessary magic , praying to gods ( both old and new and even R’hllor as well ) …. But everything went in vain ( By this time I had reached fourth page in google search results and all the links had turned purple ).

Night fell and I went home completely exhausted and frustrated beyond my limits . Ate something and decided to take a nap ( Pro tip — whenever in doubt take a nap , benzene structure was discovered this way :P )

Woke up and had an idea to do my routine check , whenever things don’t work I just try and emulate the behavior locally , kinda trying to isolate the problem . So I quickly fired up a local Apache Tomcat server and wrote a simple java servlet code. To read a file from file system and flush it to browser . Tested in all three browsers and it worked !!

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

InputStream inputStream = new FileInputStream(“C:/DownloadTest.png”);

response.setHeader(“Content-Disposition”,”attachment;filename=\”DownloadTest.png\””);

ServletOutputStream outputStream = response.getOutputStream();

IOUtils.copy(inputStream, outputStream);

outputStream.flush();

}

So by now one thing was clear it was not IE’s fault ( sorry Microsoft ) , there was something fishy going either from my or the other team’s ( document store developers) end.

So added a little more code to fetch the Inputstream from document store ( instead of reading from the file system ) and flushing it to the browser . Guess what it worked in all the browsers !!

I was like

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

HttpClient client = HttpClients.createDefault();

HttpGet get = new HttpGet(url);

HttpResponse httpResponse =client.execute(get);

HttpEntity entity = httpResponse.getEntity();

InputStream inputStream = entity.getContent();

response.setHeader(“Content-Disposition”,”attachment;filename=\”DownloadTest.png\””);

ServletOutputStream outputStream = response.getOutputStream();

IOUtils.copy(inputStream, outputStream);

outputStream.flush();

}

Now this made me move in a different direction altogether . Now I thought there was something wrong going at the server end .

Day 2 :

So after numerous log statements and configuration changes , I was still pulling my hair . And the fact that each deployment used to take 10–15 min didn’t help . I would make a small change ,push the code and wait for deployment to be over only to realize the past half an hour’s effort was useless .

At the peak of my frustration , I decided to scrape the ‘ Content-Disposition ’ header* I was getting in response from document store and extracted the filename from it . Using the filename I created the Content-Disposition header again , before flushing the file from sevlet outputstream . It worked !

I was like WTF !! a stupid redundancy in the code made it work , how ?? So printed the values of both headers one after the other ( the one which was working and one which I was getting in response from document store and passing blindly ) .

Ohh the horror , If I could find the guy who had written this api , I would have punched him . An ‘ e ’ , an extra f**king ‘ e ’ was the culprit behind 2 days of frustration .

And yeah thanks IE for being a Grammar Nazi .

Finally closed the bug , the redundancy is still there in code , working fine in production . Asked the API dev to fix his typo , but still not taking any chances .

So there you go , a stupid typo which caused me a sleepless night and two days of frustration .

Thus ends the tale of E

• Content-Disposition header — “If this header is used in a response with the application/octet- stream content-type, the implied suggestion is that the user agent should not display the response, but directly enter a `save response as…’ dialog. “
  (Read https://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html for more info ) .