Antwort: Re: [Mod_gzip] Mod_gzip and Cache-Control No Cache

[mod_gzip@lists.over.net]

Hi Kevin,


> My only advice is the same as before.
>
> Try using "Expires: -1" in the response header.
>
> If MSIE still keeps a 'copy' of the response in its
> own local cache when it shows up with "Expires: -1"
> then it is truly, truly broken.

sorry, but I wouldn't agree on that.

All browsers that I know about do support some "caching
strategy" in their configuration section.
This may be set to
 a) cache everything and never re-validate
 b) cache nothing and always get a fresh copy
 c) cache, and don't re-ask during one browser session
 d) do what the HTTP server is telling you (named "when
    the page is out of date" in Mozilla, "automatic" in
    M$IE).

So, playing the game according to the HTTP headers being

sent by the HTTP server is always an _option_ (and it is

even the default configuration value in modern browsers),

but it is nothing that a HTTP server can _enforce_ on the

client.



This topic is similar to enforcing a file to be "downloaded",

i. e. being stored on the client's hard disk instead of

being displayed in the browser window.

In this case there are many workarounds, like using strange

MIME types like "application/octet-stream"... (which doesn't

work in M$IE because this client "guesses" the content type)

but ultimately it is the browser configuration that is respon-

sible for the mapping between MIME type and the interpreting

application (I may well map _any_ file to, say, WinZip if I

think this might be appropriate, and even more if I am aware

of the servers "lying" in desperate search of a workaround).



HTTP is sending _suggestions_ to a HTTP client what it should

do with the content. But actually no browser programmer will

be convinced that he cannot do better than obeying these

"commands", by allowing the user to configure a behaviour

that might suit his/her individual requirements better.

Just think about certain configuration options of Squid where

the manual will tell you "if you activate this then you will

break the HTTP standard, so be sure that you know what you are

doing"... everyone tries to do whatever suits his own require-

ments, if these aren't matched exactly by the HTTP standard.



If you want you may thus name all these applications "broken",

but this won't have any effect on reality...



Actually, the browser configuration options named above seem

to be the result of too many server administrators being unable

to configure appropriate caching directives for each and every

URL of their universe (!) and thus not using HTTP to its full

extent, slowing down the Web as a result.

So for "advanced users", the browser allows them to "do better

than the server with the risk of guessing wrong being on their

side then". (Unfortunately, some of them aren't aware of the

last part of this statement...)



There is only one way to definitely prevent caching of an URL's

content: if you create links to it, then always change some part

of the URL (like having it contain some time stamp or whatever

- this part of the URL doesn't even need to be evaluated on the

server at all).

"Same URL means same content", as the client has no way to find

out about any dynamic nature of the content. So why should a

browser not try to cache it if it _believes_ to know better

about its requirements?

Sure, I understand that in some cases the server truely does

understand best and that the user doesn't know about that, but

HTTP as implemented in _all_ available browsers isn't the means

to enforce non-caching of content, whereas changing the URL is.



Regards, Michael