Cyberduck Mountain Duck CLI

#10378 closed defect (wontfix)

Custom path is always URI encoded and normalized with trailing slash in requests

Reported by: Onnonymous Owned by:
Priority: normal Milestone:
Component: webdav Version: 6.6.2
Severity: normal Keywords:
Cc: Architecture:
Platform: macOS 10.13

Description (last modified by Onnonymous)


I have a URL like this (with a Macaroon based authentication token):

With CURL this works fine, so the token is correct. However, Cyberduck does not seem to be able to handle this. It asks for the username/password, and after that it asks for a client certificate, but whatever I fill in, it doesn't work. I get this error:

Listing directory ?authz=token failed. Unexpected response (404 Not Found). Please contact your web hosting service provider for assistance.

I found this in the server log:

I see 2 issues here:

  1. The ? in the GET URL appears to be URLencoded;
  2. The path, in this case /, is appended to the GET URL, which alters the token so that authentication fails. Also, the path is not parsed by the server this way.

So I would like to request:

  1. That a GET URL is not URLencoded;
  2. That any path is inserted before the GET variables, instead of appended at the end.

Thanks! Onno

Change History (4)

comment:1 Changed on Jun 25, 2018 at 11:20:50 AM by Onnonymous

The Macaroon may be provided as a HTTP(S) header. So, the possibility to add custom headers would be a solution. See, page 9, for the specification.

However, I still think that it is a bug and it would be great if you could fix it.

comment:2 Changed on Jun 25, 2018 at 11:23:14 AM by Onnonymous

  • Description modified (diff)

comment:3 Changed on Jul 9, 2018 at 7:12:03 PM by dkocher

  • Summary changed from Handling of WebDAV GET URL broken to Custom path is always URI encoded and normalized with trailing slash in requests

comment:4 Changed on May 31, 2019 at 3:28:26 PM by dkocher

  • Resolution set to wontfix
  • Status changed from new to closed

We cannot easily fix this. Users have no idea of URI encoding and we should not expect them to escape the path set in the bookmark.

Note: See TracTickets for help on using tickets.