- From: Ted Hardie <hardie@thornhill.arc.nasa.gov>
- Date: Wed, 12 Nov 1997 13:27:22 -0800
- To: Jeffrey Mogul <mogul@pa.dec.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
On Nov 12, 12:22pm, Jeffrey Mogul wrote: > This is not quite the same thing; allowing INM to supersede IMS > unconditionally might be wrong if the INM contained a "weak" > entity tag. However, with a strong entity tag, there should be > no practical difference between Dave's interpretation and the > more conservative one ... except in those rare cases where a > resource's modification date changes, but its value does not. > > >-- End of excerpt from Jeffrey Mogul Actually the case where the resource's modification date changes without its value changing is more common than you'd think, because of how people implement dns-load balancing to improve performance. >From what I've seen, it's common for changes to be made on one machine and those changes propogated to the other machines in the response group. Unless you're very careful with that propogation, it's easy for the modification time to change as a result of the movement. Since there is no guarantee that a client checking back on a resource will get the same member of the response group as it originally got, you can pretty easily run into this case. Good implementation advice on the issue would, however, solve the problem in most cases. I don't think that changes the logic you've applied to the situation; I do believe, however, you'll get a non-trivial number of cases where that conservative approach will result in the transmission of a resource that is the same as the one the client has. regards, Ted Hardie NASA NIC
Received on Wednesday, 12 November 1997 13:30:26 UTC