Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

S3 URL deprecation #79

Open
Cinderhaze opened this issue May 6, 2019 · 0 comments
Open

S3 URL deprecation #79

Cinderhaze opened this issue May 6, 2019 · 0 comments
Assignees

Comments

@Cinderhaze
Copy link

According to information from the forums located here ( https://forums.aws.amazon.com/ann.jspa?annID=6776 ), the path naming will need to be updated to always use https://.s3./ instead of https://s3.//. Currently that pattern is used for us-east-1 as the region, but not for non-us-east-1 or CN regions.

Amazon S3 currently supports two request URI styles in all regions: path-style (also known as V1) that includes bucket name in the path of the URI (example: //s3.amazonaws.com//key), and virtual-hosted style (also known as V2) which uses the bucket name as part of the domain name (example: //.s3.amazonaws.com/key). In our effort to continuously improve customer experience, the path-style naming convention is being retired in favor of virtual-hosted style request format. Customers should update their applications to use the virtual-hosted style request format when making S3 API requests before September 30th, 2020 to avoid any service disruptions. Customers using the AWS SDK can upgrade to the most recent version of the SDK to ensure their applications are using the virtual-hosted style request format.

Virtual-hosted style requests are supported for all S3 endpoints in all AWS regions. S3 will stop accepting requests made using the path-style request format in all regions starting September 30th, 2020. Any requests using the path-style request format made after this time will fail.

If there is any reason why your application is not able to utilize the virtual-hosted style request format, or if you have any questions or concerns, please reach out to AWS Support.\

We may also want to adjust the parse_url logic to return the base awsurl to remove the case statement that does not work for other regions that use a different AWS endpoint, but that can be covered in another issue.

One issue that may be worth addressing as a part of this change - if a bucket name has a . in it, do we properly send a warning/error up to the user of this plugin? Is there a reasonable exception that gets flowed up, or should we manually add the warning to the case?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants