> … a relatively small part of the API requires HTTP requests to be sent to generic S3 endpoints (such as s3.us-east-2.amazonaws.com), while the vast majority of requests must be sent to the URL of a target bucket.
I believe this is talking about virtual-hosted style and path-style methods for accessing the S3 API.
From what I can see [0], at least for the REST API, the entire API works either with virtual-hosted style (where the bucket name is in the host part of the URL) and path-style (where the bucket name is in the path part of the URL). Amazon has been wanting folks to move over to the virtual-hosted style for a long time, but (as of 3+ years ago) the deprecation of path-style has been delayed[1].
This deprecation of path-style requests has been extremely important for products implementing the S3 API. For example…
* MinIO uses path-style requests by default, requiring you set a configuration variable[2] (and set up DNS appropriately) to handle the virtual-hosted style.
* Wasabi supports both path-style and virtual-hosted style, but "Wasabi recommends using path-style requests as shown in all examples in this guide (for example, http://s3.wasabisys.com/my-bucket/my-object) because the path-style offers the greatest flexibility in bucket names, avoiding domain name issues."[3].
Now here's the really annoying part: The REST API examples show virtual-hosting style, but path style works too!
For example, take the GetBucketTagging example. Let's say you have bucket "karl123456" in region US-West-2. The example would have you do this:
GET /?tagging HTTP/1.1
Host: karl123456.s3.amazonaws.com
But instead, you can do this:
GET /karl123456?tagging HTTP/1.1
Host: s3.us-west-2.amazonaws.com
!!
How do I know this? I tried it! I constructed a `curl` command do to the path-style request, and it worked! (I didn't use "karl123456", though.)
So hopefully that helps resolve at least one of your S3 annoyances :-)
> … a relatively small part of the API requires HTTP requests to be sent to generic S3 endpoints (such as s3.us-east-2.amazonaws.com), while the vast majority of requests must be sent to the URL of a target bucket.
I believe this is talking about virtual-hosted style and path-style methods for accessing the S3 API.
From what I can see [0], at least for the REST API, the entire API works either with virtual-hosted style (where the bucket name is in the host part of the URL) and path-style (where the bucket name is in the path part of the URL). Amazon has been wanting folks to move over to the virtual-hosted style for a long time, but (as of 3+ years ago) the deprecation of path-style has been delayed[1].
This deprecation of path-style requests has been extremely important for products implementing the S3 API. For example…
* MinIO uses path-style requests by default, requiring you set a configuration variable[2] (and set up DNS appropriately) to handle the virtual-hosted style.
* Wasabi supports both path-style and virtual-hosted style, but "Wasabi recommends using path-style requests as shown in all examples in this guide (for example, http://s3.wasabisys.com/my-bucket/my-object) because the path-style offers the greatest flexibility in bucket names, avoiding domain name issues."[3].
Now here's the really annoying part: The REST API examples show virtual-hosting style, but path style works too!
For example, take the GetBucketTagging example. Let's say you have bucket "karl123456" in region US-West-2. The example would have you do this:
GET /?tagging HTTP/1.1
Host: karl123456.s3.amazonaws.com
But instead, you can do this:
GET /karl123456?tagging HTTP/1.1
Host: s3.us-west-2.amazonaws.com
!!
How do I know this? I tried it! I constructed a `curl` command do to the path-style request, and it worked! (I didn't use "karl123456", though.)
So hopefully that helps resolve at least one of your S3 annoyances :-)
[0]: https://docs.aws.amazon.com/AmazonS3/latest/userguide/RESTAP...
[1]: https://aws.amazon.com/blogs/aws/amazon-s3-path-deprecation-...
[2]: https://min.io/docs/minio/linux/reference/minio-server/setti...
[3]: https://docs.wasabi.com/docs/rest-api-introduction