Jason Crawford writes:
> <<
> * Discussion of "First problem" slide. What should be the behavior on
> a LOCK on an indirectly locked resource? Should the lock remove the
> entire depth lock, or should it be redirected, or should it fail?
> Rough consensus for failure, error code to be determined later.
> >>
> Jim, could you publicly clarify this one. I'm not sure what it's refering
> to.
Sure. For example, say you have the following set of resources:
C1
/ | \
a C2 b
/ \
d e
C1, C2 are collections
a, b, d, e are non-collection resources
C1 contains a, C2, b
C2 contains d, e
If a Depth infinity lock is taken out on C1, using the terminology from the
meeting (really from Geoff Clemm's GULP proposal), resource C1 is directly
locked, and resources a, C2, b, d, e are indirectly locked (that is, they
were not the target of the LOCK request).
Given this terminological background, the question is, what is the behavior
of "UNLOCK" (the raw meeting notes are in error -- they say LOCK, and should
say UNLOCK) if applied to any of a, C2, b, d, or e? The three choices
discussed were:
1) remove the entire depth lock (i.e., is equivalent to an UNLOCK on C1)
2) be redirected to C1 using HTTP redirection (3xx)
3) fail (4xx)
The rough consensus in the meeting was that the response should fail (choice
#3).
- Jim