-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Remove hardcoded 's3.amazonaws.com' for virtual hosted addressing
This removes the hard coded references to 's3.amazonaws.com' when using the virtual hosted addressing mode of S3 and instead uses regionalized endpoints when converting to virtual hosted addressing. For example, given a bucket 'foo' in us-west-2 and a key 'bar', we would convert the URL from `s3.us-west-2.amazonaws.com/foo/bar` to `foo.s3.amazonaws.com/bar`. With this change we'll now convert the URL to `foo.s3.us-west-2.amazonaws.com/bar`. When the initial code for 's3.amazonaws.com' was first added to botocore, it provided a number of benefits: 1. You could avoid a 301 response by using `.s3.amazonaws.com`. This is because the DNS would resolve to an endpoint in the correct region, and the older signature version `s3` didn't include a region name as part of its signing process. The end result is that a user did not have to correctly configure a region for an S3 bucket, they'd automatically get to the correct region due to the DNS resolution. 2. The 301 PermanentRedirect responses did not include any structured data about the correct region to use so it wasn't easy to know which region you _should_ be sending the request to. As a result, 301 responses weren't automatically handled and ended up just raising an exception back to the user. Since this code was first introduced there were several things that have changed: 1. The introduction of the `s3v4` signature version, which requires a correct region name as part of its signature. Signing a request with the wrong region results in a 400 response. As a result, it didn't matter if `foo.s3.amazonaws.com` got you to the right region, if the request was _signed_ with the wrong region, you'd get a 400 response. 2. The 301 response (as well as most responses from S3) contain request metadata that tell you which region a bucket is in. This means that it's now possible to automatically handle 301 responses because we know which region to send the request to. 3. The introduction of various partitions outside of the `aws` partition, such as `aws-cn` meant there were other TLDs we needed to handle. The "hack" put in place in botocore was to just disable virtual hosted addressing in certain scenarios. Given all this, it makes sense to no longer hardcode `s3.amazonaws.com` when converting to virtual hosted addressing. There's already a growing number of edge cases where we have to disable this, and most importantly it's not needed anymore.
- Loading branch information
Showing
5 changed files
with
23 additions
and
23 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters