Big problem with lastModified and IfModifiedSince.

Alexandre Rafalovitch writes:
 > Hi,
 > 
 > I am trying to do something like DirectoryResource does and save some time
 > on requests by keeping htmlized version of my data in local variable and
 > reparsing it only when original data changes. This way if a client provides
 > If-Modified-Since header, I can reply with NOT_MODIFIED.
 > 
 > To achieve this, I have to jungle with three variables, listing_stamp for
 > my html version, lastModified as received from getLastModified() and ims
 > from request.getIfModifiedSince(). The problem is that some rounding
 > happens along the way and that breaks my checks of modified/non modified
 > nature.
 > 
 > I will give an example:
 > I have a resource with lastModified = 835349864096 which should be equal to
 > GMT string
 > '21 Jun 1996 09:37:44 GMT'. I parse the data and set my listing_stamp to
 > the same value.
 > When I send the reply, I set the header LastModified with that value too.
 > When I get the next request for the same place, I get IMS header with value
 > 835349864000 which gives me GMT string
 > '21 Jun 1996 09:37:44 GMT'.

Ah ! Ok, you are htting a well-know problem with ifModifiedSince wich
is that as it is set as a HTTP-Date, it doesn't go further then a
second resolution. It looks like your stuff is changing at a higher
rate (?)

 > I can provide sample code showing what I mean, if it was not clear. I am
 > actually suprised that it seems to work for DirectoryResource and
 > FileResource. Maybe I should try it under the same fire, I put my own
 > resources through...

It works because you don't actually expects it to be below the one
second resolution of the IfModifiedSince header. Wait for the 1.1
implementation, wich can cope with < 1 second "validators"

Anselm.

Received on Friday, 21 June 1996 19:16:52 UTC