Visitor Caching

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...

1. If the request headers (inbound) contains the header 'If-Modified-Since' AND 2. The user is a visitor THEN Don't check the date on the 'If-Modified-Since' and see if it would make sense to send an updated copy, just send back 304, Content not modified.

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.

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

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" />'
}

previous code actually from WebGUI/lib/WebGUI/Session/Style.pm:

caching has changed in newest WebGUI release

see this link: Cache & If-Modified-Since

WebGUI forum entries:

Cache Problem

Cache & If-Modified-Since

article: Prevent the browser from Caching a page

How Web Caches Work

Tips for Building a Cache-Aware Site

Cacheability Engine

Fixed with upgrade to WebGUI 7.4.20