We have never set values which are empty on the request
because they are perhaps not useful in the List query,
but this assumption is wrong when there are restricted
policies for a given user, because empty is actually
a valid value in IAM or Bucket policy conditions.
For example following condition would never work with our
ListObjects call and AWS cli would work fine.
"Condition": {
"StringEquals": {
"s3:prefix": [
"",
"data/",
"data"
],
"s3:delimiter": [
"/",
""
]
}
}
The reason is empty or not prefix and delimiter should be
added to the query param in List operation, such that server
can use the value to validate the policies for the incoming
request.
Refer minio/minio-go#1064
The return type for this function should be "string contains URL to
upload the object" instead of "string contains URL to download the
object"
Also fixed formatting issues.
S3 Spec requires canonicalized header string to have all extra
spaces trimmed down to a single space. This PR fixes#277, where
metadata with extra spaces in the value was causing a signature
verification mismatch.
Handle zero byte streams passed to PutObjectAsync with size -1
(unknown size stream) by uploading a single part with 0 bytes
before completing the multipart upload.
ListParts is never fully complete in its output,
there is always a possibility that the List is
partial where another PutObjectPart() is being
uploaded in parallel.
While it may seem like ListParts and ListMultipartUploads
provide the possibility of resuming an upload, it would
be a mistake as these APIs were inherently never meant do
these things. This is one of the reasons why Amazon
recommends that one should avoid using these API calls to
complete or add parts to an upload - they instead
recommend to remember the parts being uploaded at the client.
poornas