RE: Interop issue: Proposal for fixing lock token provision

The client should be able to choose either of the headers you use as
examples, depending on whether they want the request to succeed even if
lock tokens are invalid.

 

When the client submits "New-If-Header: token-1, token-2" (note the
comma) the client wants the request to succeed, as can be seen by the
fact that it is not issuing a conditional request.  So:

1.       If token-1 is not needed, or doesn't correspond to a live lock,
the request doesn't fail.

2.       Same for token-1.

 

When the client submits "If:<lockroot-1> (<token1>) <lockroot-2>
(<token-2>)", the client is forcing the request to fail if the
conditions aren't met.  If that's what the client wants, then fine.  But
if the client wants the request to succeed, I would hope the client
could use something else, because:

1.       If token1 is invalid, or doesn't match lockroot-1, the request
fails.

2.       Same for token2

 

Syntactic "swill" is important in this case because when moving a
directory with a bunch of locked files, the syntactic "swill" of the
existing if header can result in a request that is impossible to
successfully convey to the server because of bad support (in proxies,
firewalls or servers) for very long header values.

 

Client effort may or may not be reduced.  Client effort is definitely
reduced in these cases:

1.       The client has been able to put all their lock tokens in the
"New-If-Header" value without having to sort which ones apply to which
URLs and which ones are "required" for this operation.

2.       If a lock has gone away, the client is not forced to (a) parse
the error and (b) reformat request without offending tokens and (c)
reissue the request, which they want to work, just in order for it to
work.

 

I fail to understand how these are "separate issues".  The proposal has
several advantages described. It can be interoperable with the existing
client/server deployed base because nobody has to change how they
send/handle the existing IF header.  Perhaps you want to compare this to
another proposal that would solve some of the same problems, but if
that's the case, then I cannot answer because I do not understand what
the alternate proposal is.

 

Lisa

 

-----Original Message-----
From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]
On Behalf Of Clemm, Geoff
Sent: Tuesday, October 08, 2002 10:44 AM
To: 'Webdav WG'
Subject: RE: Interop issue: Proposal for fixing lock token provision

 

Perhaps you could explain this with an example? 

In particular, whenever you would have a client submit: 

New-If-Header: token-1 token-2 

I would have that client submit: 

If: <lockroot-1> (<token1>) <lockroot-2> (<token-2>) 

Other than the minor syntactic swill, and the addition of the 
lockroot tag, what is the difference in terms of client effort? 
(Semantically of course there is a difference, in that 
you cannot submit invalid lock tokens in If, but 
that is a separate issue). 

Cheers, 
Geoff 

 

-----Original Message----- 
From: Lisa Dusseault [mailto:lisa@xythos.com] 
Sent: Tuesday, October 08, 2002 12:44 PM 
To: 'Clemm, Geoff'; 'Webdav WG' 
Subject: RE: Interop issue: Proposal for fixing lock token provision 

 

> Using a different header to submit tokens doesn't make it any easier 
> for a client to decide what tokens to submit in the header.  

Yes it does, which is one of the major reasons client developers have 
asked for this to be fixed: it makes it possible for clients to submit a

bunch of lock tokens for the same "area" of the namespace, even if the 
client is not sure whether the server would require each lock token. 

Since servers are different in how they require lock tokens for various 
operations, this allows clients to submit as many lock tokens as they 
believe they need, without failing on some servers. 

lisa