aws s3 cp with --metadata-directive REPLACE not guessing correct Content-Type #6895
-
Confirm by changing [ ] to [x] below to ensure that it's a bug:
Describe the bug This behavior is not present when running the same command from Ubuntu or when using awscli v1 from macOS. SDK version number Platform/OS/Hardware/Device To Reproduce (observed behavior) Expected behavior Logs/output Additional context
This issue is not present in awscli v1, where the |
Beta Was this translation helpful? Give feedback.
Replies: 10 comments
-
Hi @bersalazar, Thanks for pointing this out— I was able to reproduce. Marking as a bug for now. |
Beta Was this translation helpful? Give feedback.
-
Hi @bersalazar, #6115 should take care of this— next V2 release will hopefully be next week. Please feel free to reach out if you're still having issues after that! |
Beta Was this translation helpful? Give feedback.
-
Hi @bersalazar, After a review of the v1 behavior and the PR I mentioned in my last comment, it looks like we actually explicitly removed support for guessing mimetypes for copies in v2 now that we copy over metadata— it was only by accident that v1 supports injecting mimetypes. Even in the docs for v1 Would you be able to clarify what your particular use case is for this? We may have a current set of parameters that could work and we're hesitant to add this 'mistake' back if there's not a strong reason for it. Thanks! |
Beta Was this translation helpful? Give feedback.
-
Hi @stobrien89 Thanks for the replies. The use case is indeed when copying files from bucket to bucket. The source and target buckets are the same in this case, the idea is to use |
Beta Was this translation helpful? Give feedback.
-
Hi @bersalazar, I may be missing something here, but I did some testing with |
Beta Was this translation helpful? Give feedback.
-
hey @stobrien89,
Content-Type is correctly set on I understand |
Beta Was this translation helpful? Give feedback.
-
Hi @bersalazar, My apologies— I almost forgot you were needing to copy a single file rather than an entire directory. So the 'correct' behavior is actually found in v2 for reasons I mentioned before— if you compare debug logs between v1 and v2 for In this case, you may be better off not specifying To test, you can create a blank index.html file (or something to that effect), use Hope this helps! |
Beta Was this translation helpful? Give feedback.
-
OK, thanks for the help and clarification @stobrien89, really appreciated! |
Beta Was this translation helpful? Give feedback.
-
Of course— Hope this works for you! Please feel free to reach out at any time if you have any additional questions. |
Beta Was this translation helpful? Give feedback.
-
Quick Tip
|
Beta Was this translation helpful? Give feedback.
Hi @bersalazar,
My apologies— I almost forgot you were needing to copy a single file rather than an entire directory.
So the 'correct' behavior is actually found in v2 for reasons I mentioned before— if you compare debug logs between v1 and v2 for
aws s3 cp s3://src-bucket s3://dest-bucket --cache-control 'no-cache' --metadata-directive REPLACE
, v1 actually sends thecontent-type
header as a part of the copy request.REPLACE
, in theory, should only have the metadata values that were specified by the CLI command.In this case, you may be better off not specifying
--metadata-directive REPLACE
in v2, as the correctcontent-type
is retained during the copy, or manually specify--content-type
as