Forcing a browser to re-render an image from its URL location andnot from the browser's cache

E

Edward Diener

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

Edward Diener

Good said:
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 ?
 
F

Friedemann Kiersch

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. The browser
assumes, there is a new image each time the
page loads and _always_ refreshes the image.
Its best to use serverside scripting for this
technique, JS with document.write() could also be
an option.

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 ?

nope, all browsers handle it the same way, except
you turn off all your caching.

greetings
 
S

SAM

Edward Diener a écrit :
Thanks, but that does not work.

Yes it could work, but you have to change 'blahblah' on each call

The best would be to use a code on the server.

Codes to use could be :
- the present date (with seconds)
- a random number

Or in JS, ie :

<body onload="document.myWebCam.src += '?'+Math.random();" >

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 ?

Not it is not a bug, it's why there is a cache.
(to do not run to the server to download a known file)
 
T

Thomas 'PointedEars' Lahn

Friedemann said:
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
 
C

caglaror

I usually try this.
(If i use binary method, if its a statik image you can put the static
url in stead of binarysender.asp, my binarysender.asp page creates
random captcha image).

function changeTheImage(){
document.getElementById('myImageID').src='binarysender.asp?'+(new
Date()).getMilliseconds();
}


or

function changeTheImage(imageID){
document.getElementById(ImageID).src='binarysender.asp?'+(new
Date()).getMilliseconds();
}

Regards,
Ça lar
 
T

Thomas 'PointedEars' Lahn

caglaror said:
I usually try this.
(If i use binary method, if its a statik image you can put the static
url in stead of binarysender.asp, my binarysender.asp page creates
random captcha image).

function changeTheImage(){
document.getElementById('myImageID').src='binarysender.asp?'+(new
Date()).getMilliseconds();
}

or

function changeTheImage(imageID){
document.getElementById(ImageID).src='binarysender.asp?'+(new
Date()).getMilliseconds();
}

Neither of those produces a value in the query part that is unique over
time. For Date.prototype.getMilliseconds() there are possible return values
from 0 to 999 for *every* second. Iff one is to employ changing URI query
parts, which is usually unnecessary, using the number of milliseconds since
Epoch instead definitely is the best approach.

Please quote the minimum of what you are replying to, as explained and
recommended in the FAQ http://jibbering.com/faq/


PointedEars
 
B

Bart Van der Donck

Edward said:
[...]
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.
 
E

Edward Diener

Bart said:
Edward said:
[...]
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.
 
E

Edward Diener

Thomas said:
Those are _not_ cache control headers, nor any other headers. And if you
had actually read the document that I pointed to, you would have known that
it is a mere myth that `meta' elements could do anything to prevent caching.

Thanks for your help but neither using the correct cache control headers
or the image randomizer trick with the query part of the image URL gets
the browser to re-render the image rather than take it from its cache. I
will have to try randomizing the image src name itself instead.
 
T

Thomas 'PointedEars' Lahn

[Sorry for posting out of thread but this FUD has to be corrected.]
Bart said:
Edward said:
[...]
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.

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.

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
 
B

Bart Van der Donck

Thomas said:
The server does not have to obey the rules, but the client has to.

With "obeying the rules", I mean that the server must send Cache-
Control HTTP headers in order to (try to) avoid caching at any level.
Of course server plays a crucial role in whole the caching process.
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.

Nonsense. Tip: focus on known large file sizes (e.g. wav, mpg...) and
you'll be surprised how much of that stuff is buffered, even
'unrenewable'. Internet traffic would be multiplied by a factor X if
all those would be requested from their end-source every time.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,995
Messages
2,570,225
Members
46,815
Latest member
treekmostly22

Latest Threads

Top