User problems with the browser cache
August 25, 2009 12:12 PM Subscribe
A commercial Web-based product our university purchased to provide student account summaries and collect tuition payments works well for 98%+ of the users. It only works for the rest, however, if they first clear their browser cache.
I've surfed the Web for years, visiting hundreds of commercial sites, and have never had to clear my cache in order to make a site work for me. With this product, users open the first page of the site but sometimes get only a white screen with "Done" at the bottom of the window.
Why is this cache clearing necessary? A flaw in the code/design or a fact of browser life?
Some technical details if they matter: The product is Java-based, running on Red Hat Enterprise Linux, and serving jsp pages with Tomcat. Most users use IE (IE8 users are instructed to press IE8's "Compatibility" button). The first page has "no-cache" directives.
I've surfed the Web for years, visiting hundreds of commercial sites, and have never had to clear my cache in order to make a site work for me. With this product, users open the first page of the site but sometimes get only a white screen with "Done" at the bottom of the window.
Why is this cache clearing necessary? A flaw in the code/design or a fact of browser life?
Some technical details if they matter: The product is Java-based, running on Red Hat Enterprise Linux, and serving jsp pages with Tomcat. Most users use IE (IE8 users are instructed to press IE8's "Compatibility" button). The first page has "no-cache" directives.
The Pragma: no-cache header by itself isn't always honored. There should be some Cache-Control and Expires headers in there too.
Are users seeing the cached page when they visit for the first time ever? If so, it could be that Tomcat and/or any other proxies sitting in front of the site are doing the caching rather than the browser, but in any case, it ought to be addressable with the right headers. Talk to your vendor.
posted by enn at 12:36 PM on August 25, 2009
Are users seeing the cached page when they visit for the first time ever? If so, it could be that Tomcat and/or any other proxies sitting in front of the site are doing the caching rather than the browser, but in any case, it ought to be addressable with the right headers. Talk to your vendor.
posted by enn at 12:36 PM on August 25, 2009
Sometimes that's the result of invisible caching servers between your server and the user.
posted by Chocolate Pickle at 12:36 PM on August 25, 2009
posted by Chocolate Pickle at 12:36 PM on August 25, 2009
Yeah, this does sounds like Peoplesoft. As someone who has applied to a bunch of jobs using that crappy software recently, I can let you know that if you solve this problem you will be a real leader in your field. Most Universities I have applied to use it, and they all have this same stupid problem. I will sometimes have to clear my cache and start over in the middle of an application.
posted by Ignatius J. Reilly at 12:51 PM on August 25, 2009
posted by Ignatius J. Reilly at 12:51 PM on August 25, 2009
Response by poster: Foci for Analysis:
Sent the link to you in MeFi Mail.
IE7, IE8, and Firefox users report the problem.
enn:
All the cache-related headers:
response.setHeader("Pragma", "no-cache");
response.setDateHeader("Expires", 0);
response.setHeader("Cache-Control", "no-cache");
We don't know if the problem occurs first-time-ever.
rbs:
Amazingly, it's not PeopleSoft.
posted by davcoo at 1:00 PM on August 25, 2009
Sent the link to you in MeFi Mail.
IE7, IE8, and Firefox users report the problem.
enn:
All the cache-related headers:
response.setHeader("Pragma", "no-cache");
response.setDateHeader("Expires", 0);
response.setHeader("Cache-Control", "no-cache");
We don't know if the problem occurs first-time-ever.
rbs:
Amazingly, it's not PeopleSoft.
posted by davcoo at 1:00 PM on August 25, 2009
davcoo, got the link. I'm thinking that the site maybe is using cookies incorrectly. It sets a JSESSIONID cookie. Maybe you could try deleting it and see what happens?
It's probably not related to this problem, but the W3C validator returns 86 Errors and 11 warnings on the start page. Yikes.
posted by Foci for Analysis at 1:15 PM on August 25, 2009
It's probably not related to this problem, but the W3C validator returns 86 Errors and 11 warnings on the start page. Yikes.
posted by Foci for Analysis at 1:15 PM on August 25, 2009
This isn't exactly a solution, but maybe you could decompile the java search for "done" then replace "done" with a javascript redirect to a page instructing the user to clear their cache.
posted by gregr at 1:15 PM on August 25, 2009
posted by gregr at 1:15 PM on August 25, 2009
Response by poster: Thanks, you've given me some excellent leads. When I make some headway on this, I'll add a post here.
posted by davcoo at 1:53 PM on August 25, 2009
posted by davcoo at 1:53 PM on August 25, 2009
Does the page load up things like dynamically-generated JavaScript? You might need to adjust the headers for other files.
Have you checked whether those anti-caching headers are reaching the browser, rather than being removed by a proxy?
Also check the server's clock is correct, just in case that's affecting caching (e.g. if something other than 0 is used for Expires somewhere).
These kinds of problems are often indicative of fundamental flaws in the design of the application. Some web developers, especially those without broad web skills, have some funny ideas about how to handle requests, generate pages and authenticate users.
posted by malevolent at 2:00 PM on August 25, 2009
Have you checked whether those anti-caching headers are reaching the browser, rather than being removed by a proxy?
Also check the server's clock is correct, just in case that's affecting caching (e.g. if something other than 0 is used for Expires somewhere).
These kinds of problems are often indicative of fundamental flaws in the design of the application. Some web developers, especially those without broad web skills, have some funny ideas about how to handle requests, generate pages and authenticate users.
posted by malevolent at 2:00 PM on August 25, 2009
If you really want to debug this you need a packet capture. Nothing else will have the required detail. Run wireshark on a machine where it can be reproduced, and use the site until it happens. Then you start digging through the log.
posted by Rhomboid at 8:30 PM on August 25, 2009
posted by Rhomboid at 8:30 PM on August 25, 2009
And gregr, I think he meant that the status bar in the browser says "Done", i.e. the response from the server was a null document.
posted by Rhomboid at 8:31 PM on August 25, 2009
posted by Rhomboid at 8:31 PM on August 25, 2009
This thread is closed to new comments.
posted by Foci for Analysis at 12:30 PM on August 25, 2009