-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
s3manager Uploader returns URL encoded Location for bigger files (multipart upload) #1385
Comments
Ok. Thanks for your quick reply. I didn't find the existing issue, so sorry for posting it again. |
@mtestrot - What is your use case for the |
I store and pass around the location as a reference to retrieve the file later on. So everything the using application has to know is the reference in order to |
@mtestrot - Other than the inconsistency of the escaping, does the URL work? |
Yes. The URL works as soon as we do a string replace before passing it around: Of course there will be a Problem if the URL contains a part which has to be URL encoded. For example if a path-segment from the S3 Object Key is build from a URL. But this is currently no use case for us. So the workaround works. |
@mtestrot - Thank you for the information. I will go ahead and try to reproduce this on my end as well. Can you provide a code snippet trying to reuse the |
Hi, I gathered some code for an isolated test case:
|
@mtestrot thank you for the example. I'll go ahead and discuss with the other SDKs to have some consistency on dealing with this issue. |
@mtestrot - Taking a look at the code that you provided, can you instead just call get object instead of trying to build the request yourself? Why is it that you are trying to do this? What's the specific use case? |
Hi, The reason I'm building the request by myself is the reduced dependency for the GET part of the TestLocation function. In production the program which stores the S3 object is different from the program which retrieves/gets the object. So the GET part - apart from the signer - has no dependency on the sdk. |
I also got this problem, see here: Original key I use on the uploader is this: On s3 it gets saved to this: Smaller files return this (spaces are encoded): Large files return this (slash is encoded): |
Just bumped into this as well. We are saving backups to S3. I'm not sure what the threshold is but very small backups (< 1MB) don't encode while our medium (~14 MB) and larger (>100MB) size backups encode. |
The S3 Upload manager will automatically switch to multipart mode when the content to upload is larger than |
Updates the Location returned value of S3 Upload's Multipart UploadOutput type to be consistent with single part upload URL. This update also brings the multipart upload Location inline with the S3 object URLs created by the SDK Fix aws#1385
I created #2453 PR to address this issue of inconsistent URL locations being returned. The URL value returned is updated to use the same pattern as the Single part upload URL. |
Updates the Location returned value of S3 Upload's Multipart UploadOutput type to be consistent with single part upload URL. This update also brings the multipart upload Location inline with the S3 object URLs created by the SDK Fix #1385
Please fill out the sections below to help us address your issue.
Version of AWS SDK for Go?
v1.10.6
Version of Go (
go version
)?go1.8 windows/amd64
What issue did you see?
The upload function from the s3manager returns an URL encoded location (UploadOutput.location) if a bigger file (>5MB) is uploaded. For smaller files (<5MB) the location is not URL encoded which in my opinion is the right behaviour.
I guess the behaviour is different for multipart uploads and singlepart uploads.
Steps to reproduce
// filesize = 5 * 1024 * 1024 Byte
uploader = s3manager.NewUploader(sess)
output, err := uploader.Upload(&s3manager.UploadInput{
Bucket: aws.String("mybucket"),
Key: aws.String("1234"),
Body: bufio.NewReader(file),
})
fmt.Println(output.Location) // should NOT be URL encoded
The text was updated successfully, but these errors were encountered: