Re: LOCK error marshalling (lockdiscovery property included?)

Lisa Dusseault wrote:

> 
> 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)?

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

    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>/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

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

Received on Wednesday, 30 June 2004 14:27:18 UTC