[
https://issues.apache.org/jira/browse/JCR-3209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817319#comment-17817319
]
Julian Reschke commented on JCR-3209:
-------------------------------------
2.6: (2.6.6)
[a0dc29e29|https://github.com/apache/jackrabbit/commit/a0dc29e29630a356ceda715095e679424d37fc73]
2.4: (2.4.6)
[205beb455|https://github.com/apache/jackrabbit/commit/205beb455622af9659da721f01a702c1d7190508]
> lock token validity
> -------------------
>
> Key: JCR-3209
> URL: https://issues.apache.org/jira/browse/JCR-3209
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-jcr-server, jackrabbit-spi2dav, locks
> Affects Versions: 2.4.4
> Reporter: Julian Reschke
> Assignee: Julian Reschke
> Priority: Minor
> Fix For: 2.4.5, 2.5
>
> Attachments: JCR-3209.diff
>
>
> There are several minor issues in the mapping between JCR lock tokens and
> WebDAV lock tokens:
> 1) WebDAV lock tokens are supposed to use URI syntax (such as
> opaquelocktoken: or urn:uuid:)
> 2) The server currently computes lock tokens for session-scoped locks based
> on the node id; these are not valid JCR lock tokens though and cause
> exceptions when they are re-added when they appear in a Lock-Token header or
> an If header. This will likely cause requests to fail that use both types of
> locks (yes, maybe academic but should be fixed anyway)
> Proposal:
> a) Map lock tokens to oqaquelocktoken URIs, using a constant UUID plus a
> postfix encoding the original lock token
> b) Use a syntax that allows to distinguish between tokens for open-scoped
> locks or session-scoped locks, so that we do not try to add the latter type
> to the Session (alternatively, handle exceptions doing so gracefully)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
