- From: John Franks <john@math.nwu.edu>
- Date: Tue, 4 Jun 1996 17:34:03 -0500 (CDT)
- To: Jeffrey Mogul <mogul@pa.dec.com>
- Cc: "Roy T. Fielding" <fielding@liege.ICS.UCI.EDU>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
On Tue, 4 Jun 1996, Jeffrey Mogul wrote: > Koen: > > always assumed that > > the Last-Modified header applied to the variant, not to the whole > > resource. > > Roy: > It applies to the resource as a whole, which explains why the definition > was the way it was (i.e., specified in terms of how the recipient will > interpret it) and should be. > > I agree with Koen on this one. At the very least, it should be at > the origin server's option to decide whether to keep distinct > Last-Modified dates for each variant, or to use the maximum > over all of the variants of a resource. > > Whether or not this has been easy for the CERN and Apache servers > is basically irrelevant, since I see no reason why the protocol > specification should require it, and it might be much harder to > implement in other contexts. > I agree with Koen and Jeff. Also I don't understand in what circumstances one would want the L-M date to be the maximum over all variants. If one variant changes and all the others don't why do you want to invalidate the cached copies of all the other variants? It seems like a waste of bandwidth. Of course, making it be the max over variants would provide a strong incentive for caches to start using If-None-Match instead of I-M-S, and that would be a "good thing." John Franks Dept of Math. Northwestern University john@math.nwu.edu
Received on Tuesday, 4 June 1996 15:37:08 UTC