RE: Depth header in a lock refreshing method

Another option is to reject the request if the Depth header is present and
has the wrong value.

lisa

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org 
> [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Geoffrey M Clemm
> Sent: Thursday, January 01, 2004 7:02 AM
> To: w3c-dist-auth@w3.org
> Subject: Re: Depth header in a lock refreshing method
> 
> 
> 
> I agree with Julian that option 4 is probably best.
> 
> Cheers,
> Geoff
> 
> Julian wrote on 12/31/2003 08:32:11 AM:
> 
> > Stanley Guan wrote:
> > 
> > > Under the topic of "Refreshing Locks", it hints that
> > > Client may include a Timeout header. But, Depth header
> > > has not being mentioned.
> > > 
> > > Under the topic of "Depth and Locking", it discussed
> > > what will happen if "Depth" header is specified for
> > > creating a new lock.  But, nothing was mentioned on
> > > what's its implication on a lock refreshing command.
> > > 
> > > Should "bis" document clarify this?
> > 
> > Possibly.
> > 
> > In general, methods should ignore unknown headers. In this 
> particular 
> > case of course, the Depth header *is* used for LOCK (just only when 
> > creating new locks).
> > 
> > So the options for LOCK refresh are:
> > 
> > 1) server MUST respect Depth header, possibly changing the 
> lock scope
> > 2) server MAY respect Depth header, possibly changing the lock scope
> > 3) server SHOULD ignore Depth header
> > 4) server MUST ignore Depth header
> > 
> > As 4) is what currently everybody seems to implement, I'd 
> propose to 
> > choose that interpretration and clarify in RFC2518bis.
> 
>

Received on Wednesday, 7 January 2004 12:58:05 UTC