Re:Big problem with lastModified and IfModifiedSince.

At 7:16 PM on 21/6/96, Anselm Baird-Smith wrote:

> 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 think the reason I get  further than second resolution, is because my
lastModifiedDate is getLastModified() of the resource which has
milliseconds resolution (since it uses System.getCurrentTime() or sume
such). On another hand, filesystem also has second resolution (?) so it
has no problem with rounding.
That means if (when) my resource would calculate lmt based on file lmt, my
problem would go away.

Does that seems reasonable explanation?
         Alex.
Ps. If it is true, it might be a good warning for newbies. At least until
Jigsaw Alpha2 will arrive (when?).

alex@access.com.au

Received on Sunday, 23 June 1996 20:39:23 UTC