Cyberduck Mountain Duck CLI

#11416 closed enhancement (duplicate)

Allow connecting with path-style requests

Reported by: georgp Owned by:
Priority: normal Milestone:
Component: s3 Version: 7.7.2
Severity: normal Keywords:
Cc: Architecture:
Platform: macOS 11

Description (last modified by dkocher)

Hi,

according to the changelog of 7.2.0 and this ticket (#10956), the possibility to configure path-style for S3 was removed. Later two mechanisms were added to automatically detect when path-style should be used:

  • Situation 1: When server is an IP address: r48257
  • Situation 2: When A/AAAA record for bucket.hostname.example is answered with NXDOMAIN: r48332

However, there are use-cases when both situations don't apply but path-style might still be required for the connection to work.

For me situation 1 will not apply as I have to use a domain name so the SSL certificate can be verified. Situation 2 also does not apply because we're using wildcard DNS records for *.hostname.example. In this case Cyberduck checks for a A record of bucket.hostname.example which obviously exists but it does not point to the correct system as the S3 system is configured to work with path-style buckets only.

Other people are having the same issue with wildcard DNS setup (#10956#comment:10) or with a nameserver of their provider which answers to requests with own IP addresses (#10888#comment:31, bad practice but it's out there..).

Therefore it would be great to have a config option to disable the automatic detection and specifically set the mode to path-style.

Besides that it seems that the mechanism for situation 2 (auto-detect with DNS lookup) is broken on MacOS 11.0.1 and Windows 10, Cyberduck 7.7.2. I tried it with a different S3 system that does not rely on wildcard DNS records. I am able to connect to the system, list buckets and files but as soon as I initiate a download, an error message appears, clearly indicating it is trying to resolve the non-existing domain and fails:

Failure to read attributes of file.png.

bucket.hostname.example. DNS is the network service that translates a server name to its Internet address. This error is most often caused by having no connection to the Internet or a misconfigured network. It can also be caused by an unresponsive DNS server or a firewall preventing access to the network.

So it seems as if the auto-detection works for the initial connect and file browser but not for downloading files.

Let me know in case I should provide more details.

Change History (7)

comment:1 Changed on Dec 11, 2020 at 12:17:15 PM by dkocher

  • Description modified (diff)

comment:2 Changed on Dec 11, 2020 at 12:17:55 PM by dkocher

  • Description modified (diff)

comment:3 Changed on Dec 11, 2020 at 12:21:29 PM by dkocher

You can disable the use of virtual host style requests by setting the configuration option s3.bucket.virtualhost.disable to true.

Version 0, edited on Dec 11, 2020 at 12:21:29 PM by dkocher (next)

comment:4 Changed on Dec 11, 2020 at 12:22:31 PM by dkocher

  • Type changed from defect to enhancement

comment:5 Changed on Dec 11, 2020 at 12:22:49 PM by dkocher

  • Summary changed from S3 path-style requests not working to Allow connecting with path-style requests

comment:6 Changed on Dec 11, 2020 at 12:25:41 PM by dkocher

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

Thanks for the detailed report and summarizing the issues. We have reoepened #10956.

comment:7 Changed on Dec 11, 2020 at 12:47:16 PM by georgp

Thanks, the quick reply. I can confirm that using the hidden configuration option solves the problem for now.

Note: See TracTickets for help on using tickets.