Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow connecting with path-style requests #11416

Closed
cyberduck opened this issue Dec 11, 2020 · 3 comments
Closed

Allow connecting with path-style requests #11416

cyberduck opened this issue Dec 11, 2020 · 3 comments

Comments

@cyberduck
Copy link
Collaborator

@cyberduck cyberduck commented Dec 11, 2020

ae06bfd created the issue

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: e5e2a97
  • Situation 2: When A/AAAA record for bucket.hostname.example is answered with NXDOMAIN: af0c7ed

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.

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Dec 11, 2020

@dkocher commented

You can disable the use of virtual host style requests by setting the configuration option s3service.disable-dns-buckets to true.

Loading

@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Dec 11, 2020

@dkocher commented

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

Loading

@cyberduck cyberduck closed this Dec 11, 2020
@cyberduck
Copy link
Collaborator Author

@cyberduck cyberduck commented Dec 11, 2020

ae06bfd commented

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

Loading

@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 27, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant