Description
In a webapp application using Apache Jackrabbit Oak implementation of the JCR, the WebDAV access of office documents are provided with Jackrabbit SimpleWebDavServlet.
When a document is opened through WebDAV by an office suite (here LibreOffice), a lock token is created and passed to the client. This lock token is generated by JcrActiveLock which delegates the generation to LockTokenMapper which, in the case of Oak, uses for doing LockImpl#getLockToken(). This method returns as token the path in the JCR of the node representing the file. Because the path contains the '/' separators, those are converted in "%2f". But, some office suite like LibreOffice seams to parse this token because they send back as token in the request header "Lock-Token" the token value in which the '/' character is encoded in "%2F" instead of "%2f" provoking consequently an error when unlocking the document.
It should be fine to avoid to pass the path of the document in the JCR as a token value. At least, it should be encoded in Base64 or any other encoder.