Re: Caching with $r->no_cache(1)

[Ask Bjoern Hansen]

On Fri, 7 Jan 2000, Randy Harmon wrote:

The latest version from CVS also sets the Cache-Control: and the Pragma:
headers when you use $r->no_cache(1).


 - ask

-- 
ask bjoern hansen - 
more than 60M impressions per day, 

Re: Caching with $r->no_cache(1)

[Ask Bjoern Hansen]

On Fri, 7 Jan 2000, Ask Bjoern Hansen wrote:

> On Fri, 7 Jan 2000, Randy Harmon wrote:
> 
> The latest version from CVS also sets the Cache-Control: and the Pragma:
> headers when you use $r->no_cache(1).

(latest version of mod_perl that is, not Apache).


 - ask

-- 
ask bjoern hansen - 
more than 60M impressions per day, 

Re: Caching with $r->no_cache(1)

[G.W. Haywood]

Hi there,

On Fri, 7 Jan 2000, Randy Harmon wrote:

> Currently, I'm experiencing the problem with Netscape 4.7, although I seem
> to recall the same problem in earlier releases, in the case where the target
> browser's clock is slow.
> 
> [snip] can be corrected by explicitly setting an Expires header that's in
> the past.  How far in the past depends on how lenient you wish to be with
> browsers with slow clocks.
> 
> Something between 5 and 30 minutes seems reasonable to me, but discussion
> may demonstrate a different approach and/or timeframe.
> 
> Thoughts?

Well, quite a lot of computers now fire up with the clock saying some
time around 4 Jan 1980.  Just how far do you let this go?  My view is
that if he suspects that it may cause a problem, one should tell his
user to make sure the clock is right.  Caveat browsor.  I feel sure
that deliberately lying about the time is a dangerous path to tread.
Of course we can't (yet) expect everyone to be running ntpd, and five
minutes doesn't initially seem unreasonable, but we could then expect
biennial fun and games when daylight savings time kicks in and out, or
not, as the case often may be.  The software industry has a bad enough
reputation as it is, without yet another kind of periodic Y2k bug.

Maybe a Request For Comment?

Or a word in someone's ear at the browser development labs?

73
Ged.

RE: Caching with $r->no_cache(1)

[Eric Cholet]

Doug has made the following modification to modperl (in the CVS tree):

  $r->no_cache(1) will now set the r->headers_out "Pragma" and
  "Cache-control" to "no-cache"

This should work even with buggy browsers.

--
Eric


> I notice that the Guide omits the mention of Netscape's ignorance of
> Expires: set to the same as Date: when it mentions $r->no_cache(1)
> performing that function.  
> 
> Currently, I'm experiencing the problem with Netscape 4.7, although I seem
> to recall the same problem in earlier releases, in the case where the target
> browser's clock is slow.
> 
> Of course, the server-side workaround (since we can't just fix our visitor's
> clocks) is to set an Expires header that significantly in the past, for some
> definition of 'significant'.
> 
> I'm going to assume that $r->no_cache(1) won't be kludged to fix Netscape's
> bug, although some would argue that it should be 'fixed' in mod_perl.
> 
> As an update to /guide/correct_headers.html#2_1_3_Expires_and_Cache_Control,
> I'd suggest adding the following text at the end:
> 
> [ ... works with the major browsers. ] However, Netscape clients with slow
> clocks may not honor the 'immediate' timeout, cacheing pages anyway. 
> This can be corrected by explicitly setting an Expires header that's in
> the past.  How far in the past depends on how lenient you wish to be with
> browsers with slow clocks.
> 
> Something between 5 and 30 minutes seems reasonable to me, but discussion
> may demonstrate a different approach and/or timeframe.
> 
> Thoughts?
> 
> Randy
> 

Re: Caching with $r->no_cache(1)

[Randy Harmon]

On Fri, Jan 07, 2000 at 12:44:43AM -0800, Ask Bjoern Hansen wrote:
> The latest version from CVS also sets the Cache-Control: and the Pragma:
> headers when you use $r->no_cache(1).

Hm, I'm setting those explicitly, as directed by the Guide.  God, it's
useful.  er, "Stas, it's useful" :)

Randy

Re: Caching with $r->no_cache(1)

[Randy Harmon]

Does anybody have experience detecting such a condition, perhaps through one
of the client headers?  I haven't had a chance to dump them - many hats.

In any case, I could use some Javascript to package up the machine's current
time and send it back to the server, for instance at the same point where I
check whether a cookie was accepted.  That'd indicate their
"Javscript-OK"-ness too.  I think I'm willing to assume that someone clueful
enough to turn off Javascript is clueful enough to have the correct time.

Any other offers as to a cleaner solution?

Randy

On Fri, Jan 07, 2000 at 09:52:25AM +, G.W. Haywood wrote:
> Hi there,
> 
> On Fri, 7 Jan 2000, Randy Harmon wrote:
> 
> > Currently, I'm experiencing the problem with Netscape 4.7, although I seem
> > to recall the same problem in earlier releases, in the case where the target
> > browser's clock is slow.
> > 
> > [snip] can be corrected by explicitly setting an Expires header that's in
> > the past.  How far in the past depends on how lenient you wish to be with
> > browsers with slow clocks.
> > 
> > Something between 5 and 30 minutes seems reasonable to me, but discussion
> > may demonstrate a different approach and/or timeframe.
> > 
> > Thoughts?
> 
> Well, quite a lot of computers now fire up with the clock saying some
> time around 4 Jan 1980.  Just how far do you let this go?  My view is
> that if he suspects that it may cause a problem, one should tell his
> user to make sure the clock is right.  Caveat browsor.  I feel sure
> that deliberately lying about the time is a dangerous path to tread.
> Of course we can't (yet) expect everyone to be running ntpd, and five
> minutes doesn't initially seem unreasonable, but we could then expect
> biennial fun and games when daylight savings time kicks in and out, or
> not, as the case often may be.  The software industry has a bad enough
> reputation as it is, without yet another kind of periodic Y2k bug.
> 
> Maybe a Request For Comment?
> 
> Or a word in someone's ear at the browser development labs?
> 
> 73
> Ged.
> 

Re: Caching with $r->no_cache(1)

[G.W. Haywood]

Hi there,

On Fri, 7 Jan 2000, Randy Harmon wrote:

> Does anybody have experience detecting such a condition, perhaps through one
> of the client headers?  I haven't had a chance to dump them - many hats.

No idea - ditto.

> In any case, I could use some Javascript to package up the machine's
> current time and send it back to the server, for instance at the
> same point where I check whether a cookie was accepted.  That'd
> indicate their "Javscript-OK"-ness too.  I think I'm willing to
> assume that someone clueful enough to turn off Javascript is clueful
> enough to have the correct time.

You might want to look at the excellent ntpd documentation which talks
about things like network delays.  I think your Javascript idea is as
good a solution as you're going to get until the Web Comes Of Age.
Don't know what you're going to do when I visit with Lynx though...
Well, at least my clock _will_ be right, I run a level 3 timeserver.

Somebody's probably going to tell us we've strayed off topic now...

73
Ged.

Re: Caching with $r->no_cache(1)

[Randy Harmon]

On Sun, Jan 09, 2000 at 08:45:11PM +, G.W. Haywood wrote:
> On Fri, 7 Jan 2000, Randy Harmon wrote:
> 
> > Does anybody have experience detecting such a condition, perhaps through one
> > of the client headers?  I haven't had a chance to dump them - many hats.
> 
> No idea - ditto.
> 
> > In any case, I could use some Javascript to package up the machine's
> > current time and send it back to the server, for instance at the
> > same point where I check whether a cookie was accepted.  That'd
> > indicate their "Javscript-OK"-ness too.  I think I'm willing to
> > assume that someone clueful enough to turn off Javascript is clueful
> > enough to have the correct time.
> 
> You might want to look at the excellent ntpd documentation which talks
> about things like network delays.  I think your Javascript idea is as

Fortunately, network lag only works in our favor when it comes to this
technique.  So it expires a few hundred milliseconds in the past instead of
"now"... no biggie to me.

> good a solution as you're going to get until the Web Comes Of Age.
> Don't know what you're going to do when I visit with Lynx though...

I'm going to hope that Lynx is smarter than Netscape on this point, and
assume that you're clueful enough to have the correct time. 

> Well, at least my clock _will_ be right, I run a level 3 timeserver.

He... I'm with you.  Oh, good, my assumption was right. :)

Randy