- From: Yaron Goland <yarong@microsoft.com>
- Date: Tue, 4 Mar 1997 22:02:25 -0800
- To: "'Larry Masinter'" <masinter@parc.xerox.com>
- Cc: "'dgd@cs.bu.edu'" <dgd@cs.bu.edu>, w3c-dist-auth@w3.org
Larry, it would appear that you only read the first part of the post where I propose URL mangling. However that was a straw man proposal. The second part of the post then proposes the use of a method which takes as input a particular range type and provides a server generated URL in the content-location header of the response. Thus the client does not perform any kind of URL mangling. I have provided a fully copy of my original post below, it can also be retrieved at http://lists.w3.org/Archives/Public/w3c-dist-auth/msg00645.html. Yaron Goal: To provide locking for defined subsections of a document Problem: DAV only supports locking on URLs, as URLs are given to a resource as a whole, DAV can not currently handle a partial lock Solution: Give subsections URLs. Example: Byte Ranges - A client searches for the attribute "xssdfsyhw30rwfwofjslfihleihfsfe" which is a token meaning "I give you permission to mangle the URL for this resource to point to a byte range in a defined way, specifically, you may add a "#" followed by a number, followed by a dash, followed by another number". The client then sends http://foo/bar#12-23 in a lock request. The result is that bytes 12 to 23 are locked. Obviously the example doesn't provide all the semantic requirements but it is just a taste of the underlying mechanism. Problem: Mangling Overload. It is very nice and good to mangle a URL w/permission from the server, but at some point the various mangling mechanisms are going to run into each other. Potential Solution: A byte range method called ByteHead =). A range header is included to specify the byte range, although it can be used to specify any arbitrary range such as chapter or page. The request-URI is the request-URI of the resource. The response contains a content-location header which is the URL pointing to the relevant range. The rest of the response contains the same thing as a HEAD request done on the URL contained in content-location. Problem: Two round trips for every single lock request. Solution: A convenience method which combines ByteHead with Lock, we can call it LocksByte. Yaron > -----Original Message----- > From: Larry Masinter [SMTP:masinter@parc.xerox.com] > Sent: Tuesday, March 04, 1997 8:42 PM > To: Yaron Goland > Cc: 'dgd@cs.bu.edu'; w3c-dist-auth@w3.org > Subject: Re: Last call: range locking > > (in reply to 26 Feb 1997 message re: range locking not used in > Groupwise) > > Having the server give the client permission to mangle URLs > is a pretty ugly way to get your URLs mangled. Besides, what > we've learned is that the very same server may have different > requirements for different parts of its address space, and the > permission-to-mangle scope is not easily characterized by > URL patterns. (The realm of cookies isn't a good design to > follow). > > Because of this, rather than having the server give the client > permission to do a particular kind of mangling, you're better > off having the server return the mangled URL directly as the > result of a request. > > So, while your "Goal/ Solution" are OK ("give subsections URLs"), > the example you gave (using a particular attribute to denote > that a particular kind of URL-manging is OK) is not, or at least, > is not in service of the WEBDAV goal of fostering interoperability > between authoring clients and versioning servers. > > Regards, > > Larry > > > -- > http://www.parc.xerox.com/masinter
Received on Wednesday, 5 March 1997 01:02:23 UTC