ATSPAM (Developwebsites) writes:
> >If _you_ want to know what's going on (he obviously doesn't), please
> >consult the oft-recommended caching tutorial
> >http://www.mnot.net/cache_docs/
>
> he provided the following as references:
> http://www.webdeveloper.com/html/htm...ags_part2.html
"As of the release of MSIE 4.01..."
Not that it was good advice when that page was written, but it's even
worse advice now.
> http://www.i18nguy.com/markup/metatags.html
"Note: It may be better to specify cache commands in HTTP than in META
statements, where they can influence more than the browser, but
proxies and other intermediaries that may cache information."
If one was to substitute 'may' for 'almost certainly, unless you are
attempting something very strange' then that would be about right.
Since lots of the caching on the web goes on in proxies, that's as
good a reason as any not to use meta for it, along with the fact that
anything in meta will get overridden by the real headers which most
servers send by default anyway.
Caching on the web generally doesn't last longer than a few days (as
caches have limited disk space and browsers recheck anyway after a
while) so it's not a problem for most pages. Rapidly updated pages can
benefit from setting *caching headers through HTTP* but far less (if
at all) from <meta>.
Imagine the likely situation:
Your server <------> ISP Caching Proxy <------> Browser
The browser notices that the page is expired according to its <meta>
information (assuming it's buggy enough to use that in preference to
the real HTTP headers) and asks for it again to see if it's updated.
The proxy notices it has one in its cache, and *it* only knows about
the HTTP headers. So since it's still up-to-date, it sends it back to
the browser.
There are ways around this with real HTTP headers for pages that
*actually* need cache avoidance, of course, but the vast majority of
pages don't.
--
Chris
Similar Threads
