Forcing viewers to un-cache css?

[hughestroop]

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.]

<hu*********@gmail.comwrote in message
news:11**********************@h48g2000cwc.googlegr oups.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]

"Mark F." <re*********@nospam.comwrites:

<hu*********@gmail.comwrote in message
news:11**********************@h48g2000cwc.googlegr oups.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">

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.]

"Chris Morris" <c.********@durham.ac.ukwrote in message
news:87************@dinopsis.dur.ac.uk...

"Mark F." <re*********@nospam.comwrites:

><hu*********@gmail.comwrote in message
news:11**********************@h48g2000cwc.googleg roups.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">

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]

Mark F. wrote:

<hu*********@gmail.comwrote in message
news:11**********************@h48g2000cwc.googlegr oups.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?

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]

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.]

"Michael Winter" <m.******@blueyonder.co.ukwrote in message
news:x0*******************@text.news.blueyonder.co .uk...

Mark F. wrote:

><hu*********@gmail.comwrote in message
news:11**********************@h48g2000cwc.googleg roups.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?

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]

>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

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]

"Mark F." <re*********@nospam.comwrites:

"Chris Morris" <c.********@durham.ac.ukwrote in message

[meta refresh on the page is] Useless - won't affect the CSS file,

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]

..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]

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]

Michael Winter wrote:

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

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]

hu*********@gmail.com 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.