S3 Addressing Style: Should `S3AddressingStyleAuto` only rewrite *.amazonaws.com DNS names?

[endgame]

@magthe notes that setting S3AddressingStylePath is necessary to use amazonka-s3 with LocalStack (and maybe other non-S3 data stores?): https://magnus.therning.org/2023-12-09-getting-amazonka-s3-to-work-with-localstack.html

Should we do this automatically when S3AddressingStyleAuto is set? My current thinking is "no", because as far as I can tell botocore doesn't do anything fancy here

Also, LocalStack claims to support vhost-style requests if the endpoint name is set correctly: https://docs.localstack.cloud/user-guide/aws/s3/

By default, most SDKs will try to use Virtual-Hosted style requests and prepend your endpoint with the bucket name. However, if the endpoint is not prefixed by s3., LocalStack will not be able to understand the request and it will most likely result in an error.

[endgame]

I'll leave this open for a week, then close it, but if new info comes through even after close, I'm happy to reopen.

[magthe]

TBH I don't think Amazonka should do more than is already done.

The time I spent looking for the solution to my problem was due to two things:

• localstack is inconsistent in when it produced errors, e.g. listing the contents of a bucket will sometimes result in an empty list (even when there are objects in it) and other times produce an error.
• localstack is producing completely unrelated errors, the error I saw most was one about the XML being incorrect and never ever was the addressing style even hinted at.

Since the error I saw was so completely unrelated it was difficult to search for a solution and it wasn't until a good hour of reading through error reports and questions on StackOverflow that I found a comment about addressing style. Once I found that it wasn't difficult to find the solution in the Amazonka docs. (Oh, and I have to point out that the documentation of S3AddressingStyle is very nice!)

I place no blame on the error message Amazonka produces:

(ConnectionFailure Network.Socket.getAddrInfo (called with preferred socket type/protocol: AddrInfo {addrFlags = [], addrFamily = AF_UNSPEC, addrSocketType = Stream, addrProtocol = 0, addrAddress = 0.0.0.0:0, addrCanonName = Nothing}, host name: Just "bar.localhost", service name: Just "4566"): does not exist (Name or service not known)))

I don't think it's the client's place to interpret that further. Now that I know about the different addressing styles that error message makes more sense, and I think that's a fairly good standard for errors, that they are understandable by someone with knowledge about AWS.

I'm considering opening a ticket on localstack related to its inconsistency in generating errors and the nature of those errors. IMO it's really there the fault is and where the improvement should be made.

[endgame]

If you're happy, I'm happy. Thanks for the quick response.