W3C home > Mailing lists > Public > www-jigsaw@w3.org > May to June 1996

Big problem with lastModified and IfModifiedSince.

From: Anselm Baird-Smith <abaird@w3.org>
Date: Fri, 21 Jun 1996 19:16:42 +0500
Message-Id: <9606212316.AA06179@www18.w3.org>
To: alex@access.com.au (Alexandre Rafalovitch)
Cc: www-jigsaw@w3.org
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 9 April 2012 12:13:25 GMT