[Cyberduck-trac] [Cyberduck] #11416: S3 path-style requests not working
Cyberduck
trac at cyberduck.io
Fri Dec 11 12:17:16 UTC 2020
#11416: S3 path-style requests not working
----------------------+----------------------
Reporter: georgp | Owner:
Type: defect | Status: new
Priority: normal | Milestone:
Component: s3 | Version: 7.7.2
Severity: normal | Resolution:
Keywords: | Architecture:
Platform: macOS 11 |
----------------------+----------------------
Description changed by dkocher:
Old description:
> Hi,
>
> according to the changelog of 7.2.0 and this ticket
> (https://trac.cyberduck.io/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:
> https://trac.cyberduck.io/changeset/48257
> - Situation 2: When A/AAAA record for bucket.hostname.example is answered
> with `NXDOMAIN`: https://trac.cyberduck.io/changeset/48332
>
> 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
> (https://trac.cyberduck.io/ticket/10956#comment:10) or with a nameserver
> of their provider which answers to requests with own IP addresses
> (https://trac.cyberduck.io/ticket/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.
New description:
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:
https://trac.cyberduck.io/changeset/48257
- 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.
--
--
Ticket URL: <https://trac.cyberduck.io/ticket/11416#comment:1>
Cyberduck <https://cyberduck.io>
Libre FTP, SFTP, WebDAV, S3 & OpenStack Swift browser for Mac and Windows
More information about the Cyberduck-trac
mailing list