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
Which s3 compatible service or software stack are you using?
Because it is a case where it is complicated to know what should be the correct behavior:
On AWS s3, there couldn't be a "sub-path" before the bucket. So there spec does not cover such a case.
In theory you can't have /s3/bucket_name, because otherwise it is "s3" that will be the bucket name.
If we were to ignore what i can call the "service path" (ie "/s3"), the signature would be kind of broken, because the same signature will work with all "services paths".
@artashesbalabekyan Would you be able to give more details about the service that you are using to be encountering this situation?
Otherwise i will have to close this issue.
For example I want use a http://localhost:8080/s3 as an endpoint. And in this case s3cmd calculates the v4 signature wrong.
It should use the hostname http://localhost:8080 not the http://localhost:8080/s3 for signature calculation.
Any ideas about it? How it can be solved?
The text was updated successfully, but these errors were encountered: