Re: need clarification about COPY to locked resource response code

Am Freitag den, 19. April 2002, um 10:12, schrieb Julian Reschke:

>> From: w3c-dist-auth-request@w3.org
>> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stefan Eissing
>> Sent: Friday, April 19, 2002 9:30 AM
>> To: WebDAV
>> Subject: Re: need clarification about COPY to locked resource response
>> code
>>
>> ...
>>
>> Am Montag den, 15. April 2002, um 23:59, schrieb Jason Crawford:
>>
>>>
>>> http://lists.w3.org/Archives/Public/w3c-dist-
>>> auth/2002JanMar/0098.html
>>>
>>> I don't think the above comment was resolved.
>>>
>>> Do we want to make a change to the spec?
>>
>> I don't feel strongly about it. If, then I would list 207 as
>> possible status code of COPY/MOVE (where there are completely
>> absent now) and explain that 423 LOCKED will only map to locked
>
> They are missing from the status tables, but they are mentioned in
> descriptions and examples.

I think that's why I wrote that they are missing from the status 
codes. ;)

>> request-uri. If any other uri (destination included) makes trouble,
>> clients should be able to deal with a 207.
>
> I think the issue is that
>
> - 423 is used both for LOCK problems on source and destination URIs,

Yes.

> - there doesn't seem to be any prior usage of multistatus to describe
> information about destination URIs.

The examples cover children of destination uris in 207. But, for 
example,
with access control you can get 403 on the destination uri and that is
not defined either. I would expect a server to report this 403 on the
destination inside a 207 multistatus.

> The cleanest "solution" (although not backward-compatible) would 
> be to have
> a separate status code for the condition "destination locked". 
> However, we
> are currently talking about RFC2518, so we're probably stuck with the
> ambiguity.
>
> In a future WebDAV protocol that supports enhanced error reporting a la
> RFC3253, I'd probably suggest:
>
> 409 CONFLICT
> ....
>
> <error xmlns='DAV:'><destination-URI-is-locked/></error>

I don't like this for the simple reason that clients need hardcoded
information about each DAV:error _and_ they need to know how to handle
HTTP status codes. So I would prefer to use existing HTTP status 
codes over
new DAV:errors.

Otherwise you need to define also DAV:destination-is-not-accesible,
DAV:destination-parent-is-locked, etc.

//Stefan

>
>>> Are we clear on what URL we need to point reference in the 
>>> multi-status
>>> response for various lock problems?
>>
>> I don't understand that question. Can you elaborate?
>
> I understand that as: is it actually allowed (in copy/move/delete) 
> to use
> multistatus to report problems on destination resources?
>

Received on Friday, 19 April 2002 04:32:40 UTC