W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1997

Re: If-None-Match and IMS (new Issue IMS_INM_MISMATCH)

From: Ted Hardie <hardie@thornhill.arc.nasa.gov>
Date: Wed, 12 Nov 1997 13:27:22 -0800
Message-Id: <9711121327.ZM9626@thornhill.arc.nasa.gov>
To: Jeffrey Mogul <mogul@pa.dec.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4656
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.

				Ted Hardie
Received on Wednesday, 12 November 1997 13:30:26 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:21 UTC