Subject: LOCK error marshalling (lockdiscovery property included?)

From: Julian Reschke <[email-masked]>
Date: Fri, 04 Jun 2004 15:47:56 +0200

Hi,

RFC2518, section 8.10.10 
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.10>) 
currently shows an example where the multistatus response body contains 
a DAV:lockdiscovery property...:

    HTTP/1.1 207 Multi-Status
    Content-Type: text/xml; charset="utf-8"
    Content-Length: xxxx

    <?xml version="1.0" encoding="utf-8" ?>
    <D:multistatus xmlns:D="DAV:">
      <D:response>
           <D:href>http://webdav.sb.aol.com/webdav/secret</D:href>
           <D:status>HTTP/1.1 403 Forbidden</D:status>
      </D:response>
      <D:response>
           <D:href>http://webdav.sb.aol.com/webdav/</D:href>
           <D:propstat>
                <D:prop><D:lockdiscovery/></D:prop>
                <D:status>HTTP/1.1 424 Failed Dependency</D:status>
           </D:propstat>
      </D:response>
    </D:multistatus>

The text then goes on...:

"Note also that the lockdiscovery property for the Request-URI has been 
included as required."

This seems to address a requirement from 8.10.1:

"The response MUST contain the value of the lockdiscovery property in a 
prop XML element."

(RFC2518bis-05 contains the same language).

Questions:

1) What's the benefit to get the DAV:lockdiscovery property in case the 
request fails? Shouldn't we just say that it MUST be returned on 
successful method execution and leave it at that?

2) Is anybody actually implementing this? Are there clients relying on 
it? (I don't think so, but I'll check). If nobody is actually doing 
this, we should remove that.

3) *If* we want to keep this, we'll have to think about that example:

      <D:response>
           <D:href>http://webdav.sb.aol.com/webdav/</D:href>
           <D:propstat>
                <D:prop><D:lockdiscovery/></D:prop>
                <D:status>HTTP/1.1 424 Failed Dependency</D:status>
           </D:propstat>
      </D:response>

After all, the "424" status is on the resource itself, not the 
DAV:lockdiscovery property. So it really would need to be....:

      <D:response>
           <D:href>http://webdav.sb.aol.com/webdav/</D:href>
           <D:status>HTTP/1.1 424 Failed Dependency</D:status>
      </D:response>

...and then we'd need a way to put in the DAV:lockdiscovery property in 
a way that doesn't break the DTD for the response element.

Feedback appreciated,

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Geoffrey M Clemm <[email-masked]>
Date: Fri, 4 Jun 2004 11:38:44 -0400

I don't think anything needs to be changed here.
I'm not sure what you had in mind by saying
"it MUST be returned on successful execution",
since the whole point is to indicate what existing
lock caused the LOCK request to fail, i.e. this
property is returned only for the failure case.

WRT the marshalling, I agree that this is not a
consistent way of using the propstat syntax
(i.e. the status is not about the property,
but that was just a convenient place to put it).
So if nobody implements this,
we certainly could define a cleaner marshalling,
but if any client/server does implement it, then we
should leave it alone.

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Sat, 05 Jun 2004 12:36:11 +0200

> property is returned only for the failure case.

In RFC2518, the requirement is independant from the success of the LOCK 
request: "The response MUST contain the value of the lockdiscovery 
property in a prop XML element." 
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.1.p.2>).

1) For a successful LOCK creation, returning the element makes a lot of 
sense, because the client can check the actual state of the lock (did 
the server accept my Timeout header? what did it persist in the 
DAV:owner property?). I think that part is widely implemented and if 
fact used by popular clients such as MS Office (it checks the response 
body to decide whether the created lock is really what it wanted). 
Therefore we should keep that part, and this is why I was saying "MUST 
be returned on success".

2) For a failed LOCK request, there are (at least) two scenarios:

2a) The resource at the request URI can not be locked, for instance 
because it already has a conflicting lock. In that case, I'd expect a 
4xx status code, and RFC2518 does not define a way to send back 
DAV:lockdiscovery. If we require the server to send back a 207 with 
response body in this case, this really needs to be stated explicitly 
because it's far from obvious.

2b) The client tries a deep lock, and some of the descendants of the 
resource identified by the request URI can not be locked. In that case 
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.4.p.3>), 
the text requires a 409 and a multistatus body (this is a bug in both 
RFC2518 and RFC2518bis, it should be 207, 
see...:<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.4.p.3>). 
In that case, the DAV:lockdiscovery property for the resource at the 
request URI will usually be empty, and it escapes me why anybody would 
want to send that back to the client.

> but if any client/server does implement it, then we

Let's find out.

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Sat, 5 Jun 2004 16:59:09 -0400

> property in a prop XML element." 

By "this property", I meant the property on the nested resource that
returned 424 because that nested resource was already locked.
I agree that a lockdiscovery property for the resource identified
by the request-URL must always be returned, whether or not the request
succeeded.

> Therefore we should keep that part, and this is why I was saying "MUST 

Yes, I agree.

> because it's far from obvious.

Well, it is stated in section 8.10.4, but I agree that it is not clearly
stated, since the only way to guess how to marshall it is by extrapolation
from example 8.10.10.

> RFC2518 and RFC2518bis, it should be 207, 
see...:<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.4.p.3
> >). 

Yes, that inconsistency in the spec doesn't contribute much in the way
of clarity (:-).

> want to send that back to the client.

It might not be empty because there might already be a shallow
lock on that collection.  So returning the lockdiscovery property
tells the client definitively whether or not there already is a
lock on the request URL resource, which is useful information when
dealing with the failure.

> > but if any client/server does implement it, then we

Yup.

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Sun, 06 Jun 2004 11:55:06 +0200

Geoffrey M Clemm wrote:

 > ...

Well, the 424 is returned for the request resource (because it has a 
failed dependancy). The non-424 status (in the RFC2518 example 
<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.10> it's 
a 403) comes without the DAV:lockdiscovery property (and I do agree that 
it may be useful here, but that's not what the spec says).

> ...

...but the multistatus response body is only mentioned for marshalling 
failures due to depth:infinity...

 > ...

In the meantime I found out that at least Apache/moddav and Sharemation 
indeed use this format. What we should do...:

1) Find out whether there are clients that actually process this 
information. As far as I can tell, it will only be useful if and only if 
you're trying to get an deep, exclusive lock on a resource that already 
has a shared lock. I'm only aware of two clients using shared locks. The 
first one being our own (and I know it doesn't use that information), 
the other being Adobe GoLive (for which I'll check).

2) If the answer is "yes" *and* we agree not to break them, we'll need 
to figure out how to precisely define that response format (a single 
example is not good enough).

3) On the other hand, if the answer is "no" let's define what we *like* 
the protocol to do and come up with a cleaner design (precondition code 
with nested content as in 
<http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.7.1.1>?

Best regards,

Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 7 Jun 2004 14:37:23 -0700

Hello client implementors! -- please respond on this thread and let us 
know if you use the 'lockdiscovery' property value, which is returned 
in failed LOCK requests.

(If no clients use the property value as returned in failed LOCK 
requests -- maybe they all do another round-trip to get the value -- 
then we might as well simplify, rather than optimize for this failure 
case)

Lisa

On Jun 6, 2004, at 2:55 AM, Julian Reschke wrote:

> <http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.10> 
> it's a 403) comes without the DAV:lockdiscovery property (and I do 
> agree that it may be useful here, but that's not what the spec says).
>
>> ...
> In the meantime I found out that at least Apache/moddav and 
> Sharemation indeed use this format. What we should do...:
>
> information. As far as I can tell, it will only be useful if and only 
> if you're trying to get an deep, exclusive lock on a resource that 
> already has a shared lock. I'm only aware of two clients using shared 
> locks. The first one being our own (and I know it doesn't use that 
> information), the other being Adobe GoLive (for which I'll check).
>
> 3) On the other hand, if the answer is "no" let's define what we 
> *like* the protocol to do and come up with a cleaner design 
> (precondition code with nested content as in

---

From: Jim Luther <[email-masked]>
Date: Mon, 7 Jun 2004 15:17:32 -0700

The Mac OS X WebDAV file system client uses exclusive locks. The 
lockdiscovery property is only used if LOCK is successful.

- Jim

On Jun 7, 2004, at 2:37 PM, Lisa Dusseault wrote:

>> ...but the multistatus response body is only mentioned for 
>> marshalling failures due to depth:infinity...
>>
>> > ...
>> 2) If the answer is "yes" *and* we agree not to break them, we'll 
>> need to figure out how to precisely define that response format (a 
>> single example is not good enough).
>>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 08 Jun 2004 11:31:10 +0200

Lisa Dusseault wrote:

> know if you use the 'lockdiscovery' property value, which is returned in 
> failed LOCK requests.
> 
> then we might as well simplify, rather than optimize for this failure case)

OK,

I just tested Adobe Golive (the client besides our own I'm aware of 
using shared locks) with Apache/moddav, trying to get an exclusive lock 
on a resource that already has a shared lock. The response from 
Apache/moddav is a 423 Locked, so no Multistatus.

Unless I'm missing something this means that the marshalling shown in 
section 8.10.10 of RFC2518 
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.10>) 
indeed won't help any clients at all; and as it is underspecified we 
should just get rid of it.

Proposed changes:

1) Change section 8.10.2 
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.1.p.2>) 
to say: "The response for a successful LOCK creation request MUST 
contain the value of the lockdiscovery property in a prop XML element."

2) When we define named preconditions, define a content model for the 
precondition that will reveal the lockdiscovery property.

Jason, could you please add this to the issues list? (I'm adding this to 
my list as 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html#rfc.issue.8.10.1_lockdiscovery_on_failure>, 
please let me know if should rephrase it).

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 30 Jun 2004 10:58:31 -0700

So, there hasn't exactly been overwhelming response to this.  We found 
out that one client implementation does not rely on having the 
'lockdiscovery' property in the body of failed LOCK responses (though 
they do use the property in other situations -- and thanks, Jim).

Problem summarized: the spec only shows by example how to include the 
property in the body of a 207, and the example doesn't follow the DTD.

Proposed solutions summarized:
   1. Define a new way to put 'lockdiscovery' in the body of a 207 to 
indicate a failed dependency, make existing servers change.
   2. Leave it out (simpler) because clients don't seem to use it and 
can always make a second trip in this (hopefully rare) failure case.

There's been some mild interest shown in the "leave it out" solution 
mostly because it simplifies the spec, although I think that it's also 
got a significant advantage in not requiring servers to change 
behavior.

Any objections to the "leave it out" solution (or further comments  in 
favour)?

Lisa

On Jun 7, 2004, at 3:17 PM, Jim Luther wrote:

>> Hello client implementors! -- please respond on this thread and let 
>> us know if you use the 'lockdiscovery' property value, which is 
>> returned in failed LOCK requests.
>>
>>> information. As far as I can tell, it will only be useful if and 
>>> only if you're trying to get an deep, exclusive lock on a resource 
>>> that already has a shared lock. I'm only aware of two clients using 
>>> shared locks. The first one being our own (and I know it doesn't use 
>>> that information), the other being Adobe GoLive (for which I'll 
>>> check).
>>>

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 Jun 2004 20:26:31 +0200

Lisa Dusseault wrote:

>   2. Leave it out (simpler) because clients don't seem to use it and can 
> always make a second trip in this (hopefully rare) failure case.
> 
> got a significant advantage in not requiring servers to change behavior.
> 

Well, I'm in favor not to put in special cases. Right now my text reads:

    <?xml version="1.0" encoding="utf-8" ?>
    <D:multistatus xmlns:D="DAV:">
      <D:response>
         <D:href>/webdav/secret</D:href>
         <D:status>HTTP/1.1 403 Forbidden</D:status>
      </D:response>
      <D:response>
         <D:href>/webdav/</D:href>
         <D:status>HTTP/1.1 424 Failed Dependency</D:status>
      </D:response>
    </D:multistatus>

(because /webdav/secret just denied the lock without any details). Let's 
assume instead /webdav/secret would have had a lock conflicting with the 
request, then we'd get

    <D:multistatus xmlns:D="DAV:">
      <D:response>
         <D:href>/webdav/secret</D:href>
         <D:status>HTTP/1.1 423 Locked</D:status>
      </D:response>
      <D:response>
         <D:href>/webdav/</D:href>
         <D:status>HTTP/1.1 424 Failed Dependency</D:status>
      </D:response>
    </D:multistatus>

...and assuming the LOCK (creation) method definition would define a 
matching precondition that would become:

    <D:multistatus xmlns:D="DAV:">
      <D:response>
         <D:href>/webdav/secret</D:href>
         <D:status>HTTP/1.1 423 Locked</D:status>
         <D:responsedescription>
           <D:error>
             <D:no-lock-conflict>
               <D:href>locktoken:...</D:href>
             </D:no-lock-conflict>
           </D:error>
         </D:responsedescription>
      </D:response>
      <D:response>
         <D:href>/webdav/</D:href>
         <D:status>HTTP/1.1 424 Failed Dependency</D:status>
      </D:response>
    </D:multistatus>

Note that this really nothing new; it would just follow from existing 
DAV:error marshalling once we simply *name* that precondition.

Also note that this only avoids a round trip to the child resource to 
lookup the conflicting lock. I guess only few clients would ever want to 
know...

Best regards, Julian