- From: Gregory J. Woodhouse <gjw@wnetc.com>
- Date: Thu, 27 Feb 1997 23:03:40 -0800 (PST)
- To: Larry Masinter <masinter@parc.xerox.com>
- cc: Yaron Goland <yarong@microsoft.com>, "'Steve Carter'" <SRCarter@gw.novell.com>, "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
This is interesting. Caching in HTTP works precisely because it implememnts the immutable file model of a distributed file system...or at least that's the way I tend to think about it. Your point that entities are immutable and reources are not is, of course, correct. The difference is that I think of the combination of a resource and a validator for that resource (think of it as a version, something like a version number of an OpenVMS file) as the immutable object. On Wed, 26 Feb 1997, Larry Masinter wrote: > Byte ranges (in HTTP range retrieval) don't apply to resources. > They apply to entities. An entity is the data stream that > you get when you perform a GET operation. Servers are free > to ignore byte range requests and deliver the entire > entity rather than the indicated range. > I'm not sure about this one. Certainly, if a resource is modified, a byte range may become an inaccurate representation of that resource (or, perhaps I should say valid entity), and in this sense I agree with you. But byte range requests are made against resources and not entities. It seems that the real point is that the link between a byte range and a reource is a transient thing, whereas the link between a byte range and an entity is permanent. > Resources don't have "byte ranges". Entities are immutable. > They don't change. Since they don't change, it doesn't make > sense to lock one or even lock part of one. > I'm not quite sold. As I indicated in an earlier message, it may be that a byte range lock is not a useful concept, but it is still meaningful. For the purposes of this post I will define a version of a reource to be a resource together with a unique validator for that resource. With this definition, it makes sense to require that new versions of a resource can only be created subject to the constraint that the byte range 0-500 is the same for both versions. (I know this use of version is not consistent with WEBDAV terminology, but it saves a lot of words.) Surely, this is a meaningful requirement. Is it a useful concept? I don't know. The problem is that byte ranges need to be independently cacheable or there is no advantage in locking a byte range instead of locking the whole resource. 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. (Sorry for all the "symbol speak". I guess my background in mathematics is catching up with me.) [...] --- 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 Friday, 28 February 1997 02:05:29 UTC