Re: Caching with $r-no_cache(1)
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
Caching with $r-no_cache(1)
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)
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 - http://www.netcetera.dk/~ask/ more than 60M impressions per day, http://valueclick.com
Re: Caching with $r-no_cache(1)
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)
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
