GCS Copy (and ReWrite) operations includes copying the original blob's metadata but also provides
a way to override the blob's metadata (such as content-type, contentLanguage, metadata fields).
When using the apiary copy or rewrite operations and supplying a StorageObject content it is going
to be used for blob's metadata overriding values. However, in this case content-type is required (and operation will fail if one is not provided).
Currently the implementation will silently ignore any overriding metadata if content-type is missing (as
in that case it will not pass the StorageObject content).
This is unexpected and not documented.
Several options:
Just document this behaviour in the Storage.CopyRequest.Builder.target method.
Change Storage.CopyRequest.Builder target settings to get either BlobId or BlobInfo (and in case of the latter also provide in the same setter BlobTargetOption... [and overload it with Iterable]. In this case we could either leave it with the javadoc suggestion (but only
applies to the target that accepts BlobInfo) and maybe also throw IllegalArgumentException in such case.
Based on [2] and instead of client side check we could change the RPC message to accept a flag to indicate if overriding the source metadata is desired.
Probably also based on [2] and instead of client side check we could use the source metadata (by issuing a separate get request) and "patch" it manually.
GCS Copy (and ReWrite) operations includes copying the original blob's metadata but also provides
a way to override the blob's metadata (such as content-type, contentLanguage, metadata fields).
When using the apiary copy or rewrite operations and supplying a
StorageObjectcontent it is goingto be used for blob's metadata overriding values. However, in this case content-type is required (and operation will fail if one is not provided).
Currently the implementation will silently ignore any overriding metadata if content-type is missing (as
in that case it will not pass the
StorageObjectcontent).This is unexpected and not documented.
Several options:
Just document this behaviour in the
Storage.CopyRequest.Builder.targetmethod.Change
Storage.CopyRequest.Buildertarget settings to get eitherBlobIdorBlobInfo(and in case of the latter also provide in the same setterBlobTargetOption... [and overload it with Iterable]. In this case we could either leave it with the javadoc suggestion (but onlyapplies to the target that accepts
BlobInfo) and maybe also throwIllegalArgumentExceptionin such case.Based on [2] and instead of client side check we could change the RPC message to accept a flag to indicate if overriding the source metadata is desired.
Probably also based on [2] and instead of client side check we could use the source metadata (by issuing a separate get request) and "patch" it manually.