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

Re: [Bug 23] lock discovery vs shared locks

From: Jim Luther <luther.j@apple.com>
Date: Wed, 16 Nov 2005 14:05:42 -0800
Message-Id: <361994E2-4C4B-494B-AC8E-225D81C29ABC@apple.com>
To: webdav <w3c-dist-auth@w3.org>

On Nov 16, 2005, at 12:28 AM, Julian Reschke wrote:

>> the LOCK response body, doesn't that mean that the lock token is  
>> returned both in the LOCK response headers (Lock-Token) and body?
> It may, but clients can not rely on it.

The Mac OS X WebDAV file system client gets the locktoken out of the  
response body when it creates a new lock. My guess (since this code  
was written before I started working on anything WebDAV related) is  
that it was done because:

* rcf2518 section 8.10.1 <http://greenbytes.de/tech/webdav/ 
rfc2518.html#rfc.section.8.10.1> says, "The response MUST contain the  
value of the lockdiscovery property in a prop XML element."

* the example given in rcf2518 section 8.10.8 <http://greenbytes.de/ 
tech/webdav/rfc2518.html#rfc.section.8.10.8> does not show a Lock- 
Token response header in the response.

Of course, the Mac OS X WebDAV file system client can be changed in  
some future release to use the Lock-Token response header (and I just  
wrote up a bug report to make sure that happens). However, if a  
server wants to interoperate with existing versions of the Mac OS X  
WebDAV file system client, they'll need to return the the locktoken  
in the body.

- Jim
Received on Wednesday, 16 November 2005 22:05:45 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:33 UTC