Thanks for looking into this Anil, it's definitely a bit unfortunate
that IE is causing this problem. I would imagine that lots of other
websites have this problem since it's not at all uncommon to have pages
that change frequently throughout the day.
One thing you can possibly look into is some debugging/comparison on the
Last-Modified and If-Modified-Since headers that are used on the
frontpage if it's set to aggregated mode. The dates for those headers
are managed differently than the ones for weblogs because when the
frontpage is in aggregated mode, meaning it is expected to show
site-wide data, then you can't rely on the weblog.lastModified attribute
to have the right date.
If you look in the PageServlet you'll see what I mean. For the
aggregated frontpage the lastModified date used for the cache control
headers is actually kept cached in memory in the SiteWideCache class.
Normally this wouldn't be of any concern, but I noticed during
development that when that cached Date object is actually set as the
Last-Modified header it loses some precision, and so the actual long
value you get from the Date.getTime() and the value you get from the
If-Modified-Since header will almost always be non-equal due to the
difference in precision. Namely, the long you get from the cached Date
object will be some # of milliseconds ahead of the version you get from
the If-Modified-Since header, which is truncated when it gets passed
through the http headers. This basically means that the header will
always be a matter milliseconds behind the cached Date and if you
compare them directly then the header will always make it seem like the
content has been modified.
To fix this I had to correct for that loss of precision so that the
cache control would actually work properly, you can see what's happening
in the PageServlet where I left a long comment about this. In any case,
I only checked this functionality on firefox during development, so it's
possible that IE works a bit differently and there is possibly still
some kind of problem when doing the cache control checking in IE. If
you set the PageServlet to DEBUG mode it should be pretty easy to check
this since the debug messaging shows both the lastModified and
ifModifiedSince dates that it is using for its comparison. So you can
see what date gets set for Last-Modified and what date it gets back and
uses for comparison on the next request.
Of course, all of that is completely mute if IE is just bypassing the
use of the cache control headers, but it's something that can be checked.
-- Allen
Anil Gangolli wrote:
OK. I confirmed that Roller 2.3 does not send Last-Modified headers for
certain (possibly all) struts actions, particularly main.do which serves
the front page in 2.3, but it does send the Last-Modified header for
blog pages.
Wherever Roller 2.3 does send the header, I see exactly the same issue
with IE set to the "Automatic" setting, so the issue is not a new
3.0-specific one as I had first thought.
What *is* new and initially caught my attention is that in Roller 3.0 we
now see this staleness behavior in IE on the front page, because the
front page is actually associated to a blog page, and gets the
Last-Modified header.
Upshot: I think we should continue the current 3.0 behavior, but I
won't be surprised if we later get requests to make it configurable, at
least for the front page to avoid the issue with default IE settings.
We should wait for that though.
--a.
----- Original Message ----- From: "Anil Gangolli" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Sunday, September 03, 2006 11:28 PM
Subject: Re: problems with 3.0 on IE
Yep. I agree. I'm not sure if there is anything to do here. I'll
be trying to understand this further; I'll try to compare what's
happening with 2.3 and 3.0 more carefully before making a recommendation.
--a.
----- Original Message ----- From: "Allen Gilliland"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Sunday, September 03, 2006 10:47 PM
Subject: Re: problems with 3.0 on IE
eeks. I don't think changing our app to not send Last-Modified
headers is the right approach. The Last-Modified header is an http
standard and if IE is doing something wrong with it then that's their
fault, not ours.
I think that everything that you listed in your bullets below is
correct behavior for the cache control. A browser can only send an
If-Modified-Since header if it has gotten a Last-Modified header, and
it sounds like when the headers are present (like in firefox) then
everything works properly.
It's not really our fault if IE is being overly aggressive about its
caching.
-- Allen
Anil Gangolli wrote:
Scratch the fourth bullet. We are sending a Last-Modified header in
2.3, so I still don't know what's different between 3.0 and 2.3
----- Original Message ----- From: "Anil Gangolli"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Sunday, September 03, 2006 7:37 PM
Subject: Re: problems with 3.0 on IE
Here's what I found:
- Apparently a recent MS update had reset my caching preferences to
allow IE to decide whent to check for modified pages
"automatically", (the meaning of which is described here:
http://support.microsoft.com/?kbid=263070). In the cases I
diagnosed, the browser was indeed, as Allen thought, not even
sending a request.
- If I change IE's cache control policy to check on "Every visit
to the page", I see requests from IE carrying If-Modified-Since
headers and what looks like correct cache behavior stepping through
PageServlet.
- It appears that "Automatically" is the default setting that IE
ships with.
- If we don't send "Last-Modified" headers and I keep the defaul
"Automatically" setting, IE appears to send requests every time,
but with no If-Modified-Since header at all.
- It appears that in trunk and 2.3 we were not sending the
"Last-Modified" header. That code is commented out, without an
explanation. (Anyone recall why? Did it have anything to do with
IE?) I think this might explain the difference in behavior I'm
seeing with 2.3.
I think we might want to add a configuration parameter to control
whether or not to send the Last-Modified header, or spend more time
figuring out a way to work properly with IE's default setting.
--a.
----- Original Message ----- From: "Allen Gilliland"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Saturday, September 02, 2006 11:07 PM
Subject: Re: problems with 3.0 on IE
Anil Gangolli wrote:
----- Original Message ----- From: "Allen Gilliland"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, September 01, 2006 9:18 AM
Subject: Re: problems with 3.0 on IE
Anil Gangolli wrote:
I'm seeing several odd problems with 3.0 on IE 6 on my local
build. I seem to be getting stale versions of pages unless I
load bypassing the cache.
I don't see how the caching could be having a different affect
from one browser to the next. What do you mean "bypassing the
cache"?
I mean forced reload which tells the browser to (a) ignore its
local cache (b) don't send an If-Modified-Since header.
gotcha.
It's possible it's just bad browser caching. I know that
firefox can be really tricky with browser caching if you aren't
careful, especially with feeds. I know for a fact that there
are times in firefox when it won't even sent a request for a
page to check 304, it will just automatically use the browser
cache, although i haven't figured out the exact conditions for
that yet.
I haven't diagnosed it yet, but I suspect it is that we are not
responding properly to some IfModified-qualified requests.
That's possible, I never use IE so I can't say that everything is
tested as well in IE. I know that one thing that can cause
problems with if-modified headers is date conversions, if for some
reason IE is doing something even just a few milliseconds
different from the application that can cause the 304 checking to
be wrong.
-- Allen
Note: There are no proxies or intermediate servers between the
browser and my dev Tomcat running on the same host.
Has anyone else seen this with IE on current 3.0 builds? I don't
want to hold anything up if it is a personal setup issue.
-- Allen
Is anyone else testing with IE?
I don't see the same problem with Firefox.
This is specific to 3.0. I'm not seeing this on 2.3.
I've just started looking into it, but hesitant to call this a
release candidate without it.
--a.
