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

Populate storage class from HEAD Object responses. #3691

merged 1 commit into from Mar 2, 2017


None yet
2 participants
Copy link

houglum commented Mar 1, 2017

Also fixes two failing ACL tests.

if (self._storage_class is None and
provider.get_provider_name() == 'aws'):
# S3 docs for HEAD object requests say S3 will return this
# header for all objects except Standard storage class objects.

This comment has been minimized.


mfschwartz Mar 1, 2017


I don't understand why you want to populate the storage class in this case, if the S3 docs say they won't populate the header in this case?

This comment has been minimized.


houglum Mar 2, 2017


If the object were of a nondefault class (e.g. STANDARD_IA), this header would be present with that value; only then does S3 add the storage class header to the response. As such, we can assume it's STANDARD when the header is not present. This allows us to avoid calling the _get_storage_class method, which performs an additional self.bucket.list call. Rather than do this (and potentially fail if the user doesn't have list permisson), we can obtain the storage class here.

For context, GSUtil will take advantage of this to populate the object's storage class for the output of gsutil stat <obj_url> and gsutil ls -L <obj_url>.

@mfschwartz mfschwartz merged commit 315b76e into boto:develop Mar 2, 2017

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed

@houglum houglum referenced this pull request Apr 14, 2017


Release 2.47? #3718

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment