Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      Description

      WebDAV lock tokens are URIs, while JCR lock tokens aren't. Therefore, the WebDAV servlet needs to transform outgoing JCR lock tokens (response headers and WebDAV properties) into URI format, and needs to parse the original lock token out of incoming WebDAV lock tokens (in request headers).

      Proposed mapping:

      • when the JCR lock token uses UUID format, use "urn:uuid",
      • otherwise encode with a constant prefix, such as "tag:jackrabbit.apache.org,2008:LockTokens."

        Issue Links

          Activity

          Hide
          angela added a comment -

          i don't have any preference. the only thing you have to make sure is the following:

          the lock tokens obtained from the request are added to the jcr-Session obtained to handle the request. If the lock token has been modified in order make it compliant with whatever requiment form rfc 2518, you must revert the modification before you add the token to the session. otherwise you won't ever be able to become lock holder (i.e. Session.addLockToken(String) failes without further notice... only a warning in the log file).

          Show
          angela added a comment - i don't have any preference. the only thing you have to make sure is the following: the lock tokens obtained from the request are added to the jcr-Session obtained to handle the request. If the lock token has been modified in order make it compliant with whatever requiment form rfc 2518, you must revert the modification before you add the token to the session. otherwise you won't ever be able to become lock holder (i.e. Session.addLockToken(String) failes without further notice... only a warning in the log file).
          Hide
          angela added a comment -

          adjust component.

          Show
          angela added a comment - adjust component.

            People

            • Assignee:
              Julian Reschke
              Reporter:
              Julian Reschke
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development