RE: no_cache(1) and still cached?
On Fri, 2003-07-25 at 04:32, Frank Maas wrote: Come to think of it, I have never had problems with mod_proxy caching thing I didn't want cached. Quite the opposite -- I had to be very careful with Expires headers to get anything cached at all. I think you might be mis-diagnosing the problem here. Maybe it's an issue on the backend instead. Well, I thought that too, but couldn't get a grip on it. Picture the situation I described before. Whenever a page is served outside it's template, a logmessage is generated. Now when I see a page without template on my screen (wrong) and I look in the logfile I see that only the allowed address is written as being served. That's why I thought there was some optimisation in the cache engine that limited the number of equal requests to the backend to one for each URI. This would then even go beyond any headers, but more on the principle of 'the page served at exactly the same moment is the same page'...? --Frank PS: I now removed the caching mechanism from the setup and everything is working fine through the proxy. Whenever I cross this bridge again I will start looking more closely.
RE: no_cache(1) and still cached?
On Fri, 2003-07-25 at 04:32, Frank Maas wrote: But the idea of setting the Expiry header back in time is appealing... Come to think of it, I have never had problems with mod_proxy caching thing I didn't want cached. Quite the opposite -- I had to be very careful with Expires headers to get anything cached at all. I think you might be mis-diagnosing the problem here. Maybe it's an issue on the backend instead. - Perrin
no_cache(1) and still cached?
Hi, Recently I found some strange behaviour of the caching-functionality of Apache. I had configured one httpd as caching proxy and a second one creating the pages. Two kind of pages are created: dynamic ones (with no_cache(1)) and static ones (with an expiry set to some minutes or hours). What I found was that sometimes users got served 'cached' dynamic pages. Although the server should not cache the page it looked like this happened whenever two requests were received at (nearly) the same time by the server. Has anyone of you experienced this before and does this harm current ideas about caching proxies? --Frank
Re: no_cache(1) and still cached?
On Thu, 2003-07-24 at 09:55, Frank Maas wrote: What I found was that sometimes users got served 'cached' dynamic pages. Although the server should not cache the page it looked like this happened whenever two requests were received at (nearly) the same time by the server. What happens if you use Expires headers instead of the no_cache() stuff? - Perrin
Re: no_cache()
David Wheeler wrote:
Huh, according to the mod_perl guide:
http://thingy.kcilink.com/modperlguide/correct_headers/2_1_3_Expires_and_Cache_Control.html
Those headers are not added by no_cache(1). But I see that, according to
the mod_perl Changes file, those headers were added to the behavior of
no_cache(1) in mod_perl 1.21_01. So perhaps the mod_perl guide should be
changed from its current documentation:
my $headers = $r-headers_out;
$headers-{'Pragma'} = $headers-{'Cache-control'} = 'no-cache';
$r-no_cache(1);
To simply:
$r-no_cache(1).
Stas?
Thanks David, fixed in the cvs version.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: no_cache()
Ask Bjoern Hansen wrote: On Thu, 15 Nov 2001, Rasoul Hajikhani wrote: I am using $request_object-no_cache(1) with no success. Isn't it supported any more? Can some one shed some light on this for me... What do you mean with no success? What are you trying to do? -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do(); more than a billion impressions per week, http://valueclick.com Well the cached document is returned rather than the new one. I know this because I make cosmetic changes to the document, reload it, and voila, still the old document. I have cleared the cache, set the cache size to 0, have even restarted the server at times just in case, but the result has been frantic. Sometimes the new document is shown on reloads, and at other times the old one is shown. -r
RE: no_cache()
#set the content type
$big_r-content_type('text/html');
$big_r-no_cache(1);
# some more code
return OK;
You *are* remembering to do
$r-send_http_header();
somewhere in (some more code), arent you?
L8r,
Rob
#!/usr/bin/perl -w
use Disclaimer qw/:standard/;
RE: no_cache()
$r-no_cache(1) adds the headers Pragma: no-cache and Cache-control: no-cache. So, you need to call no_cache before calling $r-send_http_header. You can verify that it works by looking at the headers returned by the server when you request your document. If your browser is caching the page w/o regard to these headers, then it's your browser, not mod_perl that's broken or misconfigured. - Kyle -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, November 16, 2001 10:48 AM To: Ask Bjoern Hansen Cc: [EMAIL PROTECTED] Subject: Re: no_cache() Ask Bjoern Hansen wrote: On Thu, 15 Nov 2001, Rasoul Hajikhani wrote: I am using $request_object-no_cache(1) with no success. Isn't it supported any more? Can some one shed some light on this for me... What do you mean with no success? What are you trying to do? -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do(); more than a billion impressions per week, http://valueclick.com Well the cached document is returned rather than the new one. I know this because I make cosmetic changes to the document, reload it, and voila, still the old document. I have cleared the cache, set the cache size to 0, have even restarted the server at times just in case, but the result has been frantic. Sometimes the new document is shown on reloads, and at other times the old one is shown. -r
RE: no_cache()
On Fri, 2001-11-16 at 11:59, Kyle Oppenheim wrote:
$r-no_cache(1) adds the headers Pragma: no-cache and Cache-control:
no-cache.
snip /
Huh, according to the mod_perl guide:
http://thingy.kcilink.com/modperlguide/correct_headers/2_1_3_Expires_and_Cache_Control.html
Those headers are not added by no_cache(1). But I see that, according to
the mod_perl Changes file, those headers were added to the behavior of
no_cache(1) in mod_perl 1.21_01. So perhaps the mod_perl guide should be
changed from its current documentation:
my $headers = $r-headers_out;
$headers-{'Pragma'} = $headers-{'Cache-control'} = 'no-cache';
$r-no_cache(1);
To simply:
$r-no_cache(1).
Stas?
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Re: no_cache()
Rob Bloodgood wrote:
#set the content type
$big_r-content_type('text/html');
$big_r-no_cache(1);
# some more code
return OK;
You *are* remembering to do
$r-send_http_header();
somewhere in (some more code), arent you?
L8r,
Rob
#!/usr/bin/perl -w
use Disclaimer qw/:standard/;
Well then, that's what was missing :(...
thanks
-r
no_cache()
Hello folks,
I am using $request_object-no_cache(1) with no success. Isn't it
supported any more? Can some one shed some light on this for me...
#set the content type
$big_r-content_type('text/html');
$big_r-no_cache(1);
# some more code
return OK;
thanks in advance.
-r
Re: no_cache()
On Thu, 15 Nov 2001, Rasoul Hajikhani wrote: I am using $request_object-no_cache(1) with no success. Isn't it supported any more? Can some one shed some light on this for me... What do you mean with no success? What are you trying to do? -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do(); more than a billion impressions per week, http://valueclick.com
Re: no_cache pragma/cache-control headers : confusion
Hello, KOFrom the code in Apache.xs, it seems like setting $r-no_cache(0) will KOunset the flag, but not remove the headers. Well, the Expires header is also removed. But it's still broken; you can verify this buggy behavior with this simple script: use Apache (); my $r = Apache-request; $r-no_cache(1); $r-no_cache(0); $r-send_http_header; With mod_perls 1.24_01 and 1.25 on Apaches 1.3.14 and 1.3.19, this call leaves me with Pragma and Cache-Control headers. Sadly, the nice (but broken as per above) no_cache() behavior of sending those two headers is also undocumented in the mod_perl guide to begin with. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
no_cache pragma/cache-control headers : confusion
Dear all, There is some kind of confusion in my head, and the Eagle book seems to me even more confusing. Any help appreciated. First, I always thought that no_cache() does everything regarding headers, and that you have just to turn it on or off. However I discovered yesterday that, at least in my setup, even with no_cache(0) I have Pragma: no-cache Cache-control: no-cache which seems counter-intuitive to me. I've checked the Eagle : it says that no_cache() only adds an Expires field. Ok. But then from where does the Pragma header come ? About -headers_out() it is specifically said : In addition, the Pragma: no-cache idiom, used to tell browsers not to cache the document, should be set indirectly using the no_cache() method. So, that seems confusing to me, since the no_cache() methods seem not to deal with Pragma headers. Who sets Pragma/Cache-control headers and why are they like that by default ? How to override that (with headers_out ?) ? TIA. -- Patrick. ``C'est un monde qui n'a pas les moyens de ne plus avoir mal.''
RE: no_cache pragma/cache-control headers : confusion
Apache (as in httpd) will set the 'Expires' header to the same value as the 'Date' header when no_cache is flagged in the request_rec. When your Perl handler sets $r-no_cache(1), mod_perl (in Apache.xs) is setting the 'Pragma: no-cache' and 'Cache-control: no-cache' headers in addition to setting the no_cache flag in the request_rec. From the code in Apache.xs, it seems like setting $r-no_cache(0) will unset the flag, but not remove the headers. -- Kyle Oppenheim Tellme Networks, Inc. http://www.tellme.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Patrick Sent: Wednesday, April 04, 2001 2:47 AM To: [EMAIL PROTECTED] Subject: no_cache pragma/cache-control headers : confusion Dear all, There is some kind of confusion in my head, and the Eagle book seems to me even more confusing. Any help appreciated. First, I always thought that no_cache() does everything regarding headers, and that you have just to turn it on or off. However I discovered yesterday that, at least in my setup, even with no_cache(0) I have Pragma: no-cache Cache-control: no-cache which seems counter-intuitive to me. I've checked the Eagle : it says that no_cache() only adds an Expires field. Ok. But then from where does the Pragma header come ? About -headers_out() it is specifically said : In addition, the Pragma: no-cache idiom, used to tell browsers not to cache the document, should be set indirectly using the no_cache() method. So, that seems confusing to me, since the no_cache() methods seem not to deal with Pragma headers. Who sets Pragma/Cache-control headers and why are they like that by default ? How to override that (with headers_out ?) ? TIA. -- Patrick. ``C'est un monde qui n'a pas les moyens de ne plus avoir mal.''
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
Does no_cache really deny caching?!
Hello, I would like to deny caching of pages which are under access control. So, I looked at no_cache and browsed through the http header produced by this method. As far as I discovered, no_cache(1) behaves like the A option of mod_expires. The httpd header field looks like Expires: current date and time I am not able to manage that all proxies set the time correclty. Most likely the time settings are different because only a few servers are connected to an NTP time source. This is even more important if a few servers doesn't support daylight saving time correctly. Wouldn't it be better to behave like the M option of mod_expires, e.g. to set the last modification date or maybe the hard way: set an artificial date like 01/01/1980 (that's what I did for myself via $r-header_out)?! Steffen
RE: Does no_cache really deny caching?!
Hello,
I would like to deny caching of pages which are under access control.
So, I looked at no_cache and browsed through the http header
produced by this method.
As far as I discovered, no_cache(1) behaves like the A option of
mod_expires. The httpd header field looks like
Expires: current date and time
I am not able to manage that all proxies set the time correclty. Most likely
the time settings are different because only a few servers are connected
to an NTP time source. This is even more important if a few servers
doesn't support daylight saving time correctly.
Wouldn't it be better to behave like the M option of mod_expires, e.g.
to set the last modification date or maybe the hard way:
set an artificial date like 01/01/1980 (that's what I did for myself via
$r-header_out)?!
I raised this issue on this list about a year and a half ago, and Ask
forwarded it to the Apache Group, where it was rejected because the semantics
of no_cache can't just be altered this way. You can lookup the exact reason
in the archives :-)
This works for me:
my $headers = $r-headers_out;
$headers-{'Pragma'} = $headers-{'Cache-control'} = 'no-cache';
$r-no_cache(1);
Steffen
--
Eric
