W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2000

Re: returning the lock token from a LOCK

From: Dan Brotsky <dbrotsky@Adobe.COM>
Date: Tue, 14 Nov 2000 07:12:54 -0800
Message-Id: <4.2.2.20001114064148.02d022b0@mailsj.corp.adobe.com>
To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>, w3c-dist-auth@w3.org
At 05:05 PM 10/24/00 -0400, Geoffrey M. Clemm wrote:

>In section 6.3 of 2518, it says "a lock token is returned by every
>successful LOCK operation in the lockdiscovery property in the
>response body".
>
>But then in section 8.10.1, it says "In order to indicate the lock
>token associated with a newly created lock, a Lock-Token response
>header MUST be included in the response for every successful LOCK
>request for a new lock."
>
>But then in the examples, no Lock-Token response header is included.
>
>This needs to be cleaned up.
>
>My personal preference is to go with section 8.10.1, unless there
>are servers/clients out there that depend on the section 6.3
>semantics, in which case we probably should require it to appear
>in *both* the header and the body (gross).

Unfortunately both are useful (and I agree this is gross).

The body is necessary because it returns lock expiration charateristics which otherwise would require another round-trip to discover.

The header is necessary because the client needs it (in general) to know which lock token the server is granting in response to the request.  If a non-exclusive lock is being requested by client A, then other clients may have requested and been granted the same kind of lock during the request-response cycle, in which case the lockdiscovery property will have all the other granted tokens in addition to A's.

     dan
Received on Tuesday, 14 November 2000 10:21:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:55 GMT