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!
