You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, s3-beam uses https://s3-<region>.amazonaws.com/<bucket> as the upload URL path (path-style). It is also possible to upload to https://<bucket>.s3-<region>.amazonaws.com (virtual-host style).
AWS is planning to deprecate path-style addressing for buckets created after September 30, 2020. There are also performance and resilience benefits for switching to virtual-host style addressing for existing buckets.
The switch is transparent for many buckets, but is not for buckets with a . in the bucket name (among others). AWS doesn't currently create a valid certificate for these buckets, so you will get TLS errors when you try to upload/download from them.
Using #38 would fix this for us, as it defaults to using virtual-host style addressing, unless the bucket has a . in it.
In the meantime, you can use the upload-url parameter to s3-sign to override the upload URL.
The text was updated successfully, but these errors were encountered:
danielcompton
changed the title
Allow using the hostname based bucket URL
Switch to using virtual-host style URLs when possible
Sep 24, 2019
In a virtual-hosted–style URL, the bucket name is part of the domain name in the URL. For example:
* http://bucket.s3-aws-region.amazonaws.com
* http://bucket.s3.amazonaws.com Note
Buckets created in Regions launched after March 20, 2019 are not reachable via the https://bucket.s3.amazonaws.com naming scheme.
Currently, s3-beam uses
https://s3-<region>.amazonaws.com/<bucket>
as the upload URL path (path-style). It is also possible to upload tohttps://<bucket>.s3-<region>.amazonaws.com
(virtual-host style).AWS is planning to deprecate path-style addressing for buckets created after September 30, 2020. There are also performance and resilience benefits for switching to virtual-host style addressing for existing buckets.
The switch is transparent for many buckets, but is not for buckets with a
.
in the bucket name (among others). AWS doesn't currently create a valid certificate for these buckets, so you will get TLS errors when you try to upload/download from them.Using #38 would fix this for us, as it defaults to using virtual-host style addressing, unless the bucket has a
.
in it.In the meantime, you can use the
upload-url
parameter tos3-sign
to override the upload URL.The text was updated successfully, but these errors were encountered: