Forcing browsers not to use their cache for images

[Edward Diener]

I am working on a web application which programatically changes an image
on the server side ( via ImageMagick ) on the roundtrip between client
and server. When the web page, in which the img tag resides, is
redisplayed, I need Firefox to reread the web page in order to redisplay
the image correctly rather than take the image from its cache.

I have been told that the only reliable way to do this is by using the
content header of the web page to specify certain values which,
according to W3C, browsers are supposed to follow to tell it how to
treat the cache. I have done this, according to the documentation I have
found, and yet the browser does not redisplay the image from the URL but
continues to display it by using its cache. This displays the image
incorrectly since it has changed on the server in the roundtrip between
client and server and back again.

The problem occurs in Firefox ( 2.0.0.11 ) and with IE6 and IE7 also. I
have not tried to test it with any other browsers since the
specification for the web application is that it is only guaranteed to
work with Firefox and IE. The fact that the problem exists with IE as
well as Firefox suggests that some combination in the content header is
not correct to force browsers to not use the cache but instead to reread
the data from the img URL.

Here is the content header, without the cookies, from such a page, as
extracted live:

--------------------------------------------------------

Content-type: text/plain
HTTP/1.1 200 OK
Server: ""
Date: Thu, 24 Jan 2008 16:01:45 GMT
Content-type: text/html
Pragma: no-cache
Cache-control: no-cache,no-store,must-revalidate

--------------------------------------------------------

If anybody can see what is incorrect in the content header and tell me
what I have to change in order to cause the browser to redisplay the
image from the URL and not from its cache, it would be highly
appreciated by me.

Getting browsers to redisplay the image correctly, from changes made on
the server side, is crucial to this particular application, and this
problem has persisted for much of the life of the application without a
resolution.

Thank you !

 

[Thomas 'PointedEars' Lahn]

[...]
The problem occurs in Firefox ( 2.0.0.11 ) and with IE6 and IE7 also. [...]
Here is the content header,

There is no such thing.

without the cookies, from such a page, as extracted live:

--------------------------------------------------------

Content-type: text/plain ^^^^^^^^^^^^^^^^^^^^^^^^
HTTP/1.1 200 OK
Server: ""

^^
That header is invalid. See RFC 2616, section 14.38:

http://www.rfc-editor.org/rfc/rfc2616.txt

Date: Thu, 24 Jan 2008 16:01:45 GMT
Content-type: text/html

Declaring the encoding of the resource with the `charset' parameter is
strongly recommended:

http://www.w3.org/TR/html401/charset.html#h-5.2.2

That aside, have you not already declared the Content-Type? There can only
be one Content-Type header per response message, and the status code has to
come before all headers.

Pragma: no-cache
Cache-control: no-cache,no-store,must-revalidate

You have declared the caching policy, but you have not provided any header
that would allow the user agent to recognize a change in the resource as
compared to the cached one. The Date header does not suffice (see RFC 2616,
section 14.18), you have to provide one or more of Content-Length (14.13),
Content-MD5 (14.15), ETag (14.19), Expires (14.21), or Last-Modified (14.29).

See also http://www.mnot.net/cache_docs/


The From header of your NetNews message is invalid too (not to mention
disregarding Netiquette, see RFC 1036, section 2.1.1 (which refers to RFC
2822, section 3.4.1), and possibly the Acceptable Use Policy of your Usenet
access provider. Please fix that.


HTH

PointedEars

 

[Edward Diener]

[...]
The problem occurs in Firefox ( 2.0.0.11 ) and with IE6 and IE7 also. [...]
Here is the content header,

There is no such thing.

There is no such thing as an HTML page content header ? Please explain.

^^
That header is invalid. See RFC 2616, section 14.38:

That is wonderfully cryptic but I am guessing you are telling me that
the Server must have a value rather than an empty string.

http://www.rfc-editor.org/rfc/rfc2616.txt


Declaring the encoding of the resource with the `charset' parameter is
strongly recommended:

http://www.w3.org/TR/html401/charset.html#h-5.2.2

OK, I hear you !

That aside, have you not already declared the Content-Type? There can only
be one Content-Type header per response message, and the status code has to
come before all headers.

Was there not a "Content-type: text/html" in the above ? Are you saying
that the content type is invalid because the status code comes after it
? I don't generate a status code, I just set the content header fields
in my code.

You have declared the caching policy, but you have not provided any header
that would allow the user agent to recognize a change in the resource as
compared to the cached one. The Date header does not suffice (see RFC 2616,
section 14.18), you have to provide one or more of Content-Length (14.13),
Content-MD5 (14.15), ETag (14.19), Expires (14.21), or Last-Modified (14.29).

If I provide an Expires, what do I set the value to ? Is -1 a valid
value ? Previously I had an Expires: -1, to force expiration, but that
did not cause my problem to go away.

See also http://www.mnot.net/cache_docs/


The From header of your NetNews message is invalid too (not to mention
disregarding Netiquette, see RFC 1036, section 2.1.1 (which refers to RFC
2822, section 3.4.1), and possibly the Acceptable Use Policy of your Usenet
access provider. Please fix that.

Sorry but this is way too cryptic for me. I appreciate your knowledge
but I have no idea what you mean by saying the From header is invalid.
If you are criticizing my Usenet message to this newsgroup you are just
being silly and hypercritical to no good end.

Hopefully restoring the Expires: -1 value and putting in a valid Server
value will fix my problem but if it does not I will post again.

Thanks for your help !

 

[Thomas 'PointedEars' Lahn]

Sorry but this is way too cryptic for me.

You could have used your favorite search engine instead of playing stupid.

I appreciate your knowledge but I have no idea what you mean by saying
the From header is invalid. If you are criticizing my Usenet message to
this newsgroup you are just being silly and hypercritical to no good end.

,-<http://www.att.net/csbellsouth/s/s.dll?spage=cg/legal/att.htm&leg=aup
|
| Spam/E-mail/Usenet Abuse
|
| Violation of the CAN-SPAM Act of 2003, or any state or federal law
| regulating e-mail services, constitutes an automatic violation of this AUP
| and AT&T reserves the right to seek damages and other available relief
| against Customer, as applicable.
|
| Spam/E-mail/Usenet Abuse is prohibited on AT&T IP Services. Examples of
| Spam/E-mail/Usenet Abuse include but are not limited to the following
| activities:
|
| [...]
| # posting a single message, or messages to online forums or newsgroups,
| that could reasonably be expected to provoke complaints;
| # posting messages to or canceling or superseding messages on an online
| forum or newsgroup in a manner that violates the rules of the forum or
| newsgroup or that contain forged header information.
| [...]

You have been warned.


Score adjusted,

PointedEars

 

[Stevo]

I have been told that the only reliable way to do this is by using the
content header of the web page to specify certain values which,

I don't think that this is the only way to do it. I think individual
browser settings override any settings your server might return. You may
tell the browser to request the file every time, but if the browser is
set to only check once per session, I believe the browser wins and does
exactly that.

You can reload the image again with a random query string. That's a
pretty standard way of doing things.

A js function like this would reload the image and break the caching:

function reloadImage(imgobj,imgpath)
{
var rand = Math.floor(Math.random()*10000000);
imgpath += "?" + rand;
if(imgobj)
imgobj.src=imgpath;
}

You'd get requests to your server like this:

myimg.gif?123456
myimg.gif?7959831234
etc.

 

[Edward Diener]

You could have used your favorite search engine instead of playing stupid.

It is you who are stupid since clear communication seems beyond you, and
you seem to think that cryptic communication is somehow real "cool"
rather than just being annoying.

I appreciate your knowledge but I have no idea what you mean by saying
the From header is invalid. If you are criticizing my Usenet message to
this newsgroup you are just being silly and hypercritical to no good end.

,-<http://www.att.net/csbellsouth/s/s.dll?spage=cg/legal/att.htm&leg=aup
|
| Spam/E-mail/Usenet Abuse
|
| Violation of the CAN-SPAM Act of 2003, or any state or federal law
| regulating e-mail services, constitutes an automatic violation of this AUP
| and AT&T reserves the right to seek damages and other available relief
| against Customer, as applicable.
|
| Spam/E-mail/Usenet Abuse is prohibited on AT&T IP Services. Examples of
| Spam/E-mail/Usenet Abuse include but are not limited to the following
| activities:
|
| [...]
| # posting a single message, or messages to online forums or newsgroups,
| that could reasonably be expected to provoke complaints;
| # posting messages to or canceling or superseding messages on an online
| forum or newsgroup in a manner that violates the rules of the forum or
| newsgroup or that contain forged header information.
| [...]

You have been warned.

I am terribly scared that the thought police, led by you, will come and
take me away.

Score adjusted,

Whatever that means !!!

 

[Edward Diener]

I don't think that this is the only way to do it. I think individual
browser settings override any settings your server might return. You may
tell the browser to request the file every time, but if the browser is
set to only check once per session, I believe the browser wins and does
exactly that.

So you are saying that there is essentially no programmatic way of
forcing browsers to reload an image from its URL rather than taking the
image from its cache ?

You may be right but that seems utterly illogical from this programmer's
point of view. It essentially says that any web application, which
depends on images being changed on the server side be reflected by the
browser's display of that image, can not possibly work. This makes web
application programming utterly hopeless.

You can reload the image again with a random query string. That's a
pretty standard way of doing things.

A js function like this would reload the image and break the caching:

function reloadImage(imgobj,imgpath)
{
var rand = Math.floor(Math.random()*10000000);
imgpath += "?" + rand;
if(imgobj)
imgobj.src=imgpath;
}

You'd get requests to your server like this:

myimg.gif?123456
myimg.gif?7959831234
etc.

Already tried and does not work. The browser ignores the request string
part of the URL and continues to reload the image from its cache.

I have to believe that there is some simple way of telling the browser,
for a particular web page, to go out and reload the image from its URL
rather than assuming it has the most recent version of that image in its
cache. The fact that it has been impossible to find out from anyone or
anywhere what that way is still amazes me, as if I were asking for some
hidden secret which only initiates are allowed to know <g>.

Thanks for your suggestion, nonetheless. I do appreciate it.

 

[Stevo]

Thomas 'PointedEars' Lahn said the following on 1/25/2008 6:09 PM:


"If you don't do exactly as Thomas thinks you should, he will tell on
you!". But, he "cares about the Net", he isn't a "control freak".
What a joke you are sometimes.

It would be incredibly amusing if Thomas's CV/Resume had "Good
communication skills" and "team player" on it. I think his personality
is more suited to be a traffic warden.

It's sad when technical knowledge (which none of us doubt he has plenty
of ... and I expect he has more than me in the web technology field) is
wrapped up in such a package.

 

[Stevo]

The browser ignores the request string
part of the URL and continues to reload the image from its cache.

That doesn't match up with my experience. I've been using that technique
for a long time. The browser isn't intelligent enough to realize that
it's the same URL (which of course it isn't).

I have to believe that there is some simple way of telling the browser,
for a particular web page, to go out and reload the image from its URL
rather than assuming it has the most recent version of that image in its
cache. The fact that it has been impossible to find out from anyone or
anywhere what that way is still amazes me, as if I were asking for some
hidden secret which only initiates are allowed to know <g>.

Thanks for your suggestion, nonetheless. I do appreciate it.

Perhaps that Comet Programming thread is something for you. That implies
the kind of server pushed content updating. That doesn't help you if it
means you have to re-architect a lot of stuff of course.

I notice that Yahoo Finance does regular image updates when you're
looking at a daily stock chart. They could be using some Ajax method, or
they might just overwrite the innerHTML once a minute by using a
random query string on the image.

 

[Edward Diener]

That doesn't match up with my experience. I've been using that technique
for a long time. The browser isn't intelligent enough to realize that
it's the same URL (which of course it isn't).

I hear you but unfortunately when I tried this the browser still
reloaded the image form its cache. The browser could obviously be
intelligent enough to parse the img tag so that anything after the ? is
ignored, although it may not be correct HTML to do that. Does it
actually mean anything to give an image URL some request parameters ?

Perhaps that Comet Programming thread is something for you. That implies
the kind of server pushed content updating. That doesn't help you if it
means you have to re-architect a lot of stuff of course.

I notice that Yahoo Finance does regular image updates when you're
looking at a daily stock chart. They could be using some Ajax method, or
they might just overwrite the innerHTML once a minute by using a random
query string on the image.

I wish your random query string on the image worked for me.

The only other thing I can think of is that I need a valid expires date
or last updated date in the content header, and I am not giving one to
the browsers, so that even though I have the correct cache control
values the browser still grabs the image from its cache.

 

[VK]

So you are saying that there is essentially no programmatic way of

forcing browsers to reload an image from its URL rather than taking
the image from its cache ?

Of cause there is: but it has to be done in accordance with HTTP
rules, not in the way "it must work by my/his/my boss opinion" ;-)

Put image content-generating script on your server, ensure - if GET
used - that for each new image an unique URL is used and be happy.

myImg.src = "cgi-bin/graph.cgi?p1=v1&p2=v2";
....
myImg.src = "cgi-bin/graph.cgi?p1=v1&p2=v22";
....
myImg.src = "cgi-bin/graph.cgi?p1=v1&p2=v222";
etc.

Not a Javascript question per se as Javascript is not in power to
override HTTP rules or personal browser settings.

 

[Stevo]

Not a Javascript question per se as Javascript is not in power to
override HTTP rules or personal browser settings.

Yeah, maybe a networking or http forum would be best for that.

 

[Thomas 'PointedEars' Lahn]

[...]
Put image content-generating script on your server, ensure - if GET
used - that for each new image an unique URL is used and be happy.

myImg.src = "cgi-bin/graph.cgi?p1=v1&p2=v2";
...
myImg.src = "cgi-bin/graph.cgi?p1=v1&p2=v22";
...
myImg.src = "cgi-bin/graph.cgi?p1=v1&p2=v222";
etc.

This approach will fail in Internet Explorer once the length of the
*resulting* URI has reached 2083 characters:

http://support.microsoft.com/kb/208427

Anyway, it needlessly clutters up the cache, thus potentially *slowing down*
Web access.


PointedEars

 

[VK]

[...]
Put image content-generating script on your server, ensure - if GET
used - that for each new image an unique URL is used and be happy.

myImg.src = "cgi-bin/graph.cgi?p1=v1&p2=v2";
...
myImg.src = "cgi-bin/graph.cgi?p1=v1&p2=v22";
...
myImg.src = "cgi-bin/graph.cgi?p1=v1&p2=v222";
etc.

This approach will fail in Internet Explorer once the length of the
*resulting* URI has reached 2083 characters:

Or even much lesser on Mobile IE. It is a known GET issue for IE.

Anyway, it needlessly clutters up the cache, thus potentially *slowing down*
Web access.

No pain - no gain If an intensive round-trip traffic is expected
then another alternative would be to leave document headers in peace -
they are irreleventa to the issue anyway. Instead OP should set
expiration headers for _images_ themselves with the expiration date
guaranteed to be in the past, say:
Last-Modified: Fri, 31 Dec 1999 00:00:01 GMT
Expires: Fri, 31 Dec 1999 00:00:02 GMT
Because HTTP request is rarely goes right from server to client and
vice versa, Pragma wouldn't hurt neither so to tell to intermediary
servers do not use their own caches but to forward requests to the
server of origin, so the full set could be:
Last-Modified: Fri, 31 Dec 1999 00:00:01 GMT
Expires: Fri, 31 Dec 1999 00:00:02 GMT
Pragma: no-cache
On the long run the answer to OP is "no": one cannot enforce all UAs
in the whole Internet act exactly in the way your server wants.
Anything can be changed or overridden client-side. Any WWW project is
a number game so the question is only to encure the satisfactory
majority of clients acting in the desired way. If we skip on webpunks
(Linx, no-cache-if-no-older-than-1998, 64Kb cache size etc), it should
work for 99,9% of your visitors.

 

[Thomas 'PointedEars' Lahn]

[...]
Put image content-generating script on your server, ensure - if GET
used - that for each new image an unique URL is used and be happy.
myImg.src = "cgi-bin/graph.cgi?p1=v1&p2=v2";
...
myImg.src = "cgi-bin/graph.cgi?p1=v1&p2=v22";
...
myImg.src = "cgi-bin/graph.cgi?p1=v1&p2=v222";
etc.

This approach will fail in Internet Explorer once the length of the
*resulting* URI has reached 2083 characters:

Or even much lesser on Mobile IE. It is a known GET issue for IE.

And *you* have suggested this approach anyway. Are you providing evidence
of your splitted personality here?

No pain - no gain If an intensive round-trip traffic is expected
then another alternative would be to leave document headers in peace -
they are irreleventa to the issue anyway.

Yes, but you are missing the point.

Instead OP should set expiration headers for _images_ themselves with
the expiration date guaranteed to be in the past, say:
Last-Modified: Fri, 31 Dec 1999 00:00:01 GMT
Expires: Fri, 31 Dec 1999 00:00:02 GMT
[...]

Your ability to repeat *falsely* and *in gibberish* what you read before
never ceases to amaze me.


PointedEars

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
..net>, Fri, 25 Jan 2008 17:18:56, Edward Diener <diener896092_no_spam_he
(e-mail address removed)> posted:

Sorry but this is way too cryptic for me. I appreciate your knowledge
but I have no idea what you mean by saying the From header is invalid.
If you are criticizing my Usenet message to this newsgroup you are just
being silly and hypercritical to no good end.

Ignore the quasi-Kaiser. He has a disturbed personality.

 

[Thomas 'PointedEars' Lahn]

[...] Edward Diener [...] posted:

Sorry but this is way too cryptic for me. I appreciate your knowledge
but I have no idea what you mean by saying the From header is invalid.
If you are criticizing my Usenet message to this newsgroup you are just
being silly and hypercritical to no good end.

Ignore the quasi-Kaiser. He has a disturbed personality.

Message-ID: <[email protected]>

What a hypocrite you are.


PointedEars

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]>, Sun,

Message-ID: <[email protected]>

What a hypocrite you are.

I am obliged to you for that further proof of your insanity.

 

[Thomas 'PointedEars' Lahn]

[...] Thomas 'PointedEars' Lahn [...] posted:

Message-ID: <[email protected]>

What a hypocrite you are.

I am obliged to you for that further proof of your insanity.

You have said in the referred posting that "You should not use any other
address that might belong to anyone else, currently or in the future; that
is wildly inconsiderate, and contrary to the policy of the better ISPs."
Now, it is entirely possible that someone else has the same idea than
Mr. Diener and uses that currently non-existing mailbox in the future.

And that aside, the fact remains that others get spammed because Mr. Diener
uses an address header that, when used for e-mails by spammers, produces
bounces, which are received by the people the spammer has selected as source
for the From header of his spam e-mails.

However, when others point out the very same problem that you do, in their
own words of course, you can nothing but insult them in the inept attempt to
make believe that the opposite would be true.

So there is sufficient reason to call you an obnoxious hypocrite, indeed.


EOD

PointedEars

 

[Ivan Marsh]

It is you who are stupid since clear communication seems beyond you, and
you seem to think that cryptic communication is somehow real "cool"
rather than just being annoying.

You're arguing with the single biggest asshole in the group. His nick
should give you some idea of his attitude. He can't answer a simple
question without pissing in your face and acting like you should
appreciate it.

Even if he was the smartest, most experienced programmer in the group his
personality would make his advice useless... too bad for him he's not.