I am going to try sending a combination of Expires and Last-Modified and see
if this can induce IE both to send subsequent requests and to include the
If-Modified-Since header. (Will test with Firefox as well). Based on my
reading of the spec, this should work.
I'll also take a look at the aggregated front page case, assuming I can
figure out how to set that up. If this doesn't send Last-Modified headers,
I suspect it will work exactly like 2.3 in skirting the staleness issue.
In the cases I diagnosed to date, the problem was that IE with its checking
policy set to its default ("Automatically"), was not sending requests at
all.
In cases where we were not sending Last-Modified dates at all, IE under the
Automatic setting would revert to checking every time with no
If-Modified-Since header. This works as expected. It also explains why the
front page worked with IE in 2.3 but not in 3.0.
To get IE to work properly in the general case I had to set IE to "Check on
Every Visit" which causes it to make a request and send If-Modified-Since
headers when possible. This was also working as expected; I did not see any
of the millisecond granularity issues if there were any when I tested.
--a.
----- Original Message -----
From: "Allen Gilliland" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, September 04, 2006 12:23 PM
Subject: Re: problems with 3.0 on IE
Craig L Russell wrote:
Sorry if this is noisy, but if the http header handling of last modified
truncates the current date, we should know the truncation algorithm and
use it in the cached Date.
We know the precision of Date: it's milliseconds. If the http headers
truncate to the nearest second, then Date will "always" (well, 999 times
out of a thousand ;-) be a mismatch.
What if we always truncate Date to the same precision as http headers
use?
yep, that's what I do ...
lastModified = lastModified - (lastModified % 1000);
I truncate the milliseconds from the lastModified long value before using
it in the situations where this applies and I have tested and verified
that this works properly on firefox.
My message below was meant to tell Anil about this in case he wanted to
verify that this isn't causing part of the problem with IE and the cache
control http headers. I only tested this on firefox, so although it would
be unlikely, it's possible that my solution isn't working properly for IE.
-- Allen
Craig
On Sep 4, 2006, at 11:44 AM, Allen Gilliland wrote:
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.
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
