- From: Alexandre Rafalovitch <alex@access.com.au>
- Date: Fri, 21 Jun 1996 20:03:07 +1000
- To: www-jigsaw@w3.org
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'. Surprise, surprise. It seams that by some reason some rounding happens along the route. I assume it could happen because IMS is sent along in GMT format and it gets truncated. Actually, if I turn 835349864096 into Date, into GMT string, back parsed by Date to give long I would get expected 835349864000. That is all fine, but I have no idea, if that is the way it should work and I would have to do triple conversion just so I could compare those dates. Or is there any other reasons and I was just trying to reach my nose through under my left leg? :-} 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... Alex. --------| I feel as confused as a baby in a topless bar. |--------
Received on Friday, 21 June 1996 06:05:08 UTC