Stylesheets - Forcing viewers to un-cache css?

Author

Forcing viewers to un-cache css?

hughestroop@gmail.com

2006-11-19, 7:35 pm

I have updated my CSS and if you view the main page with the old css
cached, it breaks the page. Is there any way to force viewers that
have the old css cached to get the new css?

Our viewers are NOT tech savvy, and wouldn't know what a "hard refresh"
is, nor that it needed to be done.

Mark F.

2006-11-19, 7:35 pm

<hughestroop@XXXXXXXXXX> wrote in message
news:1162999139.311728.159040@h48g2000cwc.googlegroups.com...
>I have updated my CSS and if you view the main page with the old css
> cached, it breaks the page. Is there any way to force viewers that
> have the old css cached to get the new css?
>
> Our viewers are NOT tech savvy, and wouldn't know what a "hard refresh"
> is, nor that it needed to be done.
>

Use a meta tag in the head to expire the page.

<META http-equiv="Expires" content="Tue, 20 Aug 1996 14:25:27 GMT">

Chris Morris

2006-11-19, 7:35 pm

"Mark F." <reply2group@nospam.com> writes:
> <hughestroop@XXXXXXXXXX> wrote in message
> news:1162999139.311728.159040@h48g2000cwc.googlegroups.com...
>
> Use a meta tag in the head to expire the page.
>
> <META http-equiv="Expires" content="Tue, 20 Aug 1996 14:25:27 GMT">

Useless - won't affect the CSS file, and would be overridden by any
real HTTP headers anyway. Oh, and of course, anyone with a copy of the
page stuck in their cache won't see the new version.

The best solution is to copy the new CSS file to a new filename, and
then change the HTML to point to the new CSS. Then they should either
get old CSS+old HTML, or new CSS+new HTML. Since you changed the HTML
first, it might still break, but from what you say people *are*
getting the new HTML fine.

--
Chris

Mark F.

2006-11-19, 7:35 pm

"Chris Morris" <c.i.morris@durham.ac.uk> wrote in message
news:87fycss1jr.fsf@dinopsis.dur.ac.uk...
> "Mark F." <reply2group@nospam.com> writes:
>
> Useless - won't affect the CSS file, and would be overridden by any
> real HTTP headers anyway. Oh, and of course, anyone with a copy of the
> page stuck in their cache won't see the new version.
>
> The best solution is to copy the new CSS file to a new filename, and
> then change the HTML to point to the new CSS. Then they should either
> get old CSS+old HTML, or new CSS+new HTML. Since you changed the HTML
> first, it might still break, but from what you say people *are*
> getting the new HTML fine.
>

That doesn't make sense. A page is parsed completely when it expires,
therefore an scripts that are listed in the head will be reloaded fresh as
well. Do you have any example of how it fails?

Michael Winter

2006-11-19, 7:35 pm

Mark F. wrote:
> <hughestroop@XXXXXXXXXX> wrote in message
> news:1162999139.311728.159040@h48g2000cwc.googlegroups.com...

No. If age information was sent previously, either the cached resource
needs to expire, the cache must be cleared, or the user must force it to
be updated. If only a validator was sent, then there shouldn't be any
problem, however a browser or intermediary cache can be forced to cache
data in spite of (some) directives from the server if it's more
beneficial to the user than up-to-date information.

[snip]
[color=darkred]
> Use a meta tag in the head to expire the page.

A meta element cannot be expected to control caching: an intermediary
cache is very unlikely to check the message body, and even a browser
doesn't have to respect it. Caching should be controlled only by HTTP
headers. Besides, how does this help data that's already been cached? If
the user agent isn't going to the server, how is it going to read this
meta element?

Mike

Mark F.

2006-11-19, 7:35 pm

"Michael Winter" <m.winter@blueyonder.co.uk> wrote in message
news:x0O4h.49976$r61.14376@text.news.blueyonder.co.uk...
> Mark F. wrote:
>
> No. If age information was sent previously, either the cached resource
> needs to expire, the cache must be cleared, or the user must force it to
> be updated. If only a validator was sent, then there shouldn't be any
> problem, however a browser or intermediary cache can be forced to cache
> data in spite of (some) directives from the server if it's more beneficial
> to the user than up-to-date information.
>
> [snip]
>
>
> A meta element cannot be expected to control caching: an intermediary
> cache is very unlikely to check the message body, and even a browser
> doesn't have to respect it. Caching should be controlled only by HTTP
> headers. Besides, how does this help data that's already been cached? If
> the user agent isn't going to the server, how is it going to read this
> meta element?
>
> Mike

Ok, I stand corrected on the meta tag, however, I disagree with you on one
point. If the cached object(s) is stale, or the expiration time is expired,
or the data has been set to only one session, the page and scripts will be
re-cached from the server. I've never had problems updating sites using an
expiration date or the like.

Mark

Chris Morris

2006-11-19, 7:35 pm

"Mark F." <reply2group@nospam.com> writes:
> "Chris Morris" <c.i.morris@durham.ac.uk> wrote in message
>
> That doesn't make sense. A page is parsed completely when it expires,
> therefore an scripts that are listed in the head will be reloaded fresh as
> well. Do you have any example of how it fails?

The browser will parse the page, yes, and will probably make
conditional requests for 'attached' items such as styles, scripts,
images, etc. If there's an intermediate cache (which may be the
browser's own, if its caching policy is right) then you can get this
situation:

[server] <--> [cache] <--> [browser]
page expired expired
css current expired

So, the browser makes a conditional request for the page, and gets the
new one, but when it conditionally requests the CSS, the cache thinks
(wrongly) that it has an up-to-date copy, and sends that back without
checking with the origin server.

It doesn't even need an intermediate cache, if the browser is
sufficiently confident that the CSS file is current that it doesn't
even bother with a conditional request (and it doesn't *have* to make
one) - if you can dig out an old copy of Opera 6 that hung on to old
CSS files even on a shift-reload of the HTML sometimes: you had to
shift-reload the CSS file itself to convince it to check for a new
one...

--
Chris

Michael Fesser

2006-11-19, 7:35 pm

..oO(Mark F.)

>That doesn't make sense. A page is parsed completely when it expires,
>therefore an scripts that are listed in the head will be reloaded fresh as
>well.

No. Just because the main document expires doesn't mean that all other
referenced external documents expire as well. Every single resource, be
it an image, CSS, script, whatever, is completely independent from each
other.

Micha

Michael Winter

2006-11-19, 7:35 pm

Mark F. wrote:

[snip]

> If the cached object(s) is stale, or the expiration time is expired,
> or the data has been set to only one session, the page and scripts
> will be re-cached from the server.

The stale and invalidated entities will be, yes, but the assessment of
age or validity is made on a case-by-case basis. That one is now stale
or invalid doesn't automatically invalidate other resources, whether
they are related or not.

> I've never had problems updating sites using an expiration date or
> the like.

That statement doesn't mean much without knowing the precise
circumstances in which you observed what you did. That is, the
configuration of your browser, the state of your cache, the headers sent
by the server, and the headers sent by the browser are all important
factors.

Mike

FuzzyLogik

2006-11-19, 7:35 pm

Michael Winter wrote:
> Mark F. wrote:
>
> [snip]
>
>
> The stale and invalidated entities will be, yes, but the assessment of
> age or validity is made on a case-by-case basis. That one is now stale
> or invalid doesn't automatically invalidate other resources, whether
> they are related or not.
>
>
> That statement doesn't mean much without knowing the precise
> circumstances in which you observed what you did. That is, the
> configuration of your browser, the state of your cache, the headers sent
> by the server, and the headers sent by the browser are all important
> factors.
>
> Mike

Just so everyone knows.

What I did was leave the old html and change only the css, which didn't
break the old html, only the new.

Then, two days later, released the new html, in hopes that those that
had it cached didn't have on "perma-cache" and had downloaded the new
CSS by that point.

Seems to have gone well, btw.

Andy Dingley

2006-11-19, 7:35 pm

hughestroop@XXXXXXXXXX wrote:

> I have updated my CSS and if you view the main page with the old css
> cached, it breaks the page. Is there any way to force viewers that
> have the old css cached to get the new css?

Get in your time machine and serve the old CSS with some suitable HTTP
headers that suggest not to cache it for all eternity. Hopefully your
well-adminned server was already doing this, but it's not guaranteed.

Back here and Now you should serve the new CSS document with correct
headers indicating it has been updated (it's unlikely your server isn't
doing this).

At some reasonable interval, then web browsers will check to see if
their old cached copy is still sensible. Then they'll check for an
update and see the new one. They're usually pretty good at this (within
a day or a reboot or so). There's little you can do in the meantime
though, unless you can visit each browser personally.

If you're doing development work, then the headers you serve on a CSS
document should indicate it's very likely to expire soon and caching
shouldn't be prolonged, if at all. You can always increase these again
once you've finished work. This is obviously easier if you use "dev"
and "production" servers.

If you had posted a URL we could have told you a lot more useful
information about how things actually were.