Ticket #134 (closed defect: fixed)

Opened 16 years ago

Last modified 15 years ago

Browser Caching issues require page reload when signed-on to site

Reported by: kmaclean Owned by: kmaclean
Priority: minor Milestone: WebSite 0.2.1
Component: Web Site Version: 0.1-alpha
Keywords: Cc:


the page caching in browsers causes funny effects sometimes. I first went to the Downloads section before registering/logging in. Later, I visited that page again, but despite having logged in in the meantime, the old version of the page (without the "Add" link) was shown from the browser's cache. That puzzled me for a minute!

Yes, this is a known issue with WebGUI (the CMS we use) and I am still waiting for a fix. Basically if you sign-on when you first navigate the site, you should have not problems, but if you navigate as a visitor and then sign-on, and click around some more, then you may need to hit your refresh key - very annoying.

See explanation by JT here- basically he says: In the past we weren't following the W3 specifications for cache headers. Now we are following those rules and it's causing some problems for some people. We're still trying to decide what to do about it, because we weren't doing it the right way before, and now we are, but the right way causes problems. You can see that it's quite a predicament.

Anyway, for the time being turn on prevent proxy cache in your site's settings. That should clear up any problems that your users are having.

But I think prevent proxy cache causes problems with URL???

Change History

comment:1 Changed 16 years ago by kmaclean

Explanation from JT on what occurs if proxy cache is turned off:

it simply adds some post query information to your URLs. So your URLs will be uglier for the time being, but the cache problem will go away.

comment:2 Changed 16 years ago by kmaclean

Ignore previous entry!

Explanation from JT on what occurs if you turn on prevent proxy cache in your site's settings:

it simply adds some post query information to your URLs. So your URLs will be uglier for the time being, but the cache problem will go away.

This would likely affect any outside links to the site and search engine rankings ...

comment:3 Changed 16 years ago by kmaclean

But ... other users had problems when they turned on prevent proxy cache:

Prevent Proxy Caching is not playing nicely with other URL generating items in WebGUI: e.g. the "/;" macro does not work properly

comment:4 Changed 16 years ago by kmaclean

Another bug report on caching and Firefox:

(see www.plainblack.com/bugs/tracker/caching-in-firefox)

User said: there's something wrong with the settings for visitor-caching when using Firefox. If you log in as registered user and revisit a page that you already visited as visitor, Firefox will give you the same page from the cache. Clicking refresh in the browser solves the issue.

To reproduce on demo.plainblack.com with Firefox 1.5.x:

  1. (As visitor) Click "Getting Started", click "Your next step", click "Latest News", click "Tell a Friend", click "Site Map".
  1. Log in as Admin
  1. Go back to step 1

JT replied: That's not a bug. Firefox is pulling the page from your cache, and therefore doesn't know that the page has been changed on the server (by you logging in) until you refresh.

comment:5 Changed 16 years ago by kmaclean

Another link with more information, basically saying it needs to be submitted as an RFE because WebGUI is following the W3C requirement:


comment:6 Changed 16 years ago by kmaclean

  • Status changed from new to closed
  • Resolution set to fixed

fixed with last WebGUI upgrade

comment:7 Changed 15 years ago by kmaclean

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'


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



comment:8 Changed 15 years ago by kmaclean

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.

comment:9 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?

comment:10 Changed 15 years ago by kmaclean

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): 1) Via <meta> tags (<meta http-equiv="Expires"...>) 2) Programmatically by setting HTTP headers (CGI scripts etc.) 3) 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?

Note: See TracTickets for help on using tickets.