s3 tm upload req resp #3761
s3 tm upload req resp #3761
Conversation
|
A new generated diff is ready to view.
A new doc preview is ready to view. |
| */ | ||
|
|
||
| pub use crate::upload::request::UploadRequest; | ||
| pub use crate::upload::response::UploadResponse; |
There was a problem hiding this comment.
I'd hesitate to name these "Request" and "Response" when they don't correlate 1:1 with HTTP requests and responses. It makes the library confusing to talk about, internally and with customers. This happens all the time talking about "meta requests" in aws-c-s3.
Instead of Request, maybe: UploadOptions? UploadSettings? UploadConfig? UploadParams?
Instead of Response, maybe: UploadOutcome? UploadSummary? UploadReport?
| /// </note> <note> | ||
| /// <p>This functionality is not supported for directory buckets.</p> | ||
| /// </note> | ||
| pub content_md5: Option<String>, |
There was a problem hiding this comment.
We can't allow this, or checksum_crc32 and friends, since it might get sent MPU
| /// Common response fields for uploading an object to Amazon S3 | ||
| #[non_exhaustive] | ||
| #[derive(Clone, PartialEq)] | ||
| pub struct UploadResponse { |
There was a problem hiding this comment.
We'll want to expose the Parts, too. So users can access the per-part checksums
Description
Follow up PR to #3756 that is one part of an initial multipart upload support.
This PR is simple, it just defines new request and response types for the upload API. These are nearly identical to what is found in the
aws_sdk_s3crate with the exception of the body type that leverages the newInputStreamtype (naming bikeshed still planned for later) for the body rather thanByteStream.By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.