I'm not aware of any issues, but is there a reason to specify noAcl? What if you're patching the ACL, don't you want to see the new one?

Projection=full won't return the acl to you unless you have OWNER permission on the bucket/object anyway.

RE: "is there a reason to specify noAcl" That is a discussion in flux. Currently ACL behavior is managed via dedicated objects instead of directly with the Blob or Bucket. (UPDATE: I don't think this is necessarily the right abstraction, but am in the process of making "interface drive design" document to discuss.)

RE: "won't return the acl to you unless you have OWNER permission" I would wager that was the original author's concern. Thanks!

Coverage remained the same at 100.0% when pulling 853d240 on dhermes:ditch-full-projection-in-patch into d34a15e on GoogleCloudPlatform:master.

The API docs say:

projection  string  Set of properties to return. Defaults to no_acl.

Note: Currently only works if you override the default and specify full.

Acceptable values are:

    "full": Include all properties.
    "noAcl": Omit acl and defaultObjectAcl properties.

@tseaver Thanks for pointing this out. @thobrla is that still true? When was it true? "only works" is somewhat vague as it is.

@dhermes It has to do with the way that patch currently is implemented. I suspect that if you had custom ACLs on your bucket that if you patch with no_acl, you inadvertently reset your bucket ACL to project-private.

I see.

• Do you mean sending a patch with an empty list in the acl field or none at all? (ISTM you're describing a process where a GET is performed internally with noAcl and then the contents are updated based on the PATCH contents, and then this just gets inserted directly.)
• Are there plans to fix / address / document this behavior?
• Is there a corresponding issue with objects or is it limited to buckets?

Adding the don't merge label. It seems from @Capstan feedback (and just from designing the optimal interface in #761) that projection=noAcl isn't something we need. Splitting apart ACLs from other properties isn't worth the payload size savings (1KB to 2KB).

Adding the don't merge label. It seems from @Capstan feedback (and just from designing the optimal interface in #761) that projection=noAcl isn't something we need. Splitting apart ACLs from other properties isn't worth the payload size savings (1KB to 2KB).

Closing, based on "we do not need this" and also there is no possible way we would successfully wrangle a PR this old in even if we did.