webdav: path-escape the lock root #167
Conversation
We ran in to an issue with various microsoft products accessing files over WebDAV which contain `%` characters in the name. The requests are all properly escaped -- e.g. the `%` is replaced with `%25`. Further the basic list functionality of the propfind responses contain encoded urls. The lock response/discovery includes the URL (lockroot) to the locked file. The existing implementation does not path escape that url. This seems to cause problems with the microsoft applications. When faced with the unencoded response, they try to lock again and fail. One explanation for this behaviour is that they maintain a table of locks indexed by encoded url. When the response from the server doesn't align with the URL they locked, the application fails. Update the lock discovery response code to escape the lockroot so that it matches everything else.
klarose
force-pushed
the
path-escape-lockroot
branch
from
d58105b
to
c72303b
Compare
|
This PR (HEAD: c72303b) has been imported to Gerrit for code review. Please visit https://go-review.googlesource.com/c/net/+/468635 to see it. Tip: You can toggle comments from me using the |
|
Message from Ian Lance Taylor: Patch Set 1: (1 comment) Please don’t reply on this GitHub thread. Visit golang.org/cl/468635. |
|
Message from Kyle Larose: Patch Set 2: (1 comment) Please don’t reply on this GitHub thread. Visit golang.org/cl/468635. |
|
Message from Kyle Larose: Patch Set 2: (2 comments) Please don’t reply on this GitHub thread. Visit golang.org/cl/468635. |
|
Message from Damien Neil: Patch Set 2: (1 comment) Please don’t reply on this GitHub thread. Visit golang.org/cl/468635. |
The lockroot is a path in the webdav library, meaning it may have slashes in it. Use the url.URL struct to handle this case when escaping the lockroot. Also add some unit tests.
|
This PR (HEAD: 806b1f1) has been imported to Gerrit for code review. Please visit https://go-review.googlesource.com/c/net/+/468635 to see it. Tip: You can toggle comments from me using the |
|
Message from Ian Lance Taylor: Patch Set 3: Run-TryBot+1 Please don’t reply on this GitHub thread. Visit golang.org/cl/468635. |
|
Message from Gopher Robot: Patch Set 3: (1 comment) Please don’t reply on this GitHub thread. Visit golang.org/cl/468635. |
|
Message from Gopher Robot: Patch Set 3: TryBot-Result+1 (1 comment) Please don’t reply on this GitHub thread. Visit golang.org/cl/468635. |
|
Message from Damien Neil: Patch Set 3: Code-Review+2 (1 comment) Please don’t reply on this GitHub thread. Visit golang.org/cl/468635. |
|
Message from Carlos Amedee: Patch Set 3: Code-Review+1 Please don’t reply on this GitHub thread. Visit golang.org/cl/468635. |
We ran in to an issue with various microsoft products accessing files
over WebDAV which contain
%characters in the name. The requests areall properly escaped -- e.g. the
%is replaced with%25. Furtherthe basic list functionality of the propfind responses contain encoded
urls.
The lock response/discovery includes the URL (lockroot) to the locked
file. The existing implementation does not path escape that url. This
seems to cause problems with the microsoft applications. When faced with
the unencoded response, they try to lock again and fail. One explanation
for this behaviour is that they maintain a table of locks indexed by
encoded url. When the response from the server doesn't align with the
URL they locked, the application fails.
Update the lock discovery response code to escape the lockroot so that
it matches everything else.