Ticket #156 (reopened defect)
Visitor Caching
Reported by: | kmaclean | Owned by: | kmaclean |
---|---|---|---|
Priority: | major | Milestone: | WebSite 0.2.1 |
Component: | Web Site | Version: | 0.1-alpha |
Keywords: | Cc: |
Change History
comment:2 Changed 15 years ago by kmaclean
Question from WebGUI forum:
Cache Problem
User: jcook Date: 18-May-2007 11:42 pm
I have about 80 user that go to WebGui?? every day (I love the program by the way). Its set as there Intranet home page.
My problem is the Cache, User are reporting that the calender the is not changing the date and they are getting some images becouse of crupted cache. Is there a way in WebGui?? or Apache to set the time to live on the cache data?
Reply to jcook's question:
User: zzois Date: 21-May-2007 8:59 am
I would also like to know answer to this one, hopefully from someone more knowledegable about "ways of WebGUI".
I know that generally speaking there are three ways to set cache control rules for web site(s):
- Via <meta> tags (<meta http-equiv="Expires"...>)
- Programmatically by setting HTTP headers (CGI scripts etc.)
- Through web server configuration files (httpd.conf for apache)
... and that using the third is usually the way most guaranteed to work (especially considering proxy servers).
What I am not sure is how WebGUI now fits into this three...
I beleive that WebGUI predating version 7 used settings that allowed setting different "cache times" for registered users and visitors (options "Cache Timeout" and "Cache Timeout (Visitors)" under "Display" tab), but as this caching scheme was dropped since then, do I presume right that one now controls only WebGUI's own (internal) precaching interval ("Cache Timeout" option under "Display" tab), which is unrelated to how browsers cache data?
Put in another, hopefully more sensible words, do I presume right that "Cache Timeout" option now controls only how often WebGUI prepares precached content?
Is there any option in WebGUI to employ point(s) 2) and/or 3) through it, or is one now supposed to "manually" add the required tags as assets's extra head elements and/or set them in httpd.conf?
jcook's reply
Thanks for the Info. we deployed both Meta & apache mod to make sure
comment:3 Changed 15 years ago by kmaclean
from WebGUI/Lib/WebGUI/Style.pm:
=head2 process ( content, templateId ) Returns a parsed style with content based upon the current WebGUI session information. Sets the C<sent> method/flag to be true so that subsequent head data is processed right away. =head3 content The content to be parsed into the style. Usually generated by WebGUI::Page::generate().
...
sub process { ... if ($self->session->user->isInGroup(2) || $self->session->setting->get("preventProxyCache")) { # This "triple incantation" panders to the delicate tastes of various browsers for reliable cache suppression. $var{'head.tags'} .= ' <meta http-equiv="Pragma" content="no-cache" /> <meta http-equiv="Cache-Control" content="no-cache, must-revalidate, max-age=0, private" /> <meta http-equiv="Expires" content="0" /> '; $self->session->http->setCacheControl("none"); } else { $var{'head.tags'} .= '<meta http-equiv="Cache-Control" content="must-revalidate" />' }
comment:4 Changed 15 years ago by kmaclean
previous code actually from WebGUI/lib/WebGUI/Session/Style.pm:
comment:6 Changed 15 years ago by kmaclean
see this link: Cache & If-Modified-Since
comment:10 Changed 14 years ago by kmaclean
comment:11 Changed 14 years ago by kmaclean
- Status changed from new to closed
- Resolution set to fixed
Fixed with upgrade to WebGUI 7.4.20
comment:12 Changed 14 years ago by kmaclean
- Status changed from closed to reopened
- Resolution fixed deleted
Bug report on WebGUI
Cache & If-Modified-Since
User: TjECC Date: 11-June-2007 3:52 pm
WebGUI current
In WebGUI.pm beginning @ line 133 ther is the line that checks the 'If-Modified-Since' header for a value. There is also cache control logic in WebGUI::Session::Http that handles some of this.
I have had to comment out lines 132-137 & 139 in WebGUI.pm because no matter what happens, it breaks the site. I'll have users (visitors) emailing us because they haven't seen any new news on the site for a week, or a returning user (visitor) from a long time ago keeps getting the cached version of the page.
I might be missing something here, but the logic of the code reads to me as follows...
I've looked around the source, and unless I've missed something, or there's something going on with the Apache API, it seems to me that nothing is removing the If-Modified-Since header if the document is updated.
This has been around for a while for our site and I've just kept the lines commented out, but I'm surprised nobody else has ran into an issue with more dynamic content that is regularly updated.
Any ideas?
Thanks,
Troy
JT's reply:
User: JT Date: 13-June-2007 9:14 am
That's because in order to check if the content has been modified it would have to instantiate the asset or assets in question and make that determination. And at that point we might as well serve up the whole page again.
However, that's not to say that this is a bug. It's doing what it's supposed to do. As a content publisher you're supposed to set the cache timeout on things so that the browser automatically deletes them after a while, and then it won't send an if-modified-since, and therefore WebGUI won't have anything to reply to with content not modified.
If there is indeed a bug somewhere, which I cannot verify at the moment, then it would be in the logic that sets the time to live on the page, not the if-modified-since logic. From your description, it's working as it is supposed to work.