Forcing a browser to re-render an image from its URL location andnot from the browser's cache | | |
Is there a way in Javascript, or perhaps in HTML, to force a browser to
re-render an image on an HTML page after a round-trip between the client
and the server ?
In my particular case, the image is changing on the server although the
URL for it remains the same, but the browser is still displaying the old
image from its cache rather than the new image from its URL location.
| | | | re: Forcing a browser to re-render an image from its URL location andnot from the browser's cache
Edward Diener <diener896092_no_spam_here@bellsouth.netwrote in
news:3IoTi.4745$b9.3200@bignews1.bellsouth.net: Quote:
Is there a way in Javascript, or perhaps in HTML, to force a browser to
re-render an image on an HTML page after a round-trip between the client
and the server ?
>
In my particular case, the image is changing on the server although the
URL for it remains the same, but the browser is still displaying the old
image from its cache rather than the new image from its URL location.
>
you can try appending fake arguments to the URL, ie:
<img src="naked.jpg?blahblah" /> | | | | re: Forcing a browser to re-render an image from its URL location andnot from the browser's cache
Good Man wrote: Quote:
Edward Diener <diener896092_no_spam_here@bellsouth.netwrote in
news:3IoTi.4745$b9.3200@bignews1.bellsouth.net:
> Quote:
>Is there a way in Javascript, or perhaps in HTML, to force a browser to
>re-render an image on an HTML page after a round-trip between the client
>and the server ?
>>
>In my particular case, the image is changing on the server although the
>URL for it remains the same, but the browser is still displaying the old
>image from its cache rather than the new image from its URL location.
>>
>
you can try appending fake arguments to the URL, ie:
>
<img src="naked.jpg?blahblah" />
>
Thanks, but that does not work.
Is it not a bug in a browser if the browser never re-renders an image
except from its cache, or is that just the way certain browsers work ?
If certain browsers work that way surely there must be some way to tell
a browser to re-render the image because the image has changed between
the trip between the client and server and back. Do all modern browsers
just assume that an image in an HTML page must remain static and never
change once it is displayed during a session, and strictly rely on the
end-user to tell the browser to refresh the entire HTML page when
necessary through some sort of menu command ? | | | | re: Forcing a browser to re-render an image from its URL location andnot from the browser's cache
Friedemann Kiersch wrote: Quote: Quote: Quote:
>>you can try appending fake arguments to the URL, ie:
>><img src="naked.jpg?blahblah" />
>>>
>Thanks, but that does not work.
>
Actually, it _does_ work if you apply a random
number/string as the fake argument, changing its
value on _every_ page impression.
It does also work with cache control headers, which don't fill the cache
which garbage, and don't reduce access speed to other resources, effectively. http://www.mnot.net/cache_docs/
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk> | | | | re: Forcing a browser to re-render an image from its URL location andnot from the browser's cache
Thomas 'PointedEars' Lahn wrote: Quote:
Friedemann Kiersch wrote: Quote: Quote:
>>>you can try appending fake arguments to the URL, ie:
>>><img src="naked.jpg?blahblah" />
>>>>
>>Thanks, but that does not work.
>Actually, it _does_ work if you apply a random
>number/string as the fake argument, changing its
>value on _every_ page impression.
>
It does also work with cache control headers, which don't fill the cache
which garbage, and don't reduce access speed to other resources, effectively.
> http://www.mnot.net/cache_docs/
>
>
PointedEars
We are using the HTML below, to no effect. The actual problem is an
image URL being displayed on an HTML page using IE7.
<META HTTP-EQUIV="Expires" CONTENT="Tue, 01 Jan 1985 00:00:01 GMT">
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
<META HTTP-EQUIV="cache-control" CONTENT="no-cache, no-store,
must-revalidate">
<html xmlns="http://www.w3.org/1999/xhtml">
The actual image, to which the URL points, is being changed between
client-server roundtrips, but even with the HTML code above for the HTML
page, IE7 just refuses to re-render the image but insists on always
grabbing it from its cache and therefore not displaying the updated image. | | | | re: Forcing a browser to re-render an image from its URL location andnot from the browser's cache
Edward Diener wrote: Quote:
Friedemann Kiersch wrote: Quote: Quote:
>>>you can try appending fake arguments to the URL, ie:
>>><img src="naked.jpg?blahblah" />
>>>>
>>Thanks, but that does not work.
>>>
>Actually, it _does_ work if you apply a random
>number/string as the fake argument, changing its
>value on _every_ page impression.
>
Perhaps in your case this works but in my case it does not.
>
Are you saying that the argument string after the URL
It is _not_ after the URL/URI, but (the query) part of it. See RFC3986. Quote:
has to be a numeric string to work as opposed to just any random string ?
More, `blahblah' (the query part) in this example should contain a value
that is unique over time.
With client-side JS/ES,
(new Date()).getTime()
or (slightly more efficient)
(new Date()).valueOf()
provide that. Just in case you find no way with your server to send cache
control headers or you find your currently unknown target UA ignoring them
(keep in mind that not all UAs support HTTP/1.1, so you should send the
cache control headers defined in HTTP/1.0, too).
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann | | | | re: Forcing a browser to re-render an image from its URL location andnot from the browser's cache
Edward Diener wrote: Quote:
[...]
Ok, thanks for the heads-up about using actual cache control headers
rather than meta elements. I am using an NSAPI based C++ web server
environment ( in my job ) and I will now try to figure out how to
generate the correct cache control headers when sending a page back to
the client.
Even with correctly configured headers, you have no iron guarantee
that every visiting browser (or server, or any in between gateways)
will obey the rules. For example, ISPs looooove to buffer because it
can save them a lot of money on traffic. I would take one of the
suggested randomizers for maximum result.
--
Bart | | | | re: Forcing a browser to re-render an image from its URL location andnot from the browser's cache
Bart Van der Donck wrote: Quote:
Edward Diener wrote:
> Quote:
>[...]
>Ok, thanks for the heads-up about using actual cache control headers
>rather than meta elements. I am using an NSAPI based C++ web server
>environment ( in my job ) and I will now try to figure out how to
>generate the correct cache control headers when sending a page back to
>the client.
>
Even with correctly configured headers, you have no iron guarantee
that every visiting browser (or server, or any in between gateways)
will obey the rules. For example, ISPs looooove to buffer because it
can save them a lot of money on traffic. I would take one of the
suggested randomizers for maximum result.
Unforunately neither using the correct cache control headers nor using
the randomizer technique is working in my case. The only thing left to
try is to randomly generate an entirely different image src name for
each round-trip. | | | | re: Forcing a browser to re-render an image from its URL location andnot from the browser's cache
[Sorry for posting out of thread but this FUD has to be corrected.] Quote:
Bart Van der Donck wrote: Quote:
>Edward Diener wrote: Quote:
>>[...]
>>Ok, thanks for the heads-up about using actual cache control headers
>>rather than meta elements. I am using an NSAPI based C++ web server
>>environment ( in my job ) and I will now try to figure out how to
>>generate the correct cache control headers when sending a page back to
>>the client.
>Even with correctly configured headers, you have no iron guarantee
>that every visiting browser
True. The client will have to support at least HTTP/1.0. However,
HTTP/0.9-only clients are a rare commodity nowadays. Quote: Quote:
>(or server, or any in between gateways) will obey the rules.
The server does not have to obey the rules, but the client has to. The
gateway would have to work at the application level to recognize and
filter out HTTP headers. No gateway that works at the application level
will do the latter. Quote: Quote:
>For example, ISPs looooove to buffer because it can save them a lot
>of money on traffic.
Those ISPs will become bankrupt soon because no customer likes it if their
Reload button does not work at all. Proxy caches as employed by ISPs cache
Web data based on the full URI, so the case you describe here is not at all
realistic.
PointedEars |  |
Similar JavaScript / Ajax / DHTML bytes | | |  /bytes/about
We are a network of experts and professionals in IT and software development that help one another with answers to tough questions and share insights.
Get the best answers to your questions from over 226,537 network members.
|
