W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2003

RE: Using If and not failing

From: Lisa Dusseault <lisa@xythos.com>
Date: Fri, 31 Jan 2003 22:14:32 -0800
To: "'Lisa Dusseault'" <lisa@xythos.com>, "'Webdav WG'" <w3c-dist-auth@w3c.org>
Message-ID: <007a01c2c9b9$303d9470$f876fea9@xythoslap>

I've been looking into this some more. This trick should also work with
tagged lists.  However, since multiple tagged lists are ANDed together
(" If the state of the resource to which the header is applied does not
match any of the specified state lists then the request MUST fail") it
has to be done a little differently.

<no-lock> here represents a lock token that the client made up, which is
intended to Fail.
If: <href1> (<locktoken1> Not <no-lock>) <href2> (<locktoken2> Not

This evaluates as 
	((href1 matches locktoken1) OR NOT (href1 matches no-lock))
	AND  ((href2 matches locktoken2) OR NOT (href2 matches no-lock))

I tested this against Xythos WFS, and clients can use this syntax to
make sure that the request does not fail even if locktoken1 or
locktoken2 are no longer there.  Of course this should always be used
with ETag checks. 


> -----Original Message-----
> From: Lisa Dusseault [mailto:lisa@xythos.com] 
> Sent: Thursday, January 23, 2003 12:20 PM
> To: Webdav WG
> Subject: Using If and not failing
> Did anybody point out that there's an interesting way for the 
> client to
> ensure that the If header never fails the request, by always 
> providing a
> "true" statement?
> -          One or more tokens can be put in parentheses to 
> form a group
> or list
> -          Multiple lists can be included and they are ORed together
> So if the client wants to put a bunch of locktokens in the If 
> header it
> can put any number of them in there, all separated by virtual "OR"s:
> DOSTUFF /resourceurl.html HTTP/1.1
> If: (<locktoken1>) (<locktoken2>) (<locktoken3)
> This request will succeed if the any of the clauses match.
Received on Saturday, 1 February 2003 01:14:32 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:27 UTC