endpointOverride with bare IPv6 address fails valid domain check

[adamsb6]

Describe the bug

I've found that with a bare IPv4 address I'm able to set endpointOverride and successfully make requests against a non-AWS S3 endpoint.

However, with a bare IPv6 address, we get this error:

CopyFileAllAtOnce file pair 0:13675366 failed after 1 attempts. 0 operation 0:13675367 failed after 1 attempts. Operation error message: S3Exception:S3 exception: error msg: Invalid DNS Label found in URI host  S3ErrorCode:14 Retriable:false IsWrite:false Message:path: s3://ai/foo.txt ApiCall: S3: HeadObject() HL: getObjectMetadata()

I found that the problem arises here: https://github.com/aws/aws-sdk-cpp/blob/main/src/aws-cpp-sdk-core/source/utils/DNS.cpp#L43

The endpoint gets passed into the function. We check if it has any . characters, and if not, fail the IsValidHost() function. Bare IPv4 addresses pass this test. But bare IPv6 addresses, lacking . characters, fail the test.

I also found that if I make an /etc/hosts entry for the IPv6 address I want to use and pass that instead, the client works. So connectivity works if we don't block ourselves with this test.

Can you rework it so that we also pass this test if the endpoint is a bare IPv6 address?

When searching to see if this had already been raised, I saw this issue has come up before a couple of other times without being diagnosed:
#1857
#3054

Regression Issue

• Select this option if this issue appears to be a regression.

Expected Behavior

I should be able to set an IPv6 address as my endpoint, and it should work.

Current Behavior

The client fails out with a message that the endpoint has an invalid DNS label.

Reproduction Steps

I wasn't trying to reach ::1, but you should be able to easily repro by instantiating a client with a config that has endpointOverride set to https://[::1]:80.

Possible Solution

Fix the cited check to allow valid IPv6 addresses to pass the check.

Additional Information/Context

No response

AWS CPP SDK version used

1.11.328

Compiler and Version used

clang 17

Operating System and version

CentOS 9

[sbera87]

I confirm your observation and am working on a fix