Re: that preload swf files question again ...

Geoff Cox wrote:
Richard Cornford wrote:
On Sep 30, 7:36 pm, Geoff Cox wrote:
<snip>
I have used the Live HTTP Headers extension and get

http://www.micro-active.com/a-preload-swf.htm

This URL produces an HTTP status 404 resposne.

Richard,

Apologies for that - I have changed the code which now does
download the swf files.

Downloading the files is only part of the problem. If they are not stored in the browser's cache then they will just be downloaded again later, making the pre-loading actively harmful as the first time is then just a waste of bandwidth (pointless server load and so on).

I use about:cache and Firefox to see that the 10 swf
files are in the cache.

The URL is OK now

http://www.micro-active.com/a-preload-swf.htm
<snip>
Thomas (in "how to generalize this code?") has critized my code
but I don't know how else to cope with the 10 objects.

Is there a better way?

There is no point in looking at more involved/complex alternatives until the reasons for this approach's apparent failure is understood.

<snip>
Range: bytes=0-
If-Range: "2b3cb53-25689-acccd540"

A Range request!

HTTP/1.x 206 Partial Content
<snip>
There is not much in this response to encourage caching,
and a Last-Modified date that is less than 2 minutes before
the request is certainly not going to encourage caching in
the absence of any other indicators (as it would imply the
resource is frequently changed).
<snip>

As you back-tracked through the HTTP specification from the 206 response to the Range and If-Range headers you will have noticed that this sample of the HTTP traffic was too far down stream of be informative (was pretty much doomed not to be cached). The request that Firefox initially decided not to cache was the first one it made to the server; the one with the 200 response. When I make that request the only header returned that is likely to have an impact on the cache-ability of the resource was the Last-Modified header (no Expires header, no Cache-Control with 'max-age', etc.). And as I observed earlier, at the time of the 206 response the difference between the request time and the Last-Modified time was only a couple of minutes (the sort of thing that is likely to discourage caching).

It may be that any apparent subsequent success in caching the files is only a result of your having stopped modifying them, and so the difference between the request times and the Last-Modified headers increasing (and stopped changing between requests). But if this is the case then the outcome is going to be fragile, and returning to addressing the original heeders issues would still be a good idea.

Richard.

.

Relevant Pages