René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Copy operation ignores stored object settings if content-type is null","articleBody":"GCS Copy (and ReWrite) operations includes copying the original blob's metadata but also provides \na way to override the blob's metadata (such as content-type, contentLanguage, metadata fields).\n\nWhen using the apiary copy or rewrite operations and supplying a `StorageObject` content it is going\nto 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).\n\nCurrently the implementation will silently ignore any overriding metadata if content-type is missing (as\nin that case it will not pass the `StorageObject` content).\n\nThis is unexpected and not documented.\n\nSeveral options:\n\n1) Just document this behaviour in the `Storage.CopyRequest.Builder.target` method.\n\n2) 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\u003cBlobTargetOption\u003e]. In this case we could either leave it with the javadoc suggestion (but only\napplies to the target that accepts `BlobInfo`) and maybe also throw `IllegalArgumentException` in such case.\n\n3) 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.\n\n4) 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.\n","author":{"url":"https://github.com/aozarov","@type":"Person","name":"aozarov"},"datePublished":"2015-10-29T01:43:38.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":1},"url":"https://github.com/306/google-cloud-java/issues/306"}