WebDAV servlets and locking

[Dave Fried <df...@phoenix-int.com>]

Here is what I know about the default Jackrabbit implementation of its WebDAV
servlets:
* each HTTP request = one session
* therefore, session-scoped locks are useless, because locks effectively
disappear at the end of a LOCK request (the session is logged out) and both
the lock token and being in the same session are required to operate on a
locked resource
* many WebDAV client apps use session-scoped locks by default, meaning that
they will not work with Jackrabbit (at least out of the box)

I would like to user Jackrabbit as a repository, but I need something that
most existing WebDAV clients can interface with, and that includes being
able to lock files safely for periods of time.  From what I have read in the
list archives and what I have seen in the code, there are a few possible
solutions.  I'd like to hear the pros and cons of each solution, or if you
have any other ideas that may help.

Solution 1: HTTP session = session
Have one session for each authenticated WebDAV client which persists as long
as the HTTP session persists.  Since sessions are not guaranteed to be
thread-safe, I will need to synchronize requests at a relatively high level. 
Also, I will need a mechanism to expire dead sessions.  Evidently, there are
callbacks/listeners available for this.  This does seem like a relatively
low-impact solution because it only requires replacing/extending a session
factory class.  How feasible/usable is this solution?

Solution 2: authenticated user = session (/w timeout)
Same as above, but each user gets one session which is re-used until the
user is inactive for a bit (could use some kind of dynamic pool?).  This
will absolutely require synchronization of simultaneous requests, but...
whatever.  Maybe create different sessions for the same user with different
clients or IP addresses, just for safety's sake.

Solution 3: non-standard locks
Change the way locks work so that they can always be used if you have the
token, and make sure they time-out properly.  Maybe add the requirement that
you are the same user who created the lock.  This seems straightforward, but
also seems like it could horribly break a whole bunch of stuff under the
hood.  Am I right to be apprehensive?

Thanks in advance!

--Dave
-- 
View this message in context: http://www.nabble.com/WebDAV-servlets-and-locking-tp20135445p20135445.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.

Re: WebDAV servlets and locking

[Dave Fried <df...@phoenix-int.com>]

Minor correction:


Dave Fried wrote:
> 
> Here is what I know about the default Jackrabbit implementation of its
> WebDAV servlets:
> * each HTTP request = one session
> * therefore, session-scoped locks are useless, because locks effectively
> disappear at the end of a LOCK request (the session is logged out) and
> both the lock token and being in the same session are required to operate
> on a locked resource
> * many WebDAV client apps use session-scoped locks by default, meaning
> that they will not work with Jackrabbit (at least out of the box)
> 

Actually, the locks I'm dealing with are *not* session-scoped, but the
"owner" of the lock gets cleared when the session ends, so the lock token is
useless and the problem is pretty much the same.
-- 
View this message in context: http://www.nabble.com/WebDAV-servlets-and-locking-tp20135445p20135896.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.

Re: WebDAV servlets and locking

[Angela Schreiber <an...@day.com>]

hi dave

> [...] AFAIK, from a WebDAV perspective (or as you pointed out, from a 
> JCR 2.0 perspective), there is nothing wrong with sometimes revealing 
> lock tokens.

no. but currently it is simply not possible unless the
dav-server either remembers the token/owner-id pair
OR doesn't logout the session.

regarding your proposed solutions 1 to 3.

there was also the possibility to have a variant between
1 and 2:
behaves as 1 but becames 2 if the session locks a node.
with this scenario session-scoped locks could be used that
are removed as soon as the session gets logout due to some
timeout (to long inactivity or client silently died).
this way you could avoid having lost locks that need to
be released by some admin.

angela

Re: WebDAV servlets and locking

[Dave Fried <df...@phoenix-int.com>]

Thanks, Julian!

I mostly figured the problem out.  Turns out that it was not the problem 
I thought it was.  The client software was correctly re-acquiring the 
lock during the UNLOCK operation, but the server forgot to strip the 
"opaque:" prefix from the lock token in one case.  The client got 
temporary ownership of the lock for the session, but then the tokens 
didn't match during the actual UNLOCK.  So, I just corrected the server 
code and now UNLOCK works correctly.

Regarding lost lock tokens: I think I may modify the code I am running 
to reveal lock tokens to administrators, so a resource that is left 
locked with a lost token can be later unlocked/removed by an appropriate 
person.  AFAIK, from a WebDAV perspective (or as you pointed out, from a 
JCR 2.0 perspective), there is nothing wrong with sometimes revealing 
lock tokens.

Thanks again!

--Dave

Julian Reschke wrote:
> WebDAV clients are supposed to remember the lock token they received 
> upon LOCK. They need to re-submit them in subsequent requests, using 
> the "If" header.
>
> If they do not keep them, they have to rely on lock token discovery 
> using PROPFIND, which servers are not required to support. So this is 
> not strictly a JCR problem.
>
> That being said, JCR 2.0 *allows* servers to reveal the lock tokens of 
> open-scoped locks, so I expect future implementations to actually do 
> that.
>
> BR, Julian
>

Re: WebDAV servlets and locking

[Julian Reschke <ju...@gmx.de>]

Dave Fried wrote:
 > Minor correction: the locks are not session-scoped, but the lock's 
owner gets
 > cleared when the session ends, and there is no effective way to 
re-acquire
 > it without setting up a session that lasts longer than one HTTP 
request.  So
 > the problem is more or less the same as before.

WebDAV clients are supposed to remember the lock token they received 
upon LOCK. They need to re-submit them in subsequent requests, using the 
"If" header.

If they do not keep them, they have to rely on lock token discovery 
using PROPFIND, which servers are not required to support. So this is 
not strictly a JCR problem.

That being said, JCR 2.0 *allows* servers to reveal the lock tokens of 
open-scoped locks, so I expect future implementations to actually do that.

BR, Julian

Re: WebDAV servlets and locking

[Dave Fried <df...@phoenix-int.com>]

Minor correction: the locks are not session-scoped, but the lock's owner gets
cleared when the session ends, and there is no effective way to re-acquire
it without setting up a session that lasts longer than one HTTP request.  So
the problem is more or less the same as before.


Dave Fried wrote:
> 
> Here is what I know about the default Jackrabbit implementation of its
> WebDAV servlets:
> * each HTTP request = one session
> * therefore, session-scoped locks are useless, because locks effectively
> disappear at the end of a LOCK request (the session is logged out) and
> both the lock token and being in the same session are required to operate
> on a locked resource
> * many WebDAV client apps use session-scoped locks by default, meaning
> that they will not work with Jackrabbit (at least out of the box)
> 

-- 
View this message in context: http://www.nabble.com/WebDAV-servlets-and-locking-tp20135445p20135973.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.