Remove http header using java servlet api

Question

We are using IBM Websphere Application Server 6.1 and browser is Internet Explorer 8.

We have a java servlet which dynamically generates PDF and MS Word documents. On the first attempt some users are saying they are getting

"Internet Explorer was unable to open this site. The requested site is either unavailable or cannot be found. Please try again later."

As per Microsoft Support article id 323308
When you try to open a Microsoft Office document or a PDF document over HTTPS (SSL) IE fails with above error message. This issue occurs if the server sends a "Cache-control:no-store" header or sends a "Cache-control:no-cache" header. For IE8 Microsoft suggests to add registry entry on users Windows XP desktop. This is not very practical for us to do as we don't control our users desktops. This does not happen for IE9, Firefox, Chrome, etc.

As per PK20531 WAS 6.1 is adding Cache-Control: no-cache="set-cookie, set-cookie2" and Expires HTTP headers when there is cookie being set in the response.

Note - We are not setting the cookie in the servlet. The cookie is set by single sign-on software.

On the first attempt when the single sign-on (LTPA) cookie is being set and WAS is adding HTTP headers which IE browser does not like.

Does Java servlet api provide a way to remove http headers? Is there a technique to use Filter api to remove http headers?

Answer 1

If you remove the Cache-Control header from the response, then you're not sending any instructions about caching and therefore the caching behavior would be unpredictable.

It would be better to set the header to something else, rather than remove it. Presumably you want to enable caching on the browser for your pages. So you could add these lines to your servlet to enable caching in the browser:

response.setHeader("Pragma", "cache");
response.setHeader("Cache-Control", "private, must-revalidate");

You could do this in a Filter too, because filters have access to the HTTP response object. But if you've written your own servlet then it's probably more efficient — and clearer — to do it in the servlet.

Answer 2

It's all controllable by you. If you don't put it there, there will be nothing to remove.