Java Servlet Mimetype and Internet Explorer mimetype handling bug

Question

I have a servlet that may return text/html or application/pdf content. Apparently, it looks like Internet Explorer (IE7) does not handle the application/pdf correctly.

For example. Servlet Output A may return html content:

[html content here]

And then Servlet Output B may return PDF content:

[pdf content here]

The URL associated with these outputs are the same Servlet URL: http://web/Servlet

Reading online, it looks like IE may have a buggy mechanism and not trusting the mimetype/content type that is set from the server. Mainly, I am having an issue under Internet Explorer where I output the PDF but for some reason IE reverts the content type to text/html and I get a blank html page.

Here is a quote on the issue:

"Now there is still another bug lurking even where the PDF servlet is fixed to set the MIME type of the response as application/pdf. If no results were found, then response sent this information back to the client using HTML! Now because of IE's MIME type shenanigans, the response would get displayed using a text/html MIME type. However most other browsers will trust the application/pdf MIME type sent from the server"

In Firefox with the same Servlet, I don't get this issue.

In the java code, I am essentially setting these response header values:

Expires=0
Cache-Control=max-age=1, must-revalidate, no-cache, post-check=0, pre-check=0
Pragma=public
Content-Disposition=inline; filename=filename_1257804404940.pdf
Content-Length=457834
Connection=Keep-Alive
Content-Type=application/pdf
Content-Language=en-US

Above is the output from firefox. Under IE, I may get:

Content-Length=0
Connection=Keep-Alive
Content-Type=text/html
Content-Language=en-US

Even though the code is the same. Here is my question, how can I avoid this problem?

Answer 1

We had similar problems at work. You can twist the browser's arm by including a file name with the proper extension in the URL you go to.

If you have a HTML serving servlet and one that does PDF, this is obviously no problem; just map different URLs to them.

If the type is determined at runtime, you can kludge-solve the problem by defaulting to HTML and returning a document with a meta redirect to the PDF URL if that's needed.