- From: Lou Montulli <montulli@mozilla.com>
- Date: Wed, 16 Aug 95 23:35:51 -0700
- To: Brian Behlendorf <brian@organic.com>
- Cc: Lou Montulli <montulli@mozilla.com>, Simon Spero <ses@tipper.oit.unc.edu>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
In article <Pine.SOL.3.91.950816222536.604K-100000@eat.organic.com> Brian Behlendorf <brian@organic.com> wrote: > > On Wed, 16 Aug 1995, Lou Montulli wrote: > > In article <Pine.SOL.3.91.950816205717.5252C-100000@chivalry> Simon Spero > > <ses@tipper.oit.unc.edu> wrote: > > > > > > > > > 2) The problem as described above is caused by problems at the > > > server side; the cure can also be localised to the server-side > > > without protocol modifications- for example, the server can keep > > > a record of the incorrect dates that have been changed, and always > > > retransmit the document if it recieves a request containing one of > > > the bad dates. > > > > > > This solution is too costly to implement in existing servers, > > BS - the server can easily go "oh, that IMS date is past my current time. I > will presume it's erroneous and send the full copy". It doesn't have to > remember the dates that were sent out, or the files those dates were attached > to. > > Here's the algorithm of IMS requests: > > Variables: IMS = If-Modified-Since date > LM = Server's last-modified > CURRTIME = The current time on the *server* > > 1) if IMS < LM send document > 2) if IMS > CURRTIME send document > that leaves LM < IMS < CURRTIME for the 304 response. Brian you should go read the spec or past messages before you post stuff like this. As pointed out earlier in this thread the IMS time can be after the current last modified date of the file and still be valid. Changing this is not an option. > > > Your "solution" also fails when the file has been modified but > > has the same date. > > Can we just agree (feel like rodney king here) that this is a broken case > and not worth wasting time on? Modified files can also have the same > size, even the same checksum if we try hard enough. > No, I'm afraid we can't. Not when it is as easy to solve as sending a length along with the IMS request. :lou -- Lou Montulli http://www.mcom.com/people/montulli/ Netscape Communications Corp.
Received on Wednesday, 16 August 1995 23:37:22 UTC