[thelist] good practice META tags?

Keith Davis cache at dowebs.com
Fri May 25 15:26:21 CDT 2001

Thanks for the authoritative response deke!! 
> On 24 May 2001, at 16:48, Keith Davis posted a message which said:

> > Yeah. I can't see how you would use a meta tag to tell the browser to
> > keep a certain image, or an external javascript, or an embedded cgi
> > response out of the cache while caching the rest of the page. But,
> > sending the Pragma: no-cache header along with those page components
> > will do the trick.
> Tell me how you use ANY meta tag to prevent the caching
> of only one component of the page!

That's exactly what I said. A META tag cannot do that. 

But you can keep components from being pulled from the cache based on
the LastModifiedDate of the component. That's what determines if an
external javascript or an SSI is refreshed. The problem with that is
when the js or ssi response is dynamically generated by a exe that has
not in itself been modified. 

I've used a Pragma:no-cache on the assumption that the server would
therefore not send a LastModifiedDate. With Apache, at least, the server
can control whether an ssi will be cached by the browser by not sending
a LastModifiedDate. I was hoping that Pragma:no-cache would accomplish
the same thing for non-ssi dynamic components. You say that it can't do
that though my experience was that it works, albeit unreliably from
different servers. Do you know how to keep a LastModifiedDate from being
sent for an external javascript? Hopefully without getting into the
server's config, which is not always an option.

As an alternative I've found that appending the component's file name
with a query_string such as <script src=some.cgi?_> will reliably(?)
force a dynamic js component to refresh without refreshing the entire
page.  Although I haven't had a need to use it, I'm guessing that the
component <!--#include virtual="=some.cgi?_ --> would also not be cached
since a query_string denotes a unique response.

> A big portion of the internet resides behind the AOL caching
> firewall, and it does NOT read HTML, so HTTP-EQUIV meta tags
> do not affect it. 


> > Or better, what kind of data is exchanged in a pragma request/response?

I still don't get your definition of "illegal", deke. According to your
description below, sending a Pragma:no-cache to the server would
certainly guarantee that the server is forced to send a fresh copy.
Indeed from your description it is probably the only way to force a
refresh from AOL. Doing 100mph in your BMW may be illegal, but the car
was built to run that fast. Since Pragma:no-cache works that way from
the browser, what makes it "illegal" and why does it work that way if
using it in a meta tag is "illegal". What is it "legal" for if not a
meta tag?? How does a "no-cache" directive get into a request message? 

> The Pragma general-header field is used to include implementation-
> specific directives that may apply to any recipient along the
> request/response chain. All pragma directives specify optional
> behavior from the viewpoint of the protocol; however, some systems
> may require that behavior be consistent with the directives.
>     Pragma           = "Pragma" ":" 1#pragma-directive
>     pragma-directive = "no-cache" | extension-pragma
>     extension-pragma = token [ "=" word ]
> When the "no-cache" directive is present in a request message, an
> application should forward the request toward the origin server even
> if it has a cached copy of what is being requested. This allows a
> client to insist upon receiving an authoritative response to its
> request. It also allows a client to refresh a cached copy which is
> known to be corrupted or stale.
> Pragma directives must be passed through by a proxy or gateway
> application, regardless of their significance to that application,
> since the directives may be applicable to all recipients along the
> request/response chain. It is not possible to specify a pragma for a
> specific recipient; however, any pragma directive not relevant to a
> recipient should be ignored by that recipient.


More information about the thelist mailing list