Preload images

[Henry]

Silly question but where do I see that?

RFC 2616 Sections 13 and 13.9.

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.

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:-

Also, where in that trice-%&§! IE can I toggle that?

What?

 

[Henry]

Snorik wrote:

ts_image[12].name = 'filename : image';

`Image' objects don't have a `name' property by default, and even
if they do implement the HTMLImageElement interface of W3C DOM
Level 2 HTML, the `name' property would require a NAME value,
which must not contain whitespace or `:'.

<snip>

The HTMLImageElement interface places no such restrictions on the
value of the - name - property of objects implementing the interface,
and the NAME attribute of HTML IMG elements is not a NAME token it is
CDATA, where white space (subject to notes on leading and trailing
white space) and colon characters are allowed. (The only NAME
attributes in HTML that use NAME tokens are those of META elements.)

 

[Thomas 'PointedEars' Lahn]

ts_image[12].name = 'filename : image';

`Image' objects don't have a `name' property by default, and even
if they do implement the HTMLImageElement interface of W3C DOM
Level 2 HTML, the `name' property would require a NAME value,
which must not contain whitespace or `:'.

<snip>

The HTMLImageElement interface places no such restrictions on the
value of the - name - property of objects implementing the interface,

It does not, but if the `name' attribute was a NAME token it would not have
to even if it could (IDL code, anyone?), and in fact it does not for the
HTMLMetaElement interface. Nevertheless, to comply with the markup
specification that the interface is based on would then be a sensible design
decision to make for a Web developer, ...

and the NAME attribute of HTML IMG elements is not a NAME token it is
CDATA, where white space (subject to notes on leading and trailing
white space) and colon characters are allowed. (The only NAME
attributes in HTML that use NAME tokens are those of META elements.)

...., however, I stand corrected in this case.

(OP: This is not to be misunderstood that what you are doing now is OK, as
you cannot rely on the host object implementing this interface.)


PointedEars

 

[CK]

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 <[email protected]>
=(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]

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

 

[CK]

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/

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.

Yes, it definitely would.


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 <[email protected]>
=(UDIC)=
d++ e++ T--
K1!2!3!456!7!S a29
"Coffee is a mocker. So, I am going to mock."

- Me, lately.