Re: Behavior of PUT on unlocked resource with invalid IF header ...

John,
   I'm sending this to the 2518 working group rather than Delta-V since it
doesn't seem Delta-V specific.  (I've included your note below.)

My opinion is that...
   The spec should not use the IF header for token presentation to the
server.
   The IF header should only be used for client initiated assertion
checking.
   The current use of IF for dual purposes just causes confusion (like I
think your note indicates) and impedes our ability to potentially extend it
later.
   We should transition to some other header for token presentation to the
server.
   Or perhaps I just misunderstand the IF header and someone needs to
clearly define it.  :-)

Do we have other people with opinions on this?

------------------------------------------
Phone: 914-784-7569,   ccjason@us.ibm.com


"John Hall" <johnhall@evergo.net>@w3.org on 08/14/2001 01:56:04 PM

Sent by:  ietf-dav-versioning-request@w3.org


To:   <ietf-dav-versioning@w3.org>
cc:
Subject:  Behavior of PUT on unlocked resource with invalid IF header ...


If we reject it, then a client could detect that their previously active
lock had expired.

So ... I'm wondering if the spec should require the rejection.  I'm also
wondering if my implementation should reject it even in the spec is
silent.


-----Original Message-----
From: ietf-dav-versioning-request@w3.org
[mailto:ietf-dav-versioning-request@w3.org] On Behalf Of Jim Amsden
Sent: Sunday, August 12, 2001 5:24 PM
To: ietf-dav-versioning@w3.org
Subject: RE: Comments regarding locking & auto-checkin...


John asks:
Is a PUT supposed to be rejected if the IF header provided specifies an
invalid lock token and the resource is not locked?

The if header would likely be ignored since the resource isn't locked
and there's no token to check. But servers could implement this as a
failed If header since it doesn't match the resource. Looks like a
clarification might be needed in the spec.

Received on Tuesday, 14 August 2001 14:47:37 UTC