Prev: FAQ Topic - What are object models? (2010-03-21)
Next: ECMA-262-3 in detail. Chapter 4. Scope chain.
From: Hans-Georg Michna on 21 Mar 2010 09:21
While trying to optimize the Ajax routine at
http://winhlp.com/node/684 I hit upon a possible browser snag in
relation to caching. Has anybody here looked into this matter
and knows what's going on?

In earlier versions I forced no caching by appending a timestamp
to the query string, like:

url += "&nc=" + new Date().getTime().toString().slice(-9, -3);

This method does even allow some limited caching. For example,
if you use a number that changes only every 10 or 100 seconds,
you get some caching over a short period of time.

However, the method has the obvious disadvantage that you are
filling the browser cache with useless hits, often of the same
data, that can never be re-used and serve only to push useful
cache content out of the cache prematurely.

So I began to experiment with the request header and wrote this:

if (getOrPost === "GET" && noCache)
xhr.setRequestHeader("If-Modified-Since",
"01 Jan 1970 00:00:00 GMT");

This works exceedingly well and totally suppresses any caching.
It looks like a practical solution to me.

So far, so good. But I thought, if I can influence under which
circumstances a page gets cached, I might as well use the time
string in the request header to control caching more precisely.
For example, there may be data that changes only in a matter of
minutes, not seconds, so it would be good to cache it for a
minute.

However, all my attempts failed. I tested only Internet Explorer
8, because if it wouldn't work there, the solution would be
unacceptable in today's landscape anyway.

The result of my tests is that the mere presence of the
If-Modified-Since request header row suppresses caching, no
matter which time is given. It does not matter whether the time
is in the future or in the past or far in the future or far in
the past---at least IE8 stops caching when this line is in the
request header at all.

I did make sure that the time string conforms to RFC-822, like
the one in the example above. I also tried the not quite
conformant version IE produces with

new Date().toString()

and the again different and somewhat more standards-conformant
string from

new Date().toUTCString()

But none of them made any difference.

Any ideas on this one?

Hans-Georg
From: The Natural Philosopher on 21 Mar 2010 10:19
Hans-Georg Michna wrote:
> While trying to optimize the Ajax routine at
> http://winhlp.com/node/684 I hit upon a possible browser snag in
> relation to caching. Has anybody here looked into this matter
> and knows what's going on?
>
> In earlier versions I forced no caching by appending a timestamp
> to the query string, like:
>
> url += "&nc=" + new Date().getTime().toString().slice(-9, -3);
>
> This method does even allow some limited caching. For example,
> if you use a number that changes only every 10 or 100 seconds,
> you get some caching over a short period of time.
>
> However, the method has the obvious disadvantage that you are
> filling the browser cache with useless hits, often of the same
> data, that can never be re-used and serve only to push useful
> cache content out of the cache prematurely.
>
> So I began to experiment with the request header and wrote this:
>
> if (getOrPost === "GET" && noCache)
> xhr.setRequestHeader("If-Modified-Since",
> "01 Jan 1970 00:00:00 GMT");
>
> This works exceedingly well and totally suppresses any caching.
> It looks like a practical solution to me.
>
> So far, so good. But I thought, if I can influence under which
> circumstances a page gets cached, I might as well use the time
> string in the request header to control caching more precisely.
> For example, there may be data that changes only in a matter of
> minutes, not seconds, so it would be good to cache it for a
> minute.
>
> However, all my attempts failed. I tested only Internet Explorer
> 8, because if it wouldn't work there, the solution would be
> unacceptable in today's landscape anyway.
>
> The result of my tests is that the mere presence of the
> If-Modified-Since request header row suppresses caching, no
> matter which time is given. It does not matter whether the time
> is in the future or in the past or far in the future or far in
> the past---at least IE8 stops caching when this line is in the
> request header at all.
>
> I did make sure that the time string conforms to RFC-822, like
> the one in the example above. I also tried the not quite
> conformant version IE produces with
>
> new Date().toString()
>
> and the again different and somewhat more standards-conformant
> string from
>
> new Date().toUTCString()
>
> But none of them made any difference.
>
> Any ideas on this one?
>

I think it is part of the 'Microsoft is immortal' group think.

When you are immortal, the exact time doesn't matter much. ;-)


> Hans-Georg
 | 
Pages: 1
Prev: FAQ Topic - What are object models? (2010-03-21)
Next: ECMA-262-3 in detail. Chapter 4. Scope chain.