Interoperability with path-style requests

[duck133]

Hey,

in version 7.2.0, you removed the support for path style URL generation for the S3 protocol: "Deprecated path-style request usage for (AWS GovCloud) (#10824)"

I am using CyberDuck to connect to en enterprise S3 cluster, that still and only uses path-style. Would there maybe be the option to bring the support back?

Would be fine for me, if this is then an additional checkbox in the connection settings to use path style.

But currently I am forced to use an old version no Cyberduck and repeatedly ask my, why they can't connect with their (newer) version of CyberDuck.

Thanks a lot.

[dkocher]

Also in #10888.

[dkocher]

Is this instance publicly reachable over the Internet to reproduce the issue?

[dkocher]

We have implemented a fallback in r48332 if resolving the DNS name for the bucket fails.

[dkocher]

Also as of r48257 we use path-style requests when the hostname is an IP address.

[duck133]

The instance is only partly reachable from the internet, sadly.

It is an instance of DELL ECS, which besides its enterprise hardware, also has a free to use community edition: ​https://github.com/EMCECS/ECS-CommunityEdition/releases

Hostname would be something like: namespace.mydomain.com and to not get SSL-Certificate problems, hostnames can't look like bucket.namspace.mydomain.com as it would require a *.*.mydomain.com SSL-Cert. Therefore this instance sticks to namepspace.mydomain.com/bucket

But if you need me to do anything / send any error messages, that would help you to identify the issue, I can gladly do.

[tsammut]

Hello. Thanks for sharing such a great tool!

Unfortunately, some environments use a wildcard DNS entry that will always succeed, preventing Cyberduck from falling-back to path-style access. Would it be possible to have a configuration setting (or similar) that disables virtual host style access completely, please?

Thanks!