304 for flags, icons, images, and css are expected and normal, as we set a Cache-Control header for those. So let's ignore all of that.

For pages such as /console, 304 is not expected. We don't set a Cache-Control header, and there is no header in the screenshot. But there's also no If-Modified-Since or If-None-Match header in the request. You should never get a 304 back unless you included a conditional header in the request? Not sure. See RFC 2616. This may be an IE thing, or the IE network monitor is not telling the truth or is synthesizing a network action when it's really pulling from local cache (and you imply the same thing happens in Firefox in the OP: "it does hide its fault if network monitor is opened")

We may need to attempt to reproduce this with wget, eepget, or similar, to eliminate network monitor lies and browser caches.

But also need to research allowed caching if no Cache-Control header is set.

I see that Jetty sends the Expires header if there's no session (confirmed with eepget) but does not if there's a session.

We removed the cache directives in css.jsi in March 2011 because they were causing reloads of POSTed fetches when the user clicked the back button (since we don't do P-R-G). Perhaps we can come up with some combination of headers that will work.

I still suspect that the 304s shown in the screenshot are 'fake', it's just pulling from browser cache?