endgame

The broad strokes of this discussion still look relevant, though the details appear to have changed (building is nixified instead of shake-ified). Keeping open for now, since a broader roadmap...

Marking as a "post 2.0" release, since we'll want to see how things behave after everything lands in `develop`. Note that `tls` is up to `1.5.x` now.

This looks like a good combination of easy/useful that I will optimistically assign it to the 2.0 Milestone. If I can't work out the generator code, I'll punt it to...

Let's delay doing this and think about solving #180 instead - that will provide us with a canonical way to get the response code for any response, as well as...

Yeah, it's a bit hacky. It would be good if we did something better and supported other S3-compatible object stores. What does correct behaviour look like here? I'm not familiar...

I would love to see better support for non-S3 support stores. Unfortunately, I don't have capacity to research and build something like that right now, and my priority is on...

Reclassifying as a bug and adding it to 2.0 since it's a regression that affects @basvandijk.

This is the config that tells the generator to wire in vhost rewriting: https://github.com/brendanhay/amazonka/blob/26466244b5a23b29ba8894ec89d922e6a6835a05/configs/services/s3.json#L7-L36 This is where the rewrite happens: https://github.com/brendanhay/amazonka/blob/26466244b5a23b29ba8894ec89d922e6a6835a05/lib/amazonka-core/src/Amazonka/Request.hs#L169-L194 I'm not sure `ToVHost` is right, because the service...

#797 also has other discussion, including a possible S3VHost setting to go in the Service record.

Seems OK under #761