Re: range locking not used in GroupWise

On Fri, 28 Feb 1997, Larry Masinter wrote:

> What you were calling a "validator" is called an "ETag" in HTTP/1.1
> (because we got into a knot over the meaning of 'validation'), and
> the ETag for a "version" of a resource is for the whole resource
> and not for any particular byte range.
>

Right, and I intentionally chose validator instead of entity tage because I
was referring to a non-existant validation mechanism.
 
> > The problem is that if
> > resource R is represented by a 1000 byte entity, and person A has already
> > obtained byte ranges B1 and B2 representing bytes 0-500 and 501-1000
> > respectively, and both are available in cache, then if that person wants to
> > GET the resource (not a byte range), then the corresponding entity E is the
> > union of B1 and B2, and so it should not be necessary to transer the whole
> > entity, a revalidation should be sufficient. But how can this be done? Even
> > if the byte ranges have their own validators e1 and and e2, there is no
> > relationship between the pair (e1,e2) and a validator e for R.¸
> 
> The ETag returned is that for the entire entity and not for the
> subranges. It was important that caches be able to stitch together
> whole entities from partial ranges in order to satisfy subsequent
> requests. So byte ranges *don't* have their own "validators".
> 

This is another way of saying the same thing. If entity tags refer to
entire entities, then it is possible to build an entity out of individually
cached subranges. My point was simply that if modifying a resource doesn't
invalidate all cached subranges (even those not affected), then there is no
way to know if a union of subranges will be equal a valid (up to date)
entity. I then concluded that there is nothing to be gained by locking a
subrange (whtever that might mean) because the entity tag will change with
an update, and so even byte ranges which are disjoint from the affected
range will become invalid.

> 
> 
> --
> http://www.parc.xerox.com/masinter
> 

---
gjw@wnetc.com    /    http://www.wnetc.com/home.html
If you're going to reinvent the wheel, at least try to come
up with a better one.

Received on Saturday, 1 March 1997 11:04:41 UTC