Closed chreekat closed 6 months ago
I think to solve your immediate problem, you can set the S3 addressing style when you override the Service
.
Can you try a similar request with an official SDK and see what it does? Official SDKs might be a bit better about deciding when to use vhost addressing style (in which case we should copy some of their logic), or they might make a similar mistake (in which case behaving like other SDKs is probably more important than adding magic).
I discovered I was using https://hostname
as my endpoint when I should have just used hostname
.
I simply expected to see the bucket name in the url rather than in the hostname, though I'm not sure why.. So that is what caught my eye in the exception message. It was especially noticeable when the line read host = "my-cool-bucket.https://my-cool-hostname
, which is clearly nonsense.
So I suppose there is no bug here, after all. Though as a feature it might be nice if including the protocol was allowed, since it's actually required in the AWS_ENDPOINT_URL environment variable.
I'll close this in the meanwhile.
Do we even want to respect AWS_ENDPOINT_URL
? I see it in https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-envvars.html , which is more of a CLI config option than an SDK config option.
Maybe there's some distinction you know better than I do. For me, it's grouped in with AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY as "things I need to set on a per-environment basis".
Seems like it's supported by the SDK too: https://docs.aws.amazon.com/sdkref/latest/guide/feature-ss-endpoints.html
I've made a separate issue: #980
Repro:
Result of
cabal run
:The
host
header looks pretty wrong! Is this possibly a bug in amazonka?