I think it should also be compatible when the lock on the collection is
exclusive, but has depth 0.
//Stefan
Am 16.09.2004 um 14:20 schrieb Stefan L�tzkendorf:
Julian Reschke wrote:
Stefan L�tzkendorf wrote:
What does the spec say in relation to the following scenario:
- You have a collection A that is locked. You create a lock-null
resouce
under A called foo.bar. Now, this has to be created using a LOCK
method
execution and you are likely to get a different token or the same
token as
the parent collection.
I think you should not be able to create a lock-null resource under
a locked
collection.
To work on a locked resource (e.g. to add a new member using MKCOL)
you have to
provide the locktoken in the If header. But with the LOCK method the
If
Correct.
header
is used for refreshing locks (s. 7.8), so I would say you cant lock
under a
That's only partly correct. You need the If header for LOCK refresh,
but that doesn't mean that any LOCK request with an If header is
indeed a refresh request.
And yes, that's how you would add a lock-null resource to a locked
collection. Note that this won't work unless the requested lock on
the child is compatible with the one on the parent collection (that
is, it's a shared lock).
Ok, with shared lock it makes sense to use LOCK and If header. I'v
never
used shared locks and so I always think locks as exclusive.
Have you ever found a real scenario where shared locks are usefull?
Best regards,
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
