W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 1997

RE: Change to Lock-Token

From: Yaron Goland <yarong@microsoft.com>
Date: Mon, 24 Mar 1997 15:56:46 -0800
Message-ID: <11352BDEEB92CF119F3F00805F14F485026B7285@RED-44-MSG.dns.microsoft.com>
To: "'masinter@parc.xerox.com'" <masinter@parc.xerox.com>, Jim Whitehead <ejw@ics.uci.edu>
Cc: w3c-dist-auth@w3.org
The problem is that e-tags are opaque and we really need to be able to
put lock tokens into if-match headers. Are we going to be forced to
invent our own "if-match" header for lock tokens or can we extend the
if-match syntax to accept tokens?

My feeling is that lock tokens should be URIs (this also gives the
possibility of having cross server locks on day, FAR FAR FAR into the
future =) and that we should extend the e-tag if headers to accept
tokens instead of just quoted strings.


> -----Original Message-----
> From:	Larry Masinter [SMTP:masinter@parc.xerox.com]
> Sent:	Monday, March 24, 1997 10:34 AM
> To:	Jim Whitehead
> Cc:	w3c-dist-auth@w3.org
> Subject:	Re: Change to Lock-Token
> > 2) Identity.  While a strong entity tag will correspond to the
> resource
> > when a lock is taken out on that resource, as soon as the resource
> is
> > changed its entity tag (strong for sure, weak potentially depending
> on the
> > scope of the change) will also need to change.  If intermediate
> results are
> > saved to the HTTP server before the lock is released, the lock token
> will
> > no longer correspond to the actual entity tag of the resource.
> This is a good argument for why lock tokens shouldn't be used as
> entity
> tags, then.
> --
> http://www.parc.xerox.com
Received on Monday, 24 March 1997 20:23:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:10 UTC