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

Newbie question about LOCK

From: Sander Bos <sander@x-hive.com>
Date: Tue, 26 Feb 2002 10:47:16 +0100
Message-ID: <41D11F414A26E942912B7E7696DC8E22061591@JAKARTA.xhive.archipel>
To: <w3c-dist-auth@w3.org>

Hi there,

we build a small WebDAV integration for our XML database on top of
Tomcat's WebDAV offering. XMetaL 3 is out now, has WebDAV support, but
does not cooperate well with the Tomcat WebDAV server. One problem I
could figure out myself (for completeness, that was that XMetaL asked a
lock for an owner with an XML-fragment like
<a:owner><a:href>sander</a:href></a:owner>, and Tomcat sent back a reply
with '<a:href>sander</a:href>' in the response, but without declaring
the namespace for 'a'), but I do not know what to do about the second
problem I encountered. Since I scrounged off Tomcat's implementation, I
am not intimately familiar with the DAV specification.

The problem is that the XMetaL client asks for a LOCK on the same
resource twice. I included the log at the end of this message, even
though there are two different user agents mentioned in the log, for
what I know (I'm also new to connection logging) this were actually
commands send over one keep-alive connection. Tomcat has sent back a
response granting the lock for the first request, then denying the
second one since the thing is already locked.

I read
	http://asg.web.cmu.edu/rfc/rfc2518.html#sec-7.8
a couple of times, the first line seems to suggest very clearly that
this is illegal for a client to do, all the other lines seem to
contradict it a little but are very unclear to me. I do not see any 'If
header', but maybe I do not know what to look for.


In any event, my question is this: May the client send the requests as
it does below, or may it not? Should I find fault with the server or the
client? If the fault is with the server, how should it react to the
second LOCK-request, should it see that it is from the same user and
regrant the lock anyway, and if that is so should it send the same
locktoken (just a term I saw while looking for section 7.8) as it did in
the first response?
(I am sure the people behind XMetaL tested their stuff, so I suppose
there must be servers which do grant multiple locks for the same
resource?)


Kind regards,

--Sander.

------
X-Hive Corporation (www.x-hive.com)
email: sander@x-hive.com
phone: +31 10 7108625


-----------------------------------------------

End of the log of the commands the client send:


LOCK /webdav/addresslist1.xml HTTP/1.1 
Accept: */* Accept-Language: en-us 
Content-Type: text/xml 
Accept-Encoding: gzip, deflate 
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) 
Host: localhost:8082 
Content-Length: 194 
Connection: Keep-Alive 
Cache-Control: no-cache  

<?xml version="1.0"?> 
<a:lockinfo xmlns:a="DAV:">
 	<a:lockscope><a:exclusive/></a:lockscope>
 	<a:locktype><a:write/></a:locktype>
 	<a:owner><a:href>sander</a:href></a:owner> 
</a:lockinfo> 

GET /webdav/addresslist1.xml HTTP/1.1 
Accept: */* 
User-Agent: DAV Client (C) 
Host: localhost:8082 
Connection: Keep-Alive 
Cache-Control: no-cache  

OPTIONS /webdav/addresslist1.xml HTTP/1.1 
Accept: */* 
User-Agent: DAV Client (C) 
Host: localhost:8082 
Content-Length: 0 
Connection: Keep-Alive 
Cache-Control: no-cache  

LOCK /webdav/addresslist1.xml HTTP/1.1 
Accept: */* 
Accept-Language: en-us 
Content-Type: text/xml 
Accept-Encoding: gzip, deflate 
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) 
Host: localhost:8082 
Content-Length: 194 
Connection: Keep-Alive 
Cache-Control: no-cache  

<?xml version="1.0"?> 
<a:lockinfo xmlns:a="DAV:">
 	<a:lockscope><a:exclusive/></a:lockscope>
 	<a:locktype><a:write/></a:locktype> 
 	<a:owner><a:href>sander</a:href></a:owner>
</a:lockinfo> 
Received on Tuesday, 26 February 2002 04:47:48 GMT

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