"Marc J. Cawood" <cawoodm DeleteThis @gmail.com> wrote in message
news:f887758b-43ba-4c9b-82f7-b83ad33b22a5@60g2000hsy.googlegroups.com...
> Can anyone explain why a browser _shouldn't_ cache compressed files?
> Can we change this from the IIS side?
>
> I've read (vaguely) that IE won't cache compressed responses and I
> have also witnessed this behaviour with xsl files which are defined as
> static cache files in the metabase. Why is this double (network)
> performance boost not allowed?
>
> The file is in the browser cache (temporary internet files) but
> fiddler shows that IE requests the file again and again and the
> timestamp (Last Checked) is always updated.
>
> The response header is:
> HTTP/1.1 200 OK
> Cache-Control: max-age=2419200
> Content-Length: 393
> Content-Type: text/xml
> Content-Encoding: gzip
> Last-Modified: Thu, 15 Dec 2005 12:20:47 GMT
> Accept-Ranges: bytes
> ETag: "80795dfa711c61:425"
> Vary: Accept-Encoding
> Server: Microsoft-IIS/6.0
> WWW-Authenticate: Negotiate
>
It would have helped if you supplied the request headers.
My guess is that the request headers contains a pragma:no-cache and probably
no If-Modified-Since or If-None-Match headers either.
MSXML will be the culprit. MSXML3 (the version of msxml used by IE) by
default has its ForcedResync option set to true. This means that MSXML
doesn't trust any cache and requires the XML to be resent, it won't even
send headers which give the origin server an option to send a 304.
In JScript use this code to turn it off.
oDOM.setProperty("ForcedResync", false);
note this a global option. The next DOM you instance will still have this
option set to false.
However you mentioned XSL. If you are using the document() function to
fetch additional XML DOMs you're out of luck. The document() function seems
unaffected by the change in ForcedResync setting and will force a resync
anyway. Very annoying.
--
Anthony Jones - MVP ASP/ASP.NET
>> Stay informed about: Why won't IE won't cache compressed responses?