Re: Preload images

[CK]

Words to the wise, Henry <rc*******@rain drop.co.ukwrote :

>Live HTTP headers does not show any expiry-date,
at least none I can recognize...

Then you are probably not sending Expires headers with the images (nor
Cache-Control headers with max-age parameters). Which will mean that
the individual browsers are likely to make their decisions about
whether to use a cached image based upon non-standard/non-documented
internal algorithms, and that will likely produce different outcomes
in different browsers (and under different browser configurations) ,
which is what you have been describing.

Sorry for the delay, was overly swamped and only managed to be able to
free some time last week to work on this.
Yes, that was the whole problem.
Adding Cache-Control with max-age solved the problem.

I tried to add a FileETag as well, but this does not seem to make any
additional difference, LiveHTTPHeaders does not even show that.
Would that even make sense to add a unique id to each requested
object? The images the code is requesting are already unique from
their path name.

>In the event that a particular browser reacts to the HTTP headers (or
the absence of HTTP headers) you send with your images by deciding
that it is never appropriate to use a cached image you can do all the
image pre-loading you like with scripts (or with HTML) and it will
make no difference to the situation at all (which also seems to be
what you are describing). See:-

Yes, that was it, exactly.

My guess is that when we moved our application to the new hardware,
part of the updated Apache configuration got lost in the mists of the
matrix.

Thanks a lot to you for your very helpful suggestion, also thanks to
the others for pointing out several code imperfections, those are also
rectified.
--
Claus Dragon <cl*******@mpsa hotmail.com>
=(UDIC)=
d++ e++ T--
K1!2!3!456!7!S a29
"Coffee is a mocker. So, I am going to mock."

- Me, lately.

[Thomas 'PointedEars' Lahn]

CK wrote:

Words to the wise, Henry <rc*******@rain drop.co.ukwrote :

>>Live HTTP headers does not show any expiry-date,
at least none I can recognize...

Then you are probably not sending Expires headers with the images (nor
Cache-Control headers with max-age parameters). Which will mean that
the individual browsers are likely to make their decisions about
whether to use a cached image based upon non-standard/non-documented
internal algorithms, and that will likely produce different outcomes
in different browsers (and under different browser configurations) ,
which is what you have been describing.

Sorry for the delay, was overly swamped and only managed to be able to
free some time last week to work on this.
Yes, that was the whole problem.
Adding Cache-Control with max-age solved the problem.

I tried to add a FileETag as well,

Probably you mean _ETag_. HTTP/1.x does not specify a FileETag header, that
name is reserved for an Apache directive. Since the default value for that
directive is "INode MTime Size" already, there is hardly a need to use it.

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

but this does not seem to make any
additional difference, LiveHTTPHeaders does not even show that.

LHH does show the `ETag' header value, provided it is in the response. Try
for example http://pointedears.de/scripts/dhtml.js

Would that even make sense to add a unique id to each requested
object?

Yes, it definitely would.

The images the code is requesting are already unique from their path name.

Cache control headers are all about recognizing the difference between the
cached and the current resource even though the URL the latter is retrieved
with is the same that was used for retrieving the former.
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, <f8************ *******@news.de mon.co.uk>

[CK]

Words to the wise, Thomas 'PointedEars' Lahn <Po*********@we b.de>
wrote:

>CK wrote:

>Words to the wise, Henry <rc*******@rain drop.co.ukwrote :

>>>Live HTTP headers does not show any expiry-date,
at least none I can recognize...
Then you are probably not sending Expires headers with the images (nor
Cache-Control headers with max-age parameters). Which will mean that
the individual browsers are likely to make their decisions about
whether to use a cached image based upon non-standard/non-documented
internal algorithms, and that will likely produce different outcomes
in different browsers (and under different browser configurations) ,
which is what you have been describing.

Sorry for the delay, was overly swamped and only managed to be able to
free some time last week to work on this.
Yes, that was the whole problem.
Adding Cache-Control with max-age solved the problem.

I tried to add a FileETag as well,

Probably you mean _ETag_. HTTP/1.x does not specify a FileETag header, that
name is reserved for an Apache directive. Since the default value for that
directive is "INode MTime Size" already, there is hardly a need to use it.

Yes, I meant exactly ETag. I should not type when not completely
awake.

I actually wanted to exlude INode, for I am not sure how much the CMS
swaps data around, so the same images might get different inodes and
therefore be treated as new files although that is not the case.

>http://www.mnot.net/cache_docs/

>but this does not seem to make any
additional difference, LiveHTTPHeaders does not even show that.

>LHH does show the `ETag' header value, provided it is in the response. Try
for example http://pointedears.de/scripts/dhtml.js

Ok, so if there is no ETag header shown, there is no ETag specified.

>Would that even make sense to add a unique id to each requested
object?

Yes, it definitely would.

>The images the code is requesting are already unique from their path name.

Cache control headers are all about recognizing the difference between the
cached and the current resource even though the URL the latter is retrieved
with is the same that was used for retrieving the former.

Ok, so the unique id is computed from inode, mtime and size and if one
of them changes, so does the unique id. Hmmm, I am still not sure I
understand how this could be made to work.
--
Claus Dragon <cl*******@mpsa hotmail.com>
=(UDIC)=
d++ e++ T--
K1!2!3!456!7!S a29
"Coffee is a mocker. So, I am going to mock."

- Me, lately.