Quickly confirmed with Mircea that there wasn't something going on. The best advice would be to pre-load (but not display) the image(s) or other resources you need on the original request so that they are available in IE's cache when you need them. Or perhaps one of the strategies mentioned in the link I provided above will suffice.

Re-opening this JIRA. A different customer has been able to show that this is not an issue with a basic JSF test case. Using the exact same code using ICEfaces cases the issue.

As per the conversation in the support meeting, I tested with using a commandButton with a f:ajax tag to display the image. Testing in IE9, the image is displayed upon clicking of the button. It is not displayed if navigation occurs.

Attached test cases for a non-ICEfaces JSF app and an ICEfaces app. The ICEfaces app includes the commandButton/f:ajax test.

I don't think the recent test cases are equivalent. The non-ICEfaces test doesn't use Ajax so:

• a ViewRoot style update is not done
• the URL in the browser changes (which bypasses the issue)

The problem is related to ViewRoot updates via Ajax where the URL doesn't change. In those cases, IE simply tries to use the cache and will not send a request to retrieve the resource. I suspect that if you change the JSF only test to use f:ajax (or remove ICEfaces libs from the ICEfaces test), it will behave the same way as the ICEfaces test.

This issue is definitely not caused by ICEfaces. After running a modified test case that was not using ICEfaces at all and the navigation was triggered by Ajax enabled h:commandLink the issue could still be reproduced. It seems that IE9 will not make a request for the image referenced by the 'input' element that is inserted dynamically into the document.

Beside the workaround offered by Deryk on could create a servlet filter for the served images, filter that would return a different combination of caching headers to hopefully make IE9 retrieve the referenced images.