You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Brad <ja...@javawork.co.uk> on 2008/02/20 17:51:45 UTC
webdav lock tokens
Hi,
we're running some tests where we are locking a directory before we
write a file an unlock after the write is complete. After
investigating a problem we've been having, we've noticed that
sometimes we get an "opaque" lock token from the server. Normally we
get something like this:
<D:prop xmlns:D="DAV:"><D:lockdiscovery><D:activelock><D:lockscope><D:exclusive/></D:lockscope><D:locktype><D:write/></D:locktype><D:depth>0</D:depth><D:timeout>Second-2147483</D:timeout><D:owner>Admin</D:owner><D:locktoken><D:href>29001f9b-1aaa-4252-9fae-9d9d9b2c14a8-3</D:href></D:locktoken></D:activelock></D:lockdiscovery></D:prop>
...but every so often we get this:
<D:prop xmlns:D="DAV:"><D:lockdiscovery><D:activelock><D:lockscope><D:exclusive/></D:lockscope><D:locktype><D:write/></D:locktype><D:depth>0</D:depth><D:timeout>Second-20</D:timeout><D:locktoken><D:href>opaquelocktoken:4ad983e1-a1ec-4304-8879-91b263adfd4a</D:href></D:locktoken></D:activelock></D:lockdiscovery></D:prop>
Which is bad when we attempt the unlock as the server returns a HTTP
419 Locked.
Anyway, I guess my question is do we need to do something extra with
this token? We've looked in the WebDAV spec and are none the wiser as
to what it means and why we are getting a different token format.
Thanks,
Brad.
Re: webdav lock tokens
Posted by Angela Schreiber <an...@day.com>.
Julian Reschke wrote:
> Which is fine as well. See
> <http://greenbytes.de/tech/webdav/rfc4918.html#lock-unmapped-urls>.
ok. then we can simplify that a lot :)
angela
Re: webdav lock tokens
Posted by Julian Reschke <ju...@gmx.de>.
Angela Schreiber wrote:
> Julian Reschke wrote:
>> Angela Schreiber wrote:
>> What's that for? Why not simply create an empty, locked, resource?
>
> because from my understanding the null-resource does
> not exist and it would look wrong to me, if it
> was created upon the LOCK request... at least
But that's what the spec explicitly allows to do.
> up to now i wouldn't know how to define 'empty'. in
> case of nt:file node: i can't omit the jcr:content node.
So it would contain a jcr:content node with a jcr:data property of length 0.
> and if jcr:content is nt:resource i couldn't omit the
> the jcr:data prop...
That's fine.
> and if it's there i would expect a HEAD/GET request not
> to return not-found.
Which is fine as well. See
<http://greenbytes.de/tech/webdav/rfc4918.html#lock-unmapped-urls>.
BR, Julian
Re: webdav lock tokens
Posted by Angela Schreiber <an...@day.com>.
Julian Reschke wrote:
> Angela Schreiber wrote:
> What's that for? Why not simply create an empty, locked, resource?
because from my understanding the null-resource does
not exist and it would look wrong to me, if it
was created upon the LOCK request... at least
up to now i wouldn't know how to define 'empty'. in
case of nt:file node: i can't omit the jcr:content node.
and if jcr:content is nt:resource i couldn't omit the
the jcr:data prop...
and if it's there i would expect a HEAD/GET request not
to return not-found.
angela
query question
Posted by alex marina <al...@yahoo.com>.
Hi,
I use jackrabbit with persistance on the disk. Is there any way to make a query return the size of files on the disk?
BR,
Alex
---------------------------------
Never miss a thing. Make Yahoo your homepage.
Re: webdav lock tokens
Posted by Julian Reschke <ju...@gmx.de>.
Angela Schreiber wrote:
> but:
> if no node exists (and webdav allows to create a lock
> on non-existing resources, which is something JCR does
> not allow) or if for whatever reason adding the mixin-type
> fails
>
> - the resource is locked without having a lock in
> the repository (and their lock-token is generated
> in a different way than the lock-tokens generated
> by the JCR repository).
>
> -> that's the reason for 2 different token types.
> ...
What's that for? Why not simply create an empty, locked, resource? See
<http://greenbytes.de/tech/webdav/rfc4918.html#lock-unmapped-urls>.
BR, Julian
Re: webdav lock tokens
Posted by Angela Schreiber <an...@day.com>.
> Hope this helps
> https://issues.apache.org/jira/browse/JCR-1352
i'd say it's a slightly different story.
upon a LOCK request the simple.DavResourceImpl by default
makes an attempt to lock the node on the repository.
it does so by:
- test if a repository Node exists
- test if Node is mix:lockable
- if not try to add that mixin type to the node
- locking the node
but:
if no node exists (and webdav allows to create a lock
on non-existing resources, which is something JCR does
not allow) or if for whatever reason adding the mixin-type
fails
- the resource is locked without having a lock in
the repository (and their lock-token is generated
in a different way than the lock-tokens generated
by the JCR repository).
-> that's the reason for 2 different token types.
still:
- removing the lock should succeed in either case.
- if that doesn't it's a bug (for this see
https://issues.apache.org/jira/browse/JCR-1352)
angela
RE: webdav lock tokens
Posted by Roland Porath <ro...@exari.com>.
Hi brad
Hope this helps
https://issues.apache.org/jira/browse/JCR-1352
cheers
roland
> -----Original Message-----
> From: bradmoody@gmail.com [mailto:bradmoody@gmail.com] On Behalf Of Brad
> Sent: Thursday, 21 February 2008 3:52 AM
> To: users@jackrabbit.apache.org
> Subject: webdav lock tokens
>
> Hi,
>
> we're running some tests where we are locking a directory before we
> write a file an unlock after the write is complete. After
> investigating a problem we've been having, we've noticed that
> sometimes we get an "opaque" lock token from the server. Normally we
> get something like this:
>
> <D:prop
> xmlns:D="DAV:"><D:lockdiscovery><D:activelock><D:lockscope><D:exclusive/><
> /D:lockscope><D:locktype><D:write/></D:locktype><D:depth>0</D:depth><D:tim
> eout>Second-
> 2147483</D:timeout><D:owner>Admin</D:owner><D:locktoken><D:href>29001f9b-
> 1aaa-4252-9fae-9d9d9b2c14a8-
> 3</D:href></D:locktoken></D:activelock></D:lockdiscovery></D:prop>
>
> ...but every so often we get this:
>
> <D:prop
> xmlns:D="DAV:"><D:lockdiscovery><D:activelock><D:lockscope><D:exclusive/><
> /D:lockscope><D:locktype><D:write/></D:locktype><D:depth>0</D:depth><D:tim
> eout>Second-20</D:timeout><D:locktoken><D:href>opaquelocktoken:4ad983e1-
> a1ec-4304-8879-
> 91b263adfd4a</D:href></D:locktoken></D:activelock></D:lockdiscovery></D:pr
> op>
>
> Which is bad when we attempt the unlock as the server returns a HTTP
> 419 Locked.
>
> Anyway, I guess my question is do we need to do something extra with
> this token? We've looked in the WebDAV spec and are none the wiser as
> to what it means and why we are getting a different token format.
>
> Thanks,
> Brad.
>
> !DSPAM:47bc5ac4304641420419767!