Re: IETF Last Call review: changes suggested

Lisa Dusseault schrieb:
> Here's what I've drafted up as possible guidance for clients dealing 
> with both RFC2518 and RFC2518bis servers:
> 
>       A WebDAV client implemented to this specification might find 
> servers that
>       create lock-null resources (implemented before this specification 
> using
>       RFC2518) as well as servers that create locked empty resources.  
> The response
>       to the LOCK request will not indicate what type of resource was 
> created.  
>       There are a few techniques which help the client deal with either 
> type.

Drop "implemented to this specification". This applies to all clients.

>       If the client wishes to avoid accidentally creating either 
> lock-null or empty locked
>         resources, an "If-Match: *" header can be included with LOCK 
> requests to prevent the server from
>         creating a new resource.

This will work in theory, but I'm pretty sure it doesn't in practice 
because of server bugs (I'll try to write a test case next week). We 
shouldn't recommend this as guidance unless we're pretty sure it works 
in practice.

>      If a LOCK request creates a resource and the client subsequently 
> wants to
>          overwrite that resource using a COPY or MOVE request, the 
> client should
>         include an "Overwrite: T" header. 

Yes. Terminology: it may make sense to define LNR (lock-null resource) 
and ELR (empty locked resource) upfront and use it here. So this would 
read: "If a LOCK request creates an ELR...".

>       If a LOCK request creates a resource and the client then decides 
> to get rid
>         of that resource, a DELETE request is supposed to fail on a 
> lock-null resource and
>         UNLOCK should be used instead. But with a locked empty resource, 
> UNLOCK doesn't
>         make the resource disappear.  Therefore, the client might have 
> to try both requests
>         and ignore an error in one of the two requests.

It can always do an UNLOCK, then DELETE, and treat a 404 upon the DELETE 
as success.

> Concrete suggestions for improving this would be welcome.
 > ...

Best regards, Julian

Received on Sunday, 18 February 2007 10:22:33 UTC