From: FAQ server on
-----------------------------------------------------------------------
FAQ Topic - Why are my rollovers so slow?
-----------------------------------------------------------------------

Images are cached by the browser depending on the headers sent by
the server. If the server does not send sufficient information
for the browser to decide the image is cacheable, the browser
will check if the image has been updated every time you change the
src of an image (in some user settings). To overcome this you
must send suitable headers.

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


The complete comp.lang.javascript FAQ is at
http://jibbering.com/faq/

--

The sendings of these daily posts are proficiently hosted
by http://www.pair.com.

From: VK on
On Apr 11, 3:00 am, "FAQ server" <javascr...(a)dotinternet.be> wrote:
> -----------------------------------------------------------------------
> FAQ Topic - Why are my rollovers so slow?
> -----------------------------------------------------------------------
>
> Images are cached by the browser depending on the headers sent by
> the server. If the server does not send sufficient information
> for the browser to decide the image is cacheable, the browser
> will check if the image has been updated every time you change the
> src of an image (in some user settings).  To overcome this you
> must send suitable headers.
>
> http://www.mnot.net/cache_docs/

Someone should finally remove this IE/NN 4 times silliness from the
FAQ. Indeed one can craft server-side img headers in most sick way and
with enough of application screw the caching mechanics. Has nothing to
do with the rollovers.

When NN3 first introduced Image and onmouseover/onmouseout for it, it
became hugely cool and popular to make graphics menu with rollover
effect. But as at that POD time even 14.4 Kbps was a rare really cool
spead, it would lead to inevitable delays for the first pass over the
menu items while getting mouse over picture state.

To avoid that a precaching mechanics was provided as well:
var imgOver = new Image();
imgOver.src = 'some/url';
The latter statement triggered 'some/url' loading and caching right
away, so by the time user started roll over the menu at least some if
not all mouseover images would be cached and shown immediately.

Of course - as usual in the Web - some people found a malicious usage
for that for so-called "Cach overflow attacking" by making a bunch of
new Image with src pointing to really big files.

So the initial functionality
"imgOver.src = 'some/url';" equals image precaching
had to be blocked. As it was still POD era, rollovers became slow
again on the first pass and caused a lot of complains about "my old
menu doesn't behave as before" By the connection speed increase this
issue became eliminated by itself, as delays became hardly noticeable.
Also a workaround became used by caching images over hidden (i)frame
instead of imgOver.src = 'some/url';

I vote to remove this urban legend out or at least mark it as a urban
legend but leave for a "historical flavor".
From: Garrett Smith on
VK wrote:
> On Apr 11, 3:00 am, "FAQ server" <javascr...(a)dotinternet.be> wrote:
>> -----------------------------------------------------------------------
>> FAQ Topic - Why are my rollovers so slow?
>> -----------------------------------------------------------------------
>>

[...]

> I vote to remove this urban legend out or at least mark it as a urban
> legend but leave for a "historical flavor".

Yeah that question is outdated.

The information in the answer still has practical relevance. An Image
request can be used for reasons other than rollover. For example, a
program that wants to know if the user has disconnected from the
Internet can ping a server to check for connection and issue a warning
after a period of time that the image has not loaded. In that case,
having the image cached would be problem because `onload` would fire for
the loading of the cached image in some browsers (though I cannot recall
which browsers or versions).

So remove or replace with something else relevant?
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Stefan Weiss on
On 11/04/10 16:03, VK wrote:
> On Apr 11, 3:00 am, "FAQ server" <javascr...(a)dotinternet.be> wrote:
>> -----------------------------------------------------------------------
>> FAQ Topic - Why are my rollovers so slow?
>> -----------------------------------------------------------------------
>>
>> Images are cached by the browser depending on the headers sent by
>> the server. If the server does not send sufficient information
>> for the browser to decide the image is cacheable, the browser
>> will check if the image has been updated every time you change the
>> src of an image (in some user settings). To overcome this you
>> must send suitable headers.
>>
>> http://www.mnot.net/cache_docs/
>
> Someone should finally remove this IE/NN 4 times silliness from the
> FAQ. Indeed one can craft server-side img headers in most sick way and
> with enough of application screw the caching mechanics. Has nothing to
> do with the rollovers.

It's not really a frequently asked question, AFAICT, but the pointer to
the caching tutorial is useful, and could help to solve similar problems.

On the other hand, the FAQ text isn't entirely accurate:

| To overcome this you must send suitable headers

.... and hope that the UA's cache is enabled and properly configured.
Client side caching can only be encouraged, but not forced from the
server side. For example, there's an issue with IE6 and IE7 (and
possibly IE8, didn't test) where checking the "don't store encrypted
pages" (or similar) will completely disable the cache for SSL sites -
not only the disk cache, but any kind of caching at all. In this mode,
IE will always fetch the rollover images, even if it had just fetched
them a few seconds ago. Very annoying.

> When NN3 first introduced Image and onmouseover/onmouseout for it, it
> became hugely cool and popular to make graphics menu with rollover
> effect. But as at that POD time even 14.4 Kbps was a rare really cool
> spead, it would lead to inevitable delays for the first pass over the
> menu items while getting mouse over picture state.

And now, with our mobile devices, we're often back to this "rare really
cool spead"...
(granted, rollovers usually aren't an issue on mobile devices ;-)

> To avoid that a precaching mechanics was provided as well:
> var imgOver = new Image();
> imgOver.src = 'some/url';

Somebody is probably going to tell you that Image isn't a standard
constructor, and that this is a portability hazard, but to be honest, I
can't think of any reasonably modern browser which doesn't support it.
If there are any, please feel free to correct me.

> Of course - as usual in the Web - some people found a malicious usage
> for that for so-called "Cach overflow attacking" by making a bunch of
> new Image with src pointing to really big files.
>
> So the initial functionality
> "imgOver.src = 'some/url';" equals image precaching
> had to be blocked. As it was still POD era, rollovers became slow
> again on the first pass and caused a lot of complains about "my old
> menu doesn't behave as before" By the connection speed increase this
> issue became eliminated by itself, as delays became hardly noticeable.
> Also a workaround became used by caching images over hidden (i)frame
> instead of imgOver.src = 'some/url';

What? I never heard about any "cache overflow attack" or any of the
other stuff you mentioned, and I certainly wouldn't recommend using a
hidden Iframe to preload images (and why should Iframes be immune to
this "attack"?). Could you provide a source or citation?


--
stefan
From: Richard Cornford on
On Apr 12, 12:52 am, Stefan Weiss wrote:
> On 11/04/10 16:03, VK wrote:
>> On Apr 11, 3:00 am, "FAQ server" wrote:
>>> -----------------------------------------------------------------
>>> FAQ Topic - Why are my rollovers so slow?
>>> -----------------------------------------------------------------
>
>>> Images are cached by the browser depending on the headers sent by
>>> the server. If the server does not send sufficient information
>>> for the browser to decide the image is cacheable, the browser
>>> will check if the image has been updated every time you change the
>>> src of an image (in some user settings). To overcome this you
>>> must send suitable headers.
>
>>>http://www.mnot.net/cache_docs/
>
>> Someone should finally remove this IE/NN 4 times silliness from
>> the FAQ. Indeed one can craft server-side img headers in most
>> sick way and with enough of application screw the caching
>> mechanics. Has nothing to do with the rollovers.
>
> It's not really a frequently asked question, ...
<snip>

Since the point of a FAQ is to provide the answers to questions that
get frequently asked in order that it is possible for people to
quickly find those answers, and so don't need to ask (and so don't
need to be given repetitive answers), observing that a question
answered in a FAQ is not frequently asked might be no more than
testimony that the FAQ is doing its job.

>> Of course - as usual in the Web - some people found a malicious
>> usage for that for so-called "Cach overflow attacking" by making
>> a bunch of new Image with src pointing to really big files.
>
>> So the initial functionality
>> "imgOver.src = 'some/url';" equals image precaching
>> had to be blocked. As it was still POD era, rollovers became slow
>> again on the first pass and caused a lot of complains about "my old
>> menu doesn't behave as before" By the connection speed increase this
>> issue became eliminated by itself, as delays became hardly
>> noticeable. Also a workaround became used by caching images over
>> hidden (i)frame instead of imgOver.src = 'some/url';
>
> What? I never heard about any "cache overflow attack" or any of the
> other stuff you mentioned, and I certainly wouldn't recommend using
> a hidden Iframe to preload images (and why should Iframes be
> immune to this "attack"?). Could you provide a source or citation?

What is the correct form of citation for; made up off the top of his
head?

Richard.